<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>is and as are implemented in the compiler to call the same method<br><br>Sent from my iPhone</div><div><br>On Jun 14, 2017, at 1:38 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">In SE-0170, it states: "It is worth noting that `is` should follow the same logic as `as?`." For clarity, does rolling back to the initial Swift 3 behavior mean that `NSNumber(value: 0.1) is Float == true`?</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 14, 2017 at 3:13 PM, Philippe Hausler via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div>After implementing the proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md" target="_blank">https://github.com/apple/<wbr>swift-evolution/blob/master/<wbr>proposals/0170-nsnumber_<wbr>bridge.md</a> we have gotten some initial feedback.</div><div><br></div><div>It seems that there is definitely a fair amount of confusion and heartache for dealing with Float and Double values being bridged. </div><div><br></div><div>Specifically the cases like:</div><div><br></div><div>NSNumber(value 0.1) as? Float</div><div><br></div><div>which with the current implementation will return nil since the Double value 0.1 cannot be represented exactly as a Float.</div><div><br></div><div>It seems like the overwhelming majority of users know full well that Float will result in a loss of precision (hence why they chose that type over Double). This means that the floating point bridges for Double, Float, and CGFloat should not be the pedantic “exactly” cases but instead infer the conversion intent of a lax/approximated version.</div><div><br></div><div>So in short: for the betterment of the API ergonomics, the floating point types as destinations will be pulled back to their initial Swift 3 behavior.</div><div><br></div><div>Additionally to aide appropriate migration to the appropriate truncating/exactly initializers the un-labeled, deprecated in Swift 4, plain init methods to the numeric types with an NSNumber will now be annotated with the suggested replacements.</div><div><br></div><div>Thanks for your time and feedback,</div><div>Philippe Hausler</div></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div>
</div></blockquote></body></html>