<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 2, 2016, at 12:57 PM, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 2, 2016, at 10:49 AM, David Sweeris <<a href="mailto:davesweeris@mac.com" class="">davesweeris@mac.com</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I’m not entirely sure what an “expr-collection” is.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Collection literals, e.g. [x,y,z] and [a: x, b: y].</div></div></div></div></blockquote><div>Thought so, but I wasn’t sure. Thanks for clarifying :-)</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Does your proposal mean that in this code:</div><div class=""><div style="margin: 0px; line-height: normal; font-family: 'Fira Mono';" class=""><span style="color: rgb(211, 54, 130); font-variant-ligatures: no-common-ligatures;" class="">func</span><span style="color: rgb(147, 161, 161); font-variant-ligatures: no-common-ligatures;" class=""> foo() -> </span><span style="color: rgb(39, 139, 210); font-variant-ligatures: no-common-ligatures;" class="">Int</span><span style="font-variant-ligatures: no-common-ligatures;" class=""><font color="#93a1a1" class=""> </font></span><span style="font-variant-ligatures: no-common-ligatures;" class=""><font color="#93a1a1" class="">{...</font></span><span style="color: rgb(147, 161, 161); font-variant-ligatures: no-common-ligatures;" class="">}</span></div><div style="margin: 0px; line-height: normal; font-family: 'Fira Mono'; color: rgb(147, 161, 161);" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #d33682" class="">var</span><span style="font-variant-ligatures: no-common-ligatures" class=""> w = </span><span style="font-variant-ligatures: no-common-ligatures; color: #6c71c4" class="">0</span></div><div style="margin: 0px; line-height: normal; font-family: 'Fira Mono'; color: rgb(147, 161, 161);" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #d33682" class="">var</span><span style="font-variant-ligatures: no-common-ligatures" class=""> x = </span><span style="font-variant-ligatures: no-common-ligatures; color: #29a198" class="">T</span><span style="font-variant-ligatures: no-common-ligatures" class="">(</span><span style="font-variant-ligatures: no-common-ligatures; color: #29a198" class="">foo</span><span style="font-variant-ligatures: no-common-ligatures" class="">())</span></div><div style="margin: 0px; line-height: normal; font-family: 'Fira Mono'; color: rgb(147, 161, 161);" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #d33682" class="">var</span><span style="font-variant-ligatures: no-common-ligatures" class=""> y = </span><span style="font-variant-ligatures: no-common-ligatures; color: #29a198" class="">T</span><span style="font-variant-ligatures: no-common-ligatures" class="">(</span><span style="font-variant-ligatures: no-common-ligatures; color: #29a198" class="">w</span><span style="font-variant-ligatures: no-common-ligatures" class="">)</span></div><div style="margin: 0px; line-height: normal; font-family: 'Fira Mono'; color: rgb(147, 161, 161);" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #d33682" class="">var</span><span style="font-variant-ligatures: no-common-ligatures" class=""> z = </span><span style="font-variant-ligatures: no-common-ligatures; color: #29a198" class="">T</span><span style="font-variant-ligatures: no-common-ligatures" class="">(</span><span style="font-variant-ligatures: no-common-ligatures; color: #6c71c4" class="">0</span><span style="font-variant-ligatures: no-common-ligatures" class="">)</span></div><div style="margin: 0px; line-height: normal;" class="">different initializers would be used for `x`,`y`, and `z`?</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">z would be initialized using the literal initializer if T conforms to that protocol, yes.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div style="margin: 0px; line-height: normal;" class=""> If so, that seems a potential source of much subtler problems.</div></div></div></div></blockquote><div class=""><br class=""></div>Note that this is only an issue for types that conform to the literal protocols.</div></div></div></blockquote><br class="">Oh, I know. The crux of my concern is that while the difference between `UInt16(7)` and `7 as UInt16` is subtle, it’s not <i class="">that</i> subtle… the literal convertible syntax doesn’t even look that much like a call to init, so it shouldn’t be that surprising if explicitly calling the init function might send you down a different code path. OTOH, this proposal silently (and invisibly) rewrites an explicit call to`init(_: Int)` to `init(integerLiteral: IntegerLiteralType)`, which seems worse. Again, I don’t disagree that there’s a subtlety here, but at least with the current behavior, the unexpected behavior comes from not paying attention to syntax.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">I don’t disagree that you’ve identified a potential source of issues, but it’s conceivable that there might be circumstances where the "semantically very different results” are desired. I can’t think of any off the top of my head, but I’m not convinced that means they don’t exist.</div></div></div></div></blockquote><div class=""><br class=""></div>I do not think that anybody writes UInt64(0) and *wants* the 0 to be built as an Int and then coerced to UInt64.</div></div></div></blockquote></div><br class=""><div class="">I can’t think of why anyone would either — all my *LiteralConvertible types just pass on the literal arguments to an init that takes an Int (or whatever) — but “a failure of imagination…”</div><div class=""><br class=""></div><div class="">I guess I’m just saying that with the way Swift treats literals, potential confusion is inevitable, and that it’s better to contain the subtleties to syntax which already involves some implicit behavior, rather than to start rewriting explicit code simply because we think the programmer doesn’t know what they’re doing.</div><div class=""><br class=""></div><div class="">- Dave Sweeris</div></body></html>