<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Just wanted to give my 2¢</div><div><br></div><div>¢</div><div>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><br></div><div>¢</div><div>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><br></div><div>That is all,</div><div>- Steve</div><div><br>On Dec 8, 2017, at 16:34, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div>On Fri, Dec 8, 2017 at 18:08 Jon Gilbert via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><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"><div><span></span></div><div><div><span></span></div><div><div></div><div>See below.</div><div><br>On Dec 6, 2017, at 02:45, Nick Keets via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div>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><div>You see no problem with danger and abuse?</div><div><br></div><div>I guess we have differing philosophies...</div><div><br></div><div><a href="https://developer.apple.com/swift/" target="_blank">https://developer.apple.com/swift/</a> states:</div><div><br></div><div>“<span style="background-color:rgba(255,255,255,0)">Swift eliminates entire classes of unsafe code.”</span></div><div><br></div><div>Lets keep it that way.</div><div><br></div><div>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"><br></div><div dir="auto">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"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><div><div></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"><div><div><div>~Jon</div><div><br></div><div><br></div>
</div></div></div>_______________________________________________<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></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>