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
