Smart pointers instead of GC?

Walter Bright newshound2 at digitalmars.com
Sun Feb 2 20:06:00 PST 2014


On 2/2/2014 3:40 PM, Timon Gehr wrote:
> 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?

For starters, grep through the source code for all the implicit conversions. 
Then think about how it fits in with match levels, function overloading, 
template overloading, partial ordering, ?:, covariance, contravariance, name 
mangling, TypeInfo, default initialization, will general functions have to be 
written twice (once for T, again for T?), auto function returns, and that's just 
off the top of my head.

It's not just writing a truth table and throwing it over the wall.


More information about the Digitalmars-d mailing list