[nem-en] Operator ??

[Alejandro Serrano]

I would just make ?? work like this:

a) If the object is Nullable[T], using a ?? b would have type T, and
mean if (a.HasValue) a.Value else b
b) If not, a ?? b would just mean if (a != null) a else b


Michal Moskal escribió:
> 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!
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> https://nemerle.org/mailman/listinfo/devel-en
>   


		
______________________________________________ 
LLama Gratis a cualquier PC del Mundo. 
Llamadas a fijos y móviles desde 1 céntimo por minuto. 
http://es.voice.yahoo.com