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