Would like to see ref and out required for function calls

[Timon Gehr]

Agh, sent a private mail again. I don't seem to be the only one though.
Has there been a thunderbird UI change?

On 09/08/2012 06:05 PM, Nick Treleaven wrote:
> On 08/09/2012 14:05, Chris Nicholson-Sauls wrote:
>> Given:
>>
>> 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.

Why? UFCS means uniform function call syntax.

> 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.

>> This suggestion has come up a couple times before, and each time failed
>> to gain traction.
>
> But given that C, C#, (Go?) and Rust have the same philosophy that
> argument modification should be explicit

It is already explicit. The information is just not repeated at the
call site.

> for value types, it is arguably important.

This is not necessarily a valid conclusion. Popularity does not imply
importance.

> It might be nice to have for D3.
>
>> I wouldn't mind it as an option -- possibly even as a
>> recommendation in most library code -- but as a requirement it honestly
>> just gives me a headache.
>
> As an option it would serve no practical purpose other than documentation.
>

Requiring it makes lack of call site annotations carry some information.
The only practical purpose would still be documentation.


>> 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.)
>
> Yes but unfortunately bad design is going to be a reality sometimes.

Bad design never should be a motivation for adding language features.
In fact, it seems to be a motivation for creating languages that have
few features.

> Also there is a difference between 'surprising' and 'obvious'. Callsite
> ref makes it quicker to understand code for a negligible cost,
> occasionally a lot quicker if you're coming back to code you haven't
> seen for a while.
>

IMHO it is better left to the future D editor. It can highlight ref/out
arguments in a distinct style. Why clutter the language core even more
with somewhat complex rules specifying in what cases call site ref is
required?

> ...
> The point is that the signature of checkedEmitJ is not always there when
> you are reading code that calls checkedEmitJ, so the ref and out
> parameters are useful in saving the reader time.

I'd still have to look up its declaration to understand exactly what it 
does.

> Making code easier to read is much more important than making it easier to write.
>

I don't know why this quote is repeated all the time. It is not like
ease of writing and ease of reading are decoupled or something.
What is most important is designing the language such that code
that is easy to write is easy to read.

What is easy to read is to some extent subjective. eg. I'd prefer to
just look at the called function's documentation rather than having
every call I later inspect redundantly repeat information present in
the function declaration. IMHO it's just noise.

> When I first saw:
> swap(ref a, ref b);
>
> I thought that looked ugly with the refs, but now I don't mind it. IMO
> it's only functions whose arguments are all passed by ref that don't
> really need annotation,

We are talking about call site annotations. Functions will always
require annotation to change the parameter passing style.

> and these are infrequent.

What is this claim based on? The use case above is probably one of the 
more common ones.