> On Jun 2, 2016, at 4:22 PM, Brent Royal-Gordon <[email protected]> wrote: >> So, you think that this syntax is enticing to new developers who naturally >> think that the feature works the way that I'm proposing it should work, and >> you think that the right solution is to make the syntax illegal so that you >> can more conveniently tell them it doesn't work that way? :) > > I think the difference between a cast (which merely reinterprets a value as a > compatible type) and a fullwidth conversion (which creates a similar instance > of an incompatible type) is very important to understanding how to write > Swift, and we shouldn't muddy the waters by creating a magic syntax.
My point is that a literal doesn't really have a pre-existing type. Your explanation relies on a very strange model in which we assign it an arbitrary type just so we can introduce unwanted semantic conversions from that type. >> You can still tell them that it's a struct and you're calling an initializer >> on it; it's just that the initializer chosen is the special literal >> initializer because the argument is a literal. > > If you're planning to change `IntegerLiteralConvertible` and friends to > require a fullwidth conversion initializer like `init(_ value: > IntegerLiteralType)`, then this is simply an overload resolution rule. In > that case, I think your proposal is fine. This does not work. Literal construction is not necessarily as simple as converting from an existing type, and it's important to use a semantically distinguished initializer. > But if you're going to call `init(integerLiteral:)` like it's `init(_:)`, I > don't think that's a good idea. Parameter labels are supposed to be > significant; we don't want to lose that. It sounds like you're not in favor of the proposal, then. John. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
