<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 6, 2017, at 9:45 PM, Paul Cantrell <<a href="mailto:cantrell@pobox.com" class="">cantrell@pobox.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: SourceCodePro-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">This seems marginally tolerable, but excessive.</div><div style="font-family: SourceCodePro-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: SourceCodePro-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Do we mark every usage of a type that can generate precondition failures or fatal errors for reasons other than “no such method?” No, we don’t.</div><div style="font-family: SourceCodePro-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: SourceCodePro-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Do we use a syntactically privileged marker instead of just using words like “unsafe” for types that expose direct access to raw memory? No, we don’t.</div><div style="font-family: SourceCodePro-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: SourceCodePro-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Has all of this ruined the language thus far? No. Because the Swift core team doesn’t design, and the Swift community doesn’t adopt, ill-designed APIs that turn these facts into problems.</div></div></blockquote></div><div class=""><br class=""></div>Yeah, I think I'd prefer this to stay as a normal protocol conformance. But if the proportion of resistance is high enough, I think the adoption of some annotation above and beyond the norm would be ok (again, at the declaration site, not the call site). Especially since this is a somewhat privileged protocol if any of the restrictions suggested in the proposal go forward, since they don't really apply to normal protocols.<div class=""><br class=""><div class=""><div class=""><div class="" style="font-family: SourceCodePro-Regular;"></div><blockquote type="cite" class=""><div class="" style="font-family: SourceCodePro-Regular;">My main objection to the critical responses is that most of the objections are fundamentally cultural, not technical, and are fear-based, not evidence-based.</div><div class="" style="font-family: SourceCodePro-Regular;"><br class=""></div><div class="" style="font-family: SourceCodePro-Regular;">If a little extra language ceremony helps assuage those fears, I guess I’d consider it. I still think static analysis — starting and mostly ending with boring old syntax coloring — answers most all the concerns people have raised, and this debate is a tempest in a teapot.</div></blockquote><br class=""></div></div></div><div class="">I agree wholeheartedly. I was just trying to bring some specifics to the examples given so far.</div></body></html>