On 02/02/2014 09:05 PM, Walter Bright wrote:
On 2/2/2014 9:30 AM, Namespace wrote:
Sounds good. But why @nullable instead of C# choice of "Type?" ?
Let me rephrase that as "why use a storage class rather than a type
constructor?"
An excellent question.
One of the big problems with a type constructor is we've already got a
number of them - const, immutable, shared, inout. These and their
conversions have taken quite a while for people to get comfortable with,
and there are still some issues in the language arising from their
interactions.
...
Nullable interacts with those type constructors basically in the same
way as the fixed-size array type constructor [1]. Regarding implicit
conversion, I think one good form to state the implicit conversion rules
in, for later procedural implementation, is the following:
A converts to B
──────────────────
A converts to B?
A converts to B
───────────────────
A? converts to B?
e converts to B?
────────────────── (flow analysis proves e non-null)
e converts to B
Where would be potentially bad interactions?
Adding another type constructor will double the number of cases. I worry
that D would collapse under the strain. This applies as well to type
constructors for "borrowed", etc.
...
This sounds as if there was a structural problem in DMD. (Adding the
relevant implicit conversion rules would be easy given the current state
of my own front end implementation effort.) How are type qualifiers
represented in the AST? How is the implicit conversion checker structured?
On the other hand, D took the risky leap into the unknown by making
'ref' a storage class rather than a type constructor (in C++ it's a type
constructor). This has turned out to be a satisfying win. I suspect it
will be for @nullable, too, though we have to work through the cases to
find out for sure.
These cases have almost nothing in common. (e.g, 'ref' does not
influence implicit conversion behaviour.)
