<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I’m not at all a fan of _forcing_ IUOs. Depending on the application, return types of Self!, Self?, always-succeeds Self, Self + throws, or Self + fatalError could all be the best approach.<div class=""><br class=""></div><div class="">In Python and JS, where objects have a dictionary-like shape, IUOs make sense: code can test for member presence when appropriate, while keeping general member access ergonomic.</div><div class=""><br class=""></div><div class="">In Ruby, where member lookup is fundamentally shaped more like a method call than a dictionary lookup, and where accessing a nonexistent member is a runtime error in the native language, then either throws or fatalError would be more appropriate.</div><div class=""><br class=""></div><div class="">I can imagine data-centric languages where traversing nonexistent members is typical and expected, either because the language has behavior like old-school Obj-C nil handling or because has create-on-traversal semantics. That behavior would be baked into to the shape of the APIs designed for the language. In that case, never-failing Self would be appropriate.</div><div class=""><br class=""></div><div class="">• • •<br class=""><div class=""><br class=""></div><div class="">I like the Chris’s approach where LookupType is an associated type (or, if we go with the empty protocol, behaves like one). It handles all these possibilities nicely, and then some.</div><div class=""><br class=""></div><div class="">It gives implementors latitude to choose the appropriate approach, and thus places the burden the authors of language-specific bridges to make language-appropriate design choices — which is _exactly_ as it should be.</div><div class=""><br class=""></div><div class="">Per my earlier message, I am interested in making well-designed libraries work as beautifully as possible, not in beating the authors of ill-designed ones over the head! The latter is futile, and this is a quintessential example of where pursuing the latter undermines the former.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class=""><br class=""></div><div class="">Paul<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 9, 2017, at 11:20 AM, Steven Brunwasser 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=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">Just wanted to give my 2¢</div><div class=""><br class=""></div><div class="">¢</div><div class="">I don’t like empty protocols—they feel like an abuse of the feature. I think attributes are the right way to go, since this proposal is about enabling syntactic sugar for types which can’t yet be described in the language as-is. This prevents retroactive conformance on preexisting types, which some have raised as a concern.</div><div class=""><br class=""></div><div class="">¢</div><div class="">I think the discussion about whether or not implementations should throw, return optional, or be implicitly unwrapped is a larger discussion on its own, and should probably be a separate proposal to steer the language towards a more well defined convention. That being said, I’m of the opinion that they should always return an implicitly unwrapped value. The precedent is already in the language, it allows for cleaner syntax while also explicitly stating “hey, just so you know, I might not work, so be careful, ok?”, and callers can choose to be more cautious by explicitly using the ? operator.</div><div class=""><br class=""></div><div class="">That is all,</div><div class="">- Steve</div><div class=""><br class="">On Dec 8, 2017, at 16:34, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">On Fri, Dec 8, 2017 at 18:08 Jon Gilbert via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div class=""><span class=""></span></div><div class=""><div class=""><span class=""></span></div><div class=""><div class=""></div><div class="">See below.</div><div class=""><br class="">On Dec 6, 2017, at 02:45, Nick Keets via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class="">Apologies, I may have misunderstood you. What I wanted to say is that I see no problem allowing "dangerous" stuff that may be abused. </div></blockquote><br class=""><div class="">You see no problem with danger and abuse?</div><div class=""><br class=""></div><div class="">I guess we have differing philosophies...</div><div class=""><br class=""></div><div class=""><a href="https://developer.apple.com/swift/" target="_blank" class="">https://developer.apple.com/swift/</a> states:</div><div class=""><br class=""></div><div class="">“<span style="background-color:rgba(255,255,255,0)" class="">Swift eliminates entire classes of unsafe code.”</span></div><div class=""><br class=""></div><div class="">Lets keep it that way.</div><div class=""><br class=""></div><div class="">I’m all for this proposal if it can be tweaked to where any of the dangerous invocations contain the word, “Unsafe”, or equivalent.</div></div></div></div></blockquote><div dir="auto" class=""><br class=""></div><div dir="auto" class="">Again, in Swift, “safety” means something very specific. Trapping at runtime is safe; in fact, trapping at runtime is *precisely the means by which safety is achieved* in the case of integer overflow and array indexing. This proposal introduces nothing that is unsafe.</div><div dir="auto" class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div class=""><div class=""><div class=""></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div class=""><div class=""><div class="">~Jon</div><div class=""><br class=""></div><div class=""><br class=""></div>
</div></div></div>_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div></div>
</div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></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=""></div></div></body></html>