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