As just a user of the language, as much as I hate churn I personally wouldn't mind seeing this fixed. In this case, I think the laxness can make it harder for developers to form the right mental model of the language; I know I have personally stumbled over this in the past.
- Daniel > On Jun 2, 2016, at 2:00 PM, Jordan Rose via swift-dev <swift-dev@swift.org> > wrote: > > We have a bug for this, https://bugs.swift.org/browse/SR-899. I had pretty > much the same reaction you did, which is that it's definitely a bug but it's > probably not worth changing right now. > > Jordan > > >> On Jun 2, 2016, at 13:21, Douglas Gregor via swift-dev <swift-dev@swift.org> >> wrote: >> >> Hi all, >> >> While working on some unrelated refactoring, I stumbled across a minor fix >> that would make use properly enforce “.self” when we want to get the >> metatype of a named type. For example, the Swift compiler currently >> (incorrectly) allows >> >> sizeof(UInt) >> >> which should be >> >> sizeof(UInt.self) >> >> The fix for this is actually pretty simple (patch attached), but the >> question is… do we want to fix the problem, if we think that we’ll get >> SE-0090 that makes “.self” go away? >> >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0090-remove-dot-self.md >> >> On the one hand, I want to fix the problem: >> >> * This came out of a desire to make the AST more sane. Essentially, the >> folding of expressions into TypeExprs—which will go away entirely if/when >> SE-0090 is implemented—is pulling in the parentheses describing call >> arguments. Without the fix, we still have weird AST. >> * SE-0090 is labeled as “deferred out of Swift 3”, so having the >> compiler not implement the stated language for an entire release cycle seems >> really unfortunate. >> >> OTOH, I don’t want to jerk people’s code around, forcing them to add “.self” >> now only to remove it a year from now (or whenever). >> >> Thoughts? >> >> - Doug >> >> <enforce-metatype-self.patch>_______________________________________________ >> swift-dev mailing list >> swift-dev@swift.org >> https://lists.swift.org/mailman/listinfo/swift-dev > > _______________________________________________ > swift-dev mailing list > swift-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-dev _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
