[nem-en] RFC: matching variant options against non-variant values

[Kamil Skalski]

Well, this would be consistent with

////////////////////
[Record]
class A  {
  public foo : int;
}

def x : object = A(1);

match (x)  {
  | A where (foo = 1) => System.Console.WriteLine ("a");
  | _ => ()
}
//////////////////

but after all I don't really like the distinction we have for
typecheck and pattern-matching of variants / record like matching. I
would prefer all of them do the isinst operation when needed.

On the other hand the current behavior makes sense if you consider
variant option matching as a kind of integer switch in which case it
should not do typecheck... So maybe only the knowledge of internal
implementation of variants / variant option matching spoils my
intuition here.

2007/4/30, Michal Moskal <michal.moskal at gmail.com>:
> Hi,
>
> I've just commited a change on trunk to disallow the following code:
>
> foo (o : object) : void
> {
>   match (o) {
>     | [ x, y ] => ... x + y ...
>     | _ => ...
>   }
> }
>
> It seems there were several cases in the compiler source code when a
> TyVar was matched against a pattern of type MType.Something. The
> correct way to do it, is to match the result of Fix(), otherwise we
> might get false negatives in matching, for example for aliased
> variables. I guess this didn't happen, because this was mostly used on
> top-level types, which are all-MType most of the time, but they were
> bugs waiting to happen. I know I have written most of the code in
> question myself, so it just highlights, that allowing this kind of
> matching leads to problems.
>
> There are also two bug reports releated to this, were we try to cast o
> to list[object], which doesn't work.
>
> I'm for disallowing it altogether, but if others feel like it, we I
> can replace it with a (optional?) warning. The correct code is:
>
> foo (o : object) : void
> {
>   match (o) {
>     | o is list [int] =>
>       match (o)
>          | [ x, y ] => ... x + y ...
>          | _ => ...
>       }
>     | _ => ...
>   }
> }
>
> Cheers!
>    Michał
>
> _______________________________________________
> https://nemerle.org/mailman/listinfo/devel-en
>
>


-- 
Kamil Skalski
http://nazgul.omega.pl