Maybe I made a mistake when testing, but I thought I was able to convert a negative Int to a large UInt by going through NSNumber (it didn't return nil from the as? cast).<br><div class="gmail_quote"><div dir="ltr">On Mon, May 9, 2016 at 10:11 AM Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On May 7, 2016, at 1:23 PM, Zach Waldowski via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
> On Fri, May 6, 2016, at 11:20 PM, Charles Srstka via swift-evolution wrote:<br>
>> let int = num as? Int // 5<br>
>> let float = num as? Float // 5<br>
>> let int32 = num as? Int32 // nil!<br>
> That specific behavior with Int32 seems to be an oversight in the stdlib.<br>
<br>
It wasn't an oversight. At the time of Swift 1.0, bridging a type implied bidirectional implicit conversions, and if *every* integer type were bridgeable, it would be possible to unsafely implicitly convert between any two integer types by hopping through NSNumber. Now that we've eliminated these implicit conversions, we could consider bridging more types. Do you want to start another thread to discuss that idea?<br>
<br>
-Joe<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>
</blockquote></div>