View mode: basic / threaded / horizontal-split · Log in · Help
January 09, 2013
Re: small idea
On Wednesday, 9 January 2013 at 15:10:47 UTC, bearophile wrote:
> eles:
>
>> void make_a_equal_to_b(??a,!!b); //I give you "b", give me "a"
>
> A saner syntax is just to use the same in/out/inout keywords at 
> the call point, This is essentially what C# does (with one 
> exception for COM):
>
> make_a_equal_to_b(ref a, in b)
>
> This feature was discussed several times in past for D. The 
> advantage is more readability for the code and less surprises. 
> The disadvantages are more typing, some code breakage of D2 
> code (because even if at the beginning it's a warning, and 
> later a deprecation, you will eventually need to enforce it 
> with an error).

Assuming that annotation-breaking is on a separate level of 
errorness than errors and regular warnings will avoid that 
problem. It will remain at the level "annotation", no need to 
migrate to "warning" or "error". Code will not break as long as 
typying "inout" &co. will be optional. If the programmer feels it 
is better, he puts it there.
January 09, 2013
Re: small idea
On Wednesday, 9 January 2013 at 15:43:09 UTC, bearophile wrote:
> Tim Krimm:
>
>> Why make it a requirement or give a warning.
>
> If it's not enforced I think it becomes a not useful enough 
> feature.

Let's cut it at half: if "inout" &co. are specified, then 
non-concordance with function declaration will be a requirement.

If "inout" & co. are not specified, then they are simply not 
required. Code breakage will be avoided.
January 09, 2013
Re: small idea
On Wednesday, 9 January 2013 at 16:04:06 UTC, David Nadlinger 
wrote:
> On Wednesday, 9 January 2013 at 14:28:32 UTC, eles wrote:
>> In D, this is signalled by the in/out/inout keywords.
>
> This should be »in/out/ref«, inout only had that meaning in D1.

OK&Thanks. Please read "ref" in my other posts, instead of 
"inout".
January 09, 2013
Re: small idea
On Wednesday, 9 January 2013 at 15:10:47 UTC, bearophile wrote:
> eles:
>
>> void make_a_equal_to_b(??a,!!b); //I give you "b", give me "a"
>
> A saner syntax is just to use the same in/out/inout keywords at 
> the call point, This is essentially what C# does (with one 
> exception for COM):
>
> make_a_equal_to_b(ref a, in b)
>
> This feature was discussed several times in past for D. The 
> advantage is more readability for the code and less surprises. 
> The disadvantages are more typing, some code breakage of D2 
> code (because even if at the beginning it's a warning, and 
> later a deprecation, you will eventually need to enforce it 
> with an error).

The same thing happens every time this is discussed: some people 
insist "ref" and "out" should be REQUIRED or else it should not 
be ALLOWED. Others don't want to break backward compatibility so 
they insist it can't be required. There is no common ground so it 
never gets to the "allowed" stage.

In C++ I actually use call site ref for & params even with no 
checking at all:
#define IN
#define OUT
in fact these are defined in a Microsoft header. I find them 
useful for documentation.

Again, my proposal is that the compiler should allow ref/out and 
not warn when it is missing; if users want a warning/error for 
missing ref/out, they can ask for it per-module with a pragma (or 
something).

> One more small D-specific problem is what to do if the first 
> argument is a ref and you want to use UCFS.

In the past I suggested allowing implicit ref for structs (but 
probably not for classes) with UFCS, because the "this" parameter 
of a member function of a struct is passed by ref already.
January 09, 2013
Re: small idea
I am responding before reading the rest of the thread.

On 01/09/2013 06:28 AM, eles wrote:

> In D, this is signalled by the in/out/inout keywords.

You mean ref, not inout.

> However, these are
> only visible at the moment of function declaration, not calling.

>
> In C, you usually can distinguish since parameters intended to be
> modified are passed through address (pointers), and you see that at use
> time:
>
> void make_a_equal_to_b(&a,b);

And in C++ it is again impossible because the ref parameter is a reference.

I've heard this proposal before. It is an interesting idea but I've been 
coding in C and C++ for years. I have never had an issue related to this 
topic. I always knew what a function call did. I don't remember a single 
bug that was caused by this.

I don't even prepend "ptr" to pointer variable names.

So I don't see the benefit.

Ali
January 09, 2013
Re: small idea
On Wed, 09 Jan 2013 15:28:31 +0100
"eles" <eles@eles.com> wrote:

> Disclaimer: I do not ask for anything, it is just an idea, do not 
> blame me (too much).
> 
> One thing that I really like about a function is to know quite 
> clearly which of its parameters are for input, which for output 
> and, yes, which one are for carrying (input/output parameters).
> 
> In D, this is signalled by the in/out/inout keywords. However, 
> these are only visible at the moment of function declaration, not 
> calling.
> 
> In C, you usually can distinguish since parameters intended to be 
> modified are passed through address (pointers), and you see that 
> at use time:
> 
> void make_a_equal_to_b(&a,b);
> 
> In D, it would be:
> 
> void make_a_equal_to_b(a,b);
> 
> Yes, the name of the function can convey the intention. But, in 
> C, the calling, too. It is a kind of a double check.
> 
> Now, what about accepting a quick and optional (to not break 
> existing code) annotation at the time of the call:
> 
> void make_a_equal_to_b(??a,!!b); //I give you "b", give me "a"
> 
> so that in, out and inout could be replaced by !!, ?? and !?
> 
> Alternatives could be: >>, <<, >< but that's more complex.
> 
> Non-concordance between !!/!?/?? use and in/out/inout declaration 
> could be sanctioned with a warning or an error, or explicitely 
> ignored through a compiler flag.

Yea, that's one thing I do like about C#.
January 09, 2013
Re: small idea
On Wed, Jan 09, 2013 at 01:57:14PM -0500, Nick Sabalausky wrote:
> On Wed, 09 Jan 2013 15:28:31 +0100
> "eles" <eles@eles.com> wrote:
[...]
> > One thing that I really like about a function is to know quite 
> > clearly which of its parameters are for input, which for output 
> > and, yes, which one are for carrying (input/output parameters).
> > 
> > In D, this is signalled by the in/out/inout keywords. However, 
> > these are only visible at the moment of function declaration, not 
> > calling.
[...]
> > Now, what about accepting a quick and optional (to not break 
> > existing code) annotation at the time of the call:
> > 
> > void make_a_equal_to_b(??a,!!b); //I give you "b", give me "a"
> > 
> > so that in, out and inout could be replaced by !!, ?? and !?
[...]

Why replace them? Why not just reuse them:

	void func(in int parmA, out int parmB) { ... }

	void main() {
		int x, y;

		func(in x, out y);	// self-documenting
		func(out x, out y);	// compile error
		func(in x, in y);	// compile error
	}


T

-- 
Only boring people get bored. -- JM
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home