summaryrefslogtreecommitdiff
path: root/test/files/neg/t4425b.check
Commit message (Collapse)AuthorAgeFilesLines
* SI-7850 CCE in patmat with invalid isEmpty.Paul Phillips2013-12-151-6/+6
| | | | | | | | Name-based pattern matcher needed some hardening against unapply methods with the right name but wrong types. Only isEmpty methods which return Boolean are acceptable. Catching it directly rather than indirectly also allowed for better error messages.
* SI-7897, SI-6675 improves name-based patmatPaul Phillips2013-12-151-21/+9
| | | | | | | | | | | | | | | | | | | This emerges from a recent attempt to eliminate pattern matcher related duplication and to bake the scalac-independent logic out of it. I had in mind something a lot cleaner, but it was a whole lot of work to get it here and I can take it no further. Key file to admire is PatternExpander.scala, which should provide a basis for some separation of concerns. The bugs addressed are a CCE involving Tuple1 and an imprecise warning regarding multiple pattern crushing. Editorial: auto-tupling unapply results was a terrible idea which should never have escaped from the crib. It is tantamount to purposely throwing type safety down the toilet in the very place where people need type safety the most. See SI-6111 and SI-6675 for some other comments.
* Refined name-based patmat methods.Paul Phillips2013-08-181-6/+6
| | | | | | | | This fleshes out some of the slightly unfinished corners of the adventure, especially for unapplySeq. There's still an unhealthy amount of duplication and a paucity of specification, but I think it's in eminently good shape for a milestone.
* Pattern matcher: extractors become name-based.Paul Phillips2013-08-171-15/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An extractor is no longer required to return Option[T], and can instead return anything which directly contains methods with these signatures: def isEmpty: Boolean def get: T If the type of get contains methods with the names of product selectors (_1, _2, etc.) then the type and arity of the extraction is inferred from the type of get. If it does not contain _1, then it is a single value extractor analogous like Option[T]. This has significant benefits and opens new territory: - an AnyVal based Option-like class can be used which leverages null as None, and no allocations are necessary - for primitive types the benefit is squared (see below) - the performance difference between case classes and extractors should now be largely eliminated - this in turn allows us to recapture great swaths of memory which are currently squandered (e.g. every TypeRef has fields for pre and args, even though these are more than half the time NoPrefix and Nil) Here is a primitive example: final class OptInt(val x: Int) extends AnyVal { def get: Int = x def isEmpty = x == Int.MinValue // or whatever is appropriate } // This boxes TWICE: Int => Integer => Some(Integer) def unapply(x: Int): Option[Int] // This boxes NONCE def unapply(x: Int): OptInt As a multi-value example, after I contribute some methods to TypeRef: def isEmpty = false def get = this def _1 = pre def _2 = sym def _3 = args Then it's extractor becomes def unapply(x: TypeRef) = x Which, it need hardly be said, involves no allocations.
* SI-4425 do some validity checking on unapplies.Paul Phillips2013-08-171-0/+55
Filter out unapplies which can't be called (such as those with a second non-implicit parameter list) and report the error in a meaningful fashion.