[nem-en] Operator ??

[Michal Moskal]

Hi Ivan,

On 9/24/06, Ivan A Eryshov <ivan.eryshov at gmail.com> wrote:
> I inspect C# specification regarding nullable types and the null coalescing
> operator ('??'). '??' has a lot of subtleties and I trying consistent with
> them.

As a general remark, it might not be the best idea to follow each and
every rule. Especially that they are not designed with type inference
in mind.

>             /**
>              *  BUG: 'Nullable[T]' can not be converted to 'T',
>              *       but it should.
>              *  Example:
>              *    def inull : int? = 10
>              *    // cannot convert System.Nullable[int] to int:
>              *    def i : int = inull :> int
>             **/

So System.Nullable doesn't have op_Explicit? If so, we need to emulate
it somehow.

>             /**
>              *  BUG: 'Nullable[T1]' can not be converted to
>              *       'Nullable[T2]' when 'T1' has implicit
>              *       conversation to 'T2', but it should.
>              *  C# Example:
>              *    int? i = 10;
>              *    double? d = i;
>             **/

And this is probably why it haven't...

>           /**
>            * ?BUG(??): This match case and next one can be replaced with
> single
>            *       one, but followed by code doesn't compile. Is this a
> design
>            *       decision or a bug? (C# compile such code with no
> problems)
>            *  Example:
>            *    #pragma indent
>            *    class A {}
>            *    class B
>            *      public static @:(_ : B) : A
>            *        A()
>            *    def a = A()
>            *    def b = B()
>            *    // expected B-, got A in computation branch:
>            *    def c = if (a==null) b else a
>           **/

This is more of a limitation than a bug. Upcasting in branches of if
(or match) only works with real subtyping and not implicit
conversions. Some changes are required in type inference to support
this and I have never gotten around to implement them. I probably
should.

> Secondly, I have problems with ?? macro (may be this is some kind of bugs,
> not sure).

The problem is that you use TExpr.TypeConversion in case when there is
an implicit conversion. What you should do in that case is to use
TExpr.Call (TExpr.StaticRef (conversion_operator), Parm(expr)).
Otherwise you're just cheating the type system (and this is what you
get -- the static type is right, but dynamic is not, the code would
not verify).

I think the best idea here would be to use TryTyping(...) function
instead of looking for conversions yourself or maybe just stick to
simple semantics without any implicit conversions. On the other hand
striping Nullable seems very useful, so TryTyping could be helpful.

Another thing that probably need to be done here, is delaying
execution of this macro, like it is done in foreach macro that also
analyzes types of its arguments.

Thanks!

-- 
   Michał