<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 class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><div class=""><div class="">But doing lazy checking of strings would end up having to check <i class="">every</i> string that comes from ObjC</div></div></blockquote></blockquote></div><div class=""><br class=""></div><div class="">I don’t think that’s necessarily true. There’s a limited set of places where invalid Unicode can creep into an NSString, and so the lazy check could probably bypass quite a few common cases — an ASCII string for example. Without digging into it, I suspect any NSString created from UTF-8 data can be safely bridged, since unpaired surrogate chars can’t make it through UTF-8.</div><div class=""><br class=""></div><div class="">Cheers, P</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 4, 2016, at 4:43 PM, Kevin Ballard via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<title class=""></title>
<div class=""><div class="">That kind of lazy checking of arrays is used pretty rarely (since, as you say, it only occurs with an `as!` expression). But doing lazy checking of strings would end up having to check <i class="">every</i> string that comes from ObjC (which, in a Swift app that uses Cocoa frameworks, is likely to be most strings the app works with).<br class=""></div>
<div class=""> </div>
<div class="">-Kevin Ballard</div>
<div class=""> </div>
<div class="">On Mon, Jan 4, 2016, at 02:41 PM, Félix Cloutier wrote:<br class=""></div>
<blockquote type="cite" class=""><div class="">There are precedents for lazily checking for validity after bridging. Using `array as! [T]` on a NSArray without generics fails lazily if you access an object that's not a T.<br class=""></div>
<div class=""> </div>
<div class=""><span class="colour" style=""><span class="font" style="font-family:'Lucida Grande'">Félix</span></span><br class=""></div>
<div class=""> </div>
<div class=""><blockquote type="cite" class=""><div class="">Le 4 janv. 2016 à 14:59:47, Dmitri Gribenko via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :<br class=""></div>
<div class=""> </div>
<div class=""><div dir="ltr" class=""><div class=""><div class=""><div class="">On Mon, Jan 4, 2016 at 9:37 PM, Kevin Ballard via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex;" class=""><div class=""><u class=""></u><br class=""></div>
<div class=""><div class="">I agree in principle that it would be great if String could enforce that it's always valid.<br class=""></div>
<div class=""> </div>
<div class="">But unfortunately, in practice, there's no way to do that without making it expensive to bridge from Obj-C. Because, as you've demonstrated, you can create NSStrings that contain things that aren't actually valid unicode sequences, every single bridge from an NSString to a String would have to be checked for validity. Not only that, but it's not clear what the behavior would be if an invalid string is found, since these bridges are unconditional - would Swift panic? Would it silently replace the invalid sequence with U+FFFD? Or something else entirely? But the question doesn't really matter, because turning these bridges from O(1) into O(N) would be an unacceptable performance penalty anyway.<br class=""></div>
</div>
</blockquote><div class=""> </div>
<div class="">Currently String replaces invalid sequences with U+FFFD lazily during access, but there are corner cases related to Objective-C bridging that can still leak invalid Unicode.<br class=""></div>
<div class=""> </div>
<div class="">Dmitri<br class=""></div>
</div>
<div class=""> </div>
<div class="">-- <br class=""></div>
<div class=""><div class="">main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if<br class=""></div>
<div class="">(j){printf("%d\n",i);}}} /*Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com" class="">gribozavr@gmail.com</a>>*/<br class=""></div>
</div>
</div>
</div>
<div class=""><img style="height:1px !important;width:1px !important;border-top-width:0px !important;border-right-width:0px !important;border-bottom-width:0px !important;border-left-width:0px !important;margin-top:0px !important;margin-bottom:0px !important;margin-right:0px !important;margin-left:0px !important;padding-top:0px !important;padding-bottom:0px !important;padding-right:0px !important;padding-left:0px !important;" border="0" height="1" width="1" alt="" src="https://www.fastmailusercontent.com/proxy/c333863cc5ccd02f8cd270f7e2edad541a991fa1d48757eaae6bcb2525ec958f/8647470737a3f2f25723030323431303e23647e23756e64676279646e2e65647f27766f2f60756e6f35707e6d396259433265684455633558795148445c66533c6143383a794056684d486975725a77645d674b46563b67365034427a5b635334434a5a535d22364a7a6d22364943546549413978507874364c4567305465413838756467694a5560724a7649303c43405267477f62397434507d4b4a777d6c42763c6c427f6365397745657a4940595261696d22364b647336594d6d613a6d22364c634e477471464056336e683c42775361314e403753425772317a4f6436417872314267647663585e4c69694946577272766653596340335d6831774a657659546a4074647078476b6e4e43656165323878345371757973526a4c69353b6d23344/open" class="">
_______________________________________________<br class=""></div>
<div class="">swift-evolution mailing list<br class=""></div>
<div class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""></div>
<div class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div>
</div>
</blockquote></div>
</blockquote><div class=""> </div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=zCg-2FSGF9Wk188a6c55kLyEbrj7YhaXxFEHM-2F-2B0YAlzUQ9WYVH6mR3nHVVXe-2BR-2BtX8jPOO-2BUa8LIK-2FD7gWFcP-2Bhh45Y8cCKHioVluBjxFHd-2BNBuTHQXOxkrF0qDae-2FnvwHTfVntHT-2BHTPS-2BwjXMnDmxwTy04kJx4vhObU3SMleN2brxfrJqc3jJ28DLzkv-2BgNuSJmoW7UKsIKXoVDXKgjfYL-2B7fXVWK3ksU7pOT-2B4Crk-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>