Commit message (Collapse) | Author | Age | Files | Lines | |
---|---|---|---|---|---|
* | deprecates String => Name implicit conversions | Eugene Burmako | 2014-02-14 | 1 | -4/+4 |
| | | | | | | | Given that in 2.11 we have upgraded our name construction facility from `newTxxxName` to `TxxxName`, I think it’s time we retire these implicit conversions, as they no longer save keystrokes, but continue to present ambient danger associated with implicit conversions. | ||||
* | Implicits to encourage more Name-dropping. | Paul Phillips | 2012-07-06 | 1 | -0/+15 |
This creates implicits in cakes across the land from: String => TermName String => TypeName And also from: Name => NameOps[Name] // lower priority TermName => NameOps[TermName] TypeName => NameOps[TypeName] What this is all about, using "drop" as a motivating example, is that these should all work: "abc" drop 1 // "bc": String ("abc": TermName) drop 1 // "bc": TermName ("abc": TypeName) drop 1 // "bc": TypeName (("abc": TypeName): Name) drop 1 // "bc": Name But this should not: ("bc": Name) // ambiguity error This requires drop not being directly on Name; peer implicits from String => TermName and String => TypeName; implicit classes to install drop on TermName and TypeName; and a lower priority implicit class to allow ops on Names. Review by @xeno.by . |