Smart pointers instead of GC?
Timon Gehr
timon.gehr at gmx.ch
Sun Feb 2 15:40:31 PST 2014
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.)
More information about the Digitalmars-d
mailing list