> 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. > 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. 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. -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
