<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=""><div><blockquote type="cite" class=""><div class="">On Jun 2, 2016, at 10:49 AM, David Sweeris &lt;<a href="mailto:davesweeris@mac.com" class="">davesweeris@mac.com</a>&gt; 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><br class=""></div><div>Collection literals, e.g. [x,y,z] and [a: x, b: y].</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="">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() -&gt; </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="">&nbsp;</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><br class=""></div><div>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><br class=""></div>Note that this is only an issue for types that conform to the literal protocols.</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=""><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><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><br class=""></div><div>John.</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=""><div class=""><br class=""></div><div class="">So… I’m tentatively -1</div><div class=""><br class=""></div><div class="">- Dave Sweeris</div><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 2, 2016, at 11:08 AM, John McCall via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">The official way to build a literal of a specific type is to write the literal in an explicitly-typed context, like so:<div class=""><font face="Andale Mono" class="">&nbsp; &nbsp; let x: UInt16 = 7</font></div><div class="">or</div><div class=""><font face="Andale Mono" class="">&nbsp; &nbsp; let x = 7 as UInt16</font></div><div class=""><br class=""></div><div class="">Nonetheless, programmers often try the following:</div><div class=""><font face="Andale Mono" class="">&nbsp; &nbsp; UInt16(7)</font></div><div class=""><br class=""></div><div class="">Unfortunately, this does <i class="">not</i> attempt to construct the value using the appropriate literal protocol; it instead performs overload resolution using the standard rules, i.e. considering only single-argument unlabelled initializers of a type which conforms to IntegerLiteralConvertible. &nbsp;Often this leads to static ambiguities or, worse, causes the literal to be built using a default type (such as Int); this may have semantically very different results which are only caught at runtime.</div><div class=""><br class=""></div><div class="">In my opinion, using this initializer-call syntax to build an explicitly-typed literal is an obvious and natural choice with several advantages over the "as" syntax. &nbsp;However, even if you disagree, it's clear that programmers are going to continue to independently try to use it, so it's really unfortunate for it to be subtly wrong.</div><div class=""><br class=""></div><div class="">Therefore, I propose that we adopt the following typing rule:</div><div class=""><br class=""></div><div class="">&nbsp; Given a function call expression of the form A(B) (that is, an <i class="">expr-call</i>&nbsp;with a single, unlabelled argument)&nbsp;where B is an&nbsp;<i class="">expr-literal</i>&nbsp;or <i class="">expr-collection</i>, if A has type T.Type for some type T and there is a declared conformance of T to an appropriate literal protocol for B, then the expression is always resolves as a literal construction of type T (as if the expression were written "B as A") rather than as a general initializer call.</div><div class=""><br class=""></div><div class="">Formally, this would be a special form of the argument conversion constraint, since the type of the expression A may not be immediately known.</div><div class=""><br class=""></div><div class="">Note that, as specified, it is possible to suppress this typing rule by wrapping the literal in parentheses. &nbsp;This might seem distasteful; it would be easy enough to allow the form of B to include extra parentheses. &nbsp;It's potentially useful to have a way to suppress this rule and get a normal construction, but there are several other ways of getting that effect, such as explicitly typing the literal argument (e.g. writing "A(Int(B))").</div><div class=""><br class=""></div><div class="">A conditional conformance counts as a declared conformance even if the generic arguments are known to not satisfy the conditional conformance. &nbsp;This permits the applicability of the rule to be decided without having to first decide the type arguments, which greatly simplifies the type-checking problem (and may be necessary for soundness; I didn't explore this in depth, but it certainly feels like a very nasty sort of dependence). &nbsp;We could potentially weaken this for cases where A is a direct type reference with bound parameters, e.g. Foo&lt;Int&gt;([]) or the same with a typealias, but I think there's some benefit from having a simpler specification, both for the implementation and for the explicability of the model.</div><div class=""><br class=""></div><div class="">John.</div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></body></html>