Nikolay edited on 2007-07-04 15:51:36.0
|
|
Burak edited on 2007-07-04 16:09:40.0
|
List is an unapply method, this is an extractor pattern - the outcome of the method call (method unapply that lives in *object* List) does not need to be related to type List in any way. The type is the best we have.
Also, we'd like x to have the same type in patterns Foo(x) and Foo(x @ Crazyunapp())
|
Burak edited on 2007-07-04 20:55:58.0
|
reopened this, Stepan Koltsov was right in submitting this. The actual signature of List.unapplySeq is
def unapply[A](x:List[A]): Some[List[A]]
Now, in a pattern like x @ List(...), there is no harm in giving the better type when the thing accepts (it should be a subtype, so with multiple inheritance, one might need to give it a compoundtype I guess). It's also a spec change, I think. It could be very useful, we are already doing something similar with type tests (refining the expected type with the type we test for in the pattern.)
|
Burak edited on 2007-07-06 16:33:06.0
|
I checked in, but deactivated a line to Typers.scala that would IMHO fix the bug, if refinedType was doing something slightly more involved than what it does right now. As it is, the type's don't work out although I believe they should. Martin, could you comment?
|
Martin edited on 2007-07-14 11:51:10.0
|
Which line? Can you find out what exactly goes wrong?
|
Burak edited on 2007-08-14 18:26:03.0
|
hm I tried the change again and it works now. tant pis;) for the record, the changed lines in the typer are 1690 and 1694.
|
Burak edited on 2007-08-14 20:42:43.0
|
actually, bug0646.scala fails, due to a very weird refinement type... i included information in typers.scala, from the said line onwards. re-open and assigned to martin.
|