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