<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="">Thanks Oliver for bringing this up.</div><div class=""><br class=""></div>Anyone can share the thread for the draft/experimental API which is in the implementation? I cannot find it.<div class=""><br class=""></div><div class="">About performance, I think the idea is to return Swift types only and not autoreleasing objects anymore.</div><div class="">Still a performance test would be needed to clarify if your proposed solution performs better or not.</div><div class="">Also we have to clarify if this suggestion is in line with Swift API guidelines and maybe find a trade-off if performance is better.<br class=""><div class=""><br class=""></div><div class="">Cheers,<div class="">Alfredo Delli Bovi<br class="">
<br class=""><div><blockquote type="cite" class=""><div class="">On 30 Nov 2016, at 11:50, Oliver Drobnik via swift-corelibs-dev &lt;<a href="mailto:swift-corelibs-dev@swift.org" class="">swift-corelibs-dev@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Earlier I posted this proposal to the Swift Evolution Mailing list. Then I looked at the NSScanner implementation in core libs and found experimental API using the return value to for returning the scanned results. See my comments on that below:<div class=""><br class=""></div><div class=""><br class=""></div><div class="">—</div><div class=""><br class=""></div><div class="">Working on a function for Foundation’s Scanner I stumbled on this LLVM crash:&nbsp;<a href="https://bugs.swift.org/browse/SR-3295" class="">https://bugs.swift.org/browse/SR-3295</a><div class=""><br class=""></div><div class="">This got me thinking about a workaround and I would like to prose this:</div><div class=""><br class=""></div><div class="">When importing Foundation into Swift 3, all&nbsp;</div><div class=""><br class=""></div><div class=""><b class="">AutoreleasingUnsafeMutablePointer&lt;T?&gt;?</b></div><div class=""><br class=""></div><div class="">should instead be exposed as simple:</div><div class=""><br class=""></div><div class=""><b class="">inout T?</b></div><div class=""><br class=""></div><div class="">e.g.</div><div class=""><br class=""></div><div class=""><b class="">open&nbsp;func&nbsp;scanString(_&nbsp;string:&nbsp;String, into result:&nbsp;AutoreleasingUnsafeMutablePointer&lt;NSString?&gt;?) -&gt;&nbsp;Bool</b></div><div class=""><br class=""></div><div class="">would become</div><div class=""><br class=""></div><div class=""><b class="">open&nbsp;func&nbsp;scanString(_&nbsp;string:&nbsp;String, into result:&nbsp;inout&nbsp;String?) -&gt;&nbsp;Bool</b></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">The call would stay exactly the same for normal use cases where you specify a receiving variable:</div><div class=""><br class=""></div><div class=""><b class="">var string: String?</b></div><div class=""><b class="">scanString("=", into: &amp;string)</b></div><div class=""><br class=""></div><div class="">because inout parameters require a &amp;</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">for the use case where you don’t require a receiving parameter, a second method without result parameter would be generated:</div><div class=""><br class=""></div><div class=""><b class="">open func scanString(_ string: String) -&gt; Bool</b></div><div class=""><br class=""></div><div class="">This is necessary because you cannot specify nil or an immutable value for an inout parameter.&nbsp;</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">A fixit/migration would change calls to</div><div class=""><br class=""></div><div class=""><b class="">scanString(“foo", into result: nil)</b></div><div class=""><br class=""></div><div class="">into</div><div class=""><br class=""></div><div class=""><b class="">scanString(“foo")</b></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">The normal call with receiving variable would stay the same. But the case without return would become more concise.</div><div class=""><br class=""></div><div class="">What do you think?</div><div class=""><br class=""></div><div class="">kind regards</div><div class="">Oliver Drobnik</div></div><div class=""><br class=""></div><div class="">—</div><div class=""><br class=""></div><div class="">The new experimental API does not consider the situation that one might just want to scan a token in a long string and since I know what I am scanning I don’t care about the result. For example in my scanning I would like to processed if I hit a “foo“ …&nbsp;</div><div class=""><br class=""></div><div class="">The experimental API would force me to do this:</div><div class=""><br class=""></div><div class=""><b class="">if let _ = scanString(“foo“) { }</b></div><div class=""><br class=""></div><div class="">My proposal is more elegant:</div><div class=""><br class=""></div><div class="">if scanString(“foo”) {}</div><div class=""><br class=""></div><div class="">And if you do lots and lots of these scans then performance would benefit from the compiler not having to pack the return for an autoreleasing value which would have to be released right away due to assignment to _.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">IMHO my proposal is more in line with the spirit of the original API: 1) return Bool if the scan was successful, 2) optionally return the scanned value.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">kind regards</div><div class="">Oliver Drobnik</div></div>_______________________________________________<br class="">swift-corelibs-dev mailing list<br class=""><a href="mailto:swift-corelibs-dev@swift.org" class="">swift-corelibs-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-corelibs-dev<br class=""></div></blockquote></div><br class=""></div></div></div></body></html>