<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Jun 2, 2016 at 2:38 PM Vladimir.S &lt;<a href="mailto:svabox@gmail.com">svabox@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What is wrong with your examples?<br>
<br>
var x1: Int32 = 0<br>
var x2 = Int32(0)<br>
print(x1.dynamicType, x2.dynamicType) // Int32 Int32<br></blockquote><div><br></div><div>I was referring to the subtle distinction between creating an Int32 from a literal (the first one) and creating an Int from a literal and then coercing it to Int32 (the second one). <span style="line-height:1.5">So, I was pondering whether this was the cause of some complex expressions I&#39;ve had problems with in the past. However, looking at the specific code, it looks like I had the *opposite* problem.</span></div><div><br></div><div>This expression is evaluated quickly in Swift 2.2:</div><div><br></div><div><div>let value = Int64((0x1b &lt;&lt; 0) | (0x28 &lt;&lt; 7) | (0x79 &lt;&lt; 14) | (0x42 &lt;&lt; 21) | (0x3b &lt;&lt; 28) |</div><div>      (0x56 &lt;&lt; 35) | (0x00 &lt;&lt; 42) | (0x05 &lt;&lt; 49) | (0x26 &lt;&lt; 56) | (0x01 &lt;&lt; 63))</div></div><div><br></div><div>This one errors out with &quot;<span style="line-height:1.5">expression was too complex to be solved in reasonable time&quot;</span><span style="line-height:1.5">:</span></div><div></div>





<div><br></div><div><div>let value: Int64 = (0x1b &lt;&lt; 0) | (0x28 &lt;&lt; 7) | (0x79 &lt;&lt; 14) | (0x42 &lt;&lt; 21) | (0x3b &lt;&lt; 28) |</div><div>      (0x56 &lt;&lt; 35) | (0x00 &lt;&lt; 42) | (0x05 &lt;&lt; 49) | (0x26 &lt;&lt; 56) | (0x01 &lt;&lt; 63)</div></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On 03.06.2016 0:17, Tony Allevato via swift-evolution wrote:<br>
&gt; +1. As someone who thought &quot;var x: Int32 = 0&quot; and &quot;var x = Int32(0)&quot; were<br>
&gt; equivalent, this is very good to know (and very good to fix).<br>
&gt;<br>
&gt; I&#39;m starting to wonder now if some of the times I&#39;ve hit &quot;expression was<br>
&gt; too complex&quot; errors with large 64-bit multi-term expressions with literals<br>
&gt; were caused by coercions happening that I didn&#39;t realize.<br>
&gt;<br>
&gt;<br>
&gt; On Thu, Jun 2, 2016 at 9:31 AM John McCall via swift-evolution<br>
&gt; &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;&gt; wrote:<br>
&gt;<br>
&gt;     The official way to build a literal of a specific type is to write the<br>
&gt;     literal in an explicitly-typed context, like so:<br>
&gt;         let x: UInt16 = 7<br>
&gt;     or<br>
&gt;         let x = 7 as UInt16<br>
&gt;<br>
&gt;     Nonetheless, programmers often try the following:<br>
&gt;         UInt16(7)<br>
&gt;<br>
&gt;     Unfortunately, this does /not/ attempt to construct the value using the<br>
&gt;     appropriate literal protocol; it instead performs overload resolution<br>
&gt;     using the standard rules, i.e. considering only single-argument<br>
&gt;     unlabelled initializers of a type which conforms to<br>
&gt;     IntegerLiteralConvertible.  Often this leads to static ambiguities or,<br>
&gt;     worse, causes the literal to be built using a default type (such as<br>
&gt;     Int); this may have semantically very different results which are only<br>
&gt;     caught at runtime.<br>
&gt;<br>
&gt;     In my opinion, using this initializer-call syntax to build an<br>
&gt;     explicitly-typed literal is an obvious and natural choice with several<br>
&gt;     advantages over the &quot;as&quot; syntax.  However, even if you disagree, it&#39;s<br>
&gt;     clear that programmers are going to continue to independently try to<br>
&gt;     use it, so it&#39;s really unfortunate for it to be subtly wrong.<br>
&gt;<br>
&gt;     Therefore, I propose that we adopt the following typing rule:<br>
&gt;<br>
&gt;       Given a function call expression of the form A(B) (that is, an<br>
&gt;     /expr-call/ with a single, unlabelled argument) where B is<br>
&gt;     an /expr-literal/ or /expr-collection/, if A has type T.Type for some<br>
&gt;     type T and there is a declared conformance of T to an appropriate<br>
&gt;     literal protocol for B, then the expression is always resolves as a<br>
&gt;     literal construction of type T (as if the expression were written &quot;B as<br>
&gt;     A&quot;) rather than as a general initializer call.<br>
&gt;<br>
&gt;     Formally, this would be a special form of the argument conversion<br>
&gt;     constraint, since the type of the expression A may not be immediately<br>
&gt;     known.<br>
&gt;<br>
&gt;     Note that, as specified, it is possible to suppress this typing rule by<br>
&gt;     wrapping the literal in parentheses.  This might seem distasteful; it<br>
&gt;     would be easy enough to allow the form of B to include extra<br>
&gt;     parentheses.  It&#39;s potentially useful to have a way to suppress this<br>
&gt;     rule and get a normal construction, but there are several other ways of<br>
&gt;     getting that effect, such as explicitly typing the literal argument<br>
&gt;     (e.g. writing &quot;A(Int(B))&quot;).<br>
&gt;<br>
&gt;     A conditional conformance counts as a declared conformance even if the<br>
&gt;     generic arguments are known to not satisfy the conditional<br>
&gt;     conformance.  This permits the applicability of the rule to be decided<br>
&gt;     without having to first decide the type arguments, which greatly<br>
&gt;     simplifies the type-checking problem (and may be necessary for<br>
&gt;     soundness; I didn&#39;t explore this in depth, but it certainly feels like<br>
&gt;     a very nasty sort of dependence).  We could potentially weaken this for<br>
&gt;     cases where A is a direct type reference with bound parameters, e.g.<br>
&gt;     Foo&lt;Int&gt;([]) or the same with a typealias, but I think there&#39;s some<br>
&gt;     benefit from having a simpler specification, both for the<br>
&gt;     implementation and for the explicability of the model.<br>
&gt;<br>
&gt;     John.<br>
&gt;     _______________________________________________<br>
&gt;     swift-evolution mailing list<br>
&gt;     <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;<br>
&gt;     <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; swift-evolution mailing list<br>
&gt; <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
&gt;<br>
</blockquote></div></div>