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.
