Would like to see ref and out required for function calls

[Manuel]

On Thursday, 13 September 2012 at 10:34:00 UTC, Andrei 
Alexandrescu wrote:
> On 9/13/12 1:02 AM, Manuel wrote:
>> If a bigger part of the D community would like to have these 
>> annotations
>> added to the language, at least as an optional feature, then 
>> that might
>> persuade our "benevolent dictators" (just joking - you are 
>> great!)
>> Walther and Andrei to add them or we could just make a fork of 
>> the
>> language and add them ourselves (more joking - no, just skip 
>> this last
>> part - it's late) :-)
>>
>> There might be other problems, maybe with the compiler 
>> internals or
>> breakage of parts of the language. These were severe. But i 
>> think only
>> Walther and Andrei might tell. If these wouldn't exist it 
>> would at least
>> be possible, how David proposed it in his post, to make them 
>> optional.
>
> I don't think there would be problems with allowing ref/out 
> optionally at the call site. The thing is, however, that in 
> this matter reasonable people may disagree. In C++, the 
> equivalent argument (should we pass everything modifiable by 
> pointer or not?) erupts every six months on internal fora at 
> Facebook. No winning argument is made by either part. For 
> example, it is often brought up that it's good to see "&" at 
> the call site when debugging some urgent matter at 3am. Yet 
> there are other people who are just as apt at debugging urgent 
> matters at 3am, and the absence of "&" doesn't seem to be a 
> handicap for them at all. I'd be unable to identify any pattern 
> in engineers choosing one preference over the other. As a 
> consequence, our code has a mix of pass-by-pointer and 
> pass-by-reference-to-nonconst, all engineers manage either 
> style just as well, and we've never been able to find any 
> evidence pointing one way or another.
>
> Now that the subject has been broken,

Thanks Andrei for sharing your experience with this matter in 
your working environment (after all, it's "Facebook" and not 
"John Nobody and Sons Inc.").

To be honest, i and i think even Kevin, who started this thread, 
didn't expect such lively reactions. But Kevins thread seems to 
struck a nerve.

And i think you made a very important point here. Whether someone 
would like to have this feature in the language or not is, 
despite all technical reasons / merits, also a psychological 
thing or a matter of taste.


> people who are just as apt at debugging urgent matters at 3am, 
> and the absence of "&" doesn't seem to be a handicap for them 
> at all


I think every competent programmer can handle both cases well 
(even at 3am). It's more, and here you are right, where you want 
to spend your time. Do you want to spend your time looking up all 
the function/method signatures you don't know / remember or spend 
it writing endless call site annotations. Do you want to spend 
your time debugging strange side-effects or want to write 
annoying annotations just to please the compiler. At the end, at 
3am, it might result in the same level of productivity.


(1) transmogrify(MyValueType1, MyValueType2, MyValueType3);

The disadvantage here is, that if you don't know / have written 
the function you don't know whether if and which parameters might 
be modified. So you have to look the function signature up, no 
other choice here. There is no way for a quick read over the 
code. The advantage is that you save yourself writing endless 
annoying anotations, safe some typing and have less noise.


(2) transmogrify(MyValueType1, MyValueType2, out MyValueType3);

The disadvantage here is more typing, more noise. The advantage 
is that you as a programmer are forced to confirm that you know 
that this call will modify the value type and you want it this 
way, so nothing happens accidently. It's basically a 
double-check. You say i know this function will modify things and 
i want it that way. It gives people who read / review the code 
also more informations at a quick glance so they don't have too 
look things up constantly.

Whether you want something double checked might really depend on 
your personality (maybe i am more the anxious type and you are 
the bungee jumper type ;-) ).


So i think it basically boils down to this. I think it would fit 
do D because of the safety concept inside the language (as it is 
similar to contracts).

Since you don't seem to be overzealous regarding this (if i 
interpreted your confession rightly ;-) ) then it might be the 
best to leave all as it is.


I would like to have heared more arguments like: it breaks down 
certain language constructs, there are problems with templates or 
UCFS, or maybe from Walther that it makes too much work on the 
compiler side which could be spend better for other things or 
such.

But as i have written i haved lived without call site annotations 
in D and can live on without them. And honestly, i even think 
there are also more important things to be adressed in D (the 
classic one like bugs, toolchain, etc.).

So maybe the best contribution so far came from Paulo Pinto. To 
take things as they are and concentrate on more important things. 
But it's at least a good thing that we discussed this ;-)





> we do have good evidence of a pattern that generates 
> significant and difficult bugs: escaping the address of a 
> reference. In C++:
>
> struct A {
>     A(int& host) : host_(host) {}
> private:
>     int& host_;
> };
>
> In D:
>
> class A { // or struct
>     A(ref int host) : _host(&host) {}
> private:
>     int* _host;
> }
>
> A solution we use for C++ is to require escaped addresses to be 
> always passed as pointers or smart pointers.
>
> Walter and I have discussed this for quite a while. We have 
> recently decided to disallow, at least in SafeD, escaping the 
> address of a ref parameter. In the beginning we'll be overly 
> conservative by disallowing taking the address of a ref 
> altogether. I'll write a DIP on that soon.
>
>
> Andrei