Would like to see ref and out required for function calls

[Manuel]

On Tuesday, 11 September 2012 at 17:57:17 UTC, David Piepgrass 
wrote:
>>>> void func (ref int[], int)
>>>>
>>>> If ref/out were required at the call site, this destroys 
>>>> UFCS.
>>>>
>>>> int[] array;
>>>> array.func(0); // error, ref not specified by caller
>>>
>>> For UFCS, ref should be implied.
> +1
>
>> Why? UFCS means uniform function call syntax.
> It is already understood that the thing left of '.' may be 
> passed by reference:
>
> struct Foo { int x = 0; void f() { x++; } }
> void obvious()
> {
>    Foo foo; foo.f(); // x is passed to f() by reference
> }
>
> Perhaps your argument makes sense for classes, but not for 
> structs. In any case the syntax (ref foo).f() would require 
> extra work for Walter so I would not propose it. What I might 
> propose instead is that, if the user requests (via command-line 
> argument such as '-callSiteRef') that a warning be issued for 
> arguments passed without 'ref' at the call site, then a 
> situation like this should prompt a warning.
>
> class Bar { int b; }
> void changeBar(ref Bar b) { b = new Bar(); }
> void warning()
> {
>     Bar bar = new Bar();
>     bar.b = 10;
>     bar.changeBar(); // Warning: 'bar' is implicitly passed by 
> reference. To eliminate this warning, use 'changeBar(ref bar)' 
> instead or do not compile with '-callSiteRef'
> }
>
> Again, this problem only applies to classes, since it is 
> understood that structs are normally passed by reference.
>
>>> Also for 'const ref' parameters, callsite ref should not be 
>>> necessary.
>>>
>> The callee might escape a pointer to the argument. Which is
>> 'non-obvious' as well when there is no callsite ref.
>
> If you're referring to the fact that it's easy to have a D 
> pointer to a stack variable outlive the variable... I don't 
> think that this 'flaw' (I think of it as a flaw, others may 
> think of it as a feature) is a good enough reason to say 'call 
> site ref should be required for const ref parameters'.
>
>>> for value types, it is arguably important.
>>
>> This is not necessarily a valid conclusion. Popularity does 
>> not imply importance.
>
> I think 'ref' is a popular idea because people have used it in 
> C# and liked it. I didn't start putting 'IN OUT' and 'OUT' in 
> my C++ code until C# taught me the value of documenting it at 
> the call site.


Like i have written above, when switching from C++ to C# i found 
it at first annoying but now i wished i would have it in C++ too. 
One possibility to simulate this in C++ is like the pbrt people 
have done it with const references and pointers (look at my post 
above for further details).


>
>>>> Generally speaking, if a parameter being
>>>> ref/out is surprising, there is something wrong with the 
>>>> design.  (There
>>>> are times it is non-obvious in otherwise good code, this 
>>>> seems uncommon.)
>
> I often want to 'scan' code to see what it does. Especially for 
> debugging, I want to see where the side-effects are QUICKLY. 
> Guessing which parameters are 'ref' requires me to analyze the 
> code in my head. Even if I myself wrote the code, it can be 
> time consuming. That's why I would prefer to explicitly mark 
> possible side effects with 'ref' (of course, when passing a 
> class to a function, the class members may be modified when the 
> reference to the class was passed by value. But it is far 
> easier to keep track of which classes are mutable than to keep 
> track of which parameters of which functions are 'ref', because 
> functions far outnumber classes.)
>

+1

It's not only that you yourself want to 'scan' through your code 
and QUICKLY see where parameters in function calls are modified 
but others might have to read your code aswell for code reviewing 
without browsing in the hopefully existing documentation for 
every single function / method. People in companies normally are 
not programming in isolation but are working in a team and teams 
often change.



>> IMHO it is better left to the future D editor.
>
> That's probably a long way off.

Yes. Looking at the current overall state of the d toolchain that 
might be a very long way off.

And even then, inmho, it would be a not so good solution because 
it would be a feature which would tie users who want this feature 
to a specific editor / ide.