<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Jun 2, 2016, at 4:33 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><div class=""><div style="white-space:pre-wrap" class="">The IntegerLiteral type idea might be worth exploring. It does seem to provide some additional consistency. For example, wasn't it clarified on this list just recently that literals don't have a type and adopt one based on context? It'd be nice to point out that 42 is an IntegerLiteral when explaining that it's not an Int.<br class=""></div></div></blockquote><div><br class=""></div>I think that's a very promising way of thinking about literals. Writing a literal creates a notional value whose type is the informal, infinite-precise type of all integer/FP/collection/etc. literals, which (1) can be implicitly converted to any type that implements the appropriate protocol and (2) in fact *must* be converted to some such type (possibly the default type for that literal) in order for the code to be executable. You can then think about this proposal as saying that an explicit conversion from that informal type to a literal-convertible type follows the same path as an implicit conversion would have.</div><div><br class=""></div><div>John.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, Jun 2, 2016 at 18:22 Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> 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? :)<br class="">
<br class="">
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.<br class="">
<br class="">
> 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.<br class="">
<br class="">
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.<br class="">
<br class="">
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.<br class="">
<br class="">
--<br class="">
Brent Royal-Gordon<br class="">
Architechies<br class="">
<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div>
</div></blockquote></div><br class=""></body></html>