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