<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 10, 2017, at 8:00 AM, Brent Royal-Gordon 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 style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 9, 2017, at 10:32 AM, Xiaodi Wu 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=""><span style="font-family: Helvetica; font-size: 12px; 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; float: none; display: inline !important;" class="">On Sat, Dec 9, 2017 at 11:20 Steven Brunwasser <</span><a href="mailto:sbrunwasser@gmail.com" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">sbrunwasser@gmail.com</a><span style="font-family: Helvetica; font-size: 12px; 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; float: none; display: inline !important;" class="">> wrote:</span><br style="font-family: Helvetica; font-size: 12px; 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=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; 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;"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><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.</div></div></blockquote><div dir="auto" class=""><br class=""></div><div dir="auto" class="">As has been discussed here before, protocols aren’t about bags of syntax but rather about semantics. Empty protocols are explicitly a demonstration of this settled principle and are very much consistent with the direction of Swift.</div></div></div></blockquote></div><div class=""><br class=""></div><div class="">I also think it should be an attribute.</div><div class=""><br class=""></div><div class="">The last time I said this, I pointed out that this was a protocol which:</div><div class=""><br class=""></div><div class="">1. Has no formal members,</div><div class="">2. But imposes informal requirements enforced by the compiler,</div><div class="">3. Permits and uses arbitrary overloads, and</div><div class="">4. Cannot be usefully used in a generic context or as a type constraint,</div><div class=""><br class=""></div><div class="">None of which are true of ordinary protocols. Since then, we have added:</div><div class=""><br class=""></div><div class="">5. Can only be conformed to in the main declaration.</div><div class=""><br class=""></div><div class="">This is looking less like a protocol by the day. The square-peg grooves in the round hole are getting deeper and more splintery with every revision.</div></div></div></blockquote><br class=""></div><div>The flavor of DynamicMemberLookupProtocol with an explicit member requirement sure does _read_ nicely! The fact that Chris left it present but commented out in the proposal suggests that expressing it that way has some intuitive / communicative value.</div><div><br class=""></div><div>This section laying out the reasons why it doesn’t work:</div><div><br class=""></div><div> <a href="https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#declare-an-explicit-subscript-requirement" class="">https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#declare-an-explicit-subscript-requirement</a></div><div><br class=""></div><div>…reads like a todo list for rounding out protocols and generics.</div><div><br class=""></div>So, Chris, question: in the future, maybe circa Swift 6 or 7, is it likely that generalized existentials + some sort of more robust handling of “mutating” in protocols would make the explicit member requirement on DynamicMemberLookupProtocol actually work?<div class=""><br class=""></div><div class="">If that seems likely, it would make sense to keep it an empty protocol now with the expectation that the language will catch up and the member requirement can be made explicit.</div><div class=""><br class=""></div><div class="">If that isn’t likely — if we expect that the member requirement will never really work — then my gut reaction is that Brent has a point.</div><div class=""><br class=""></div><div class="">Per Xiaodi, empty protocols per se aren’t a problem; Brent’s #1 and #2 don’t bother me much. But his #5 suggests this is deeply un-protocol-like, and if his #3 and #4 are never addressed by the compiler, then an attribute really is worth considering.</div><div class=""><br class=""></div><div class="">I guess the question boils down to whether this protocol behaves like a type, where implementing the protocol expresses an “is-a” relationship that makes semantic and intuitive sense, or whether it behaves more like a compiler flag that doesn’t express any useful type relationship.</div><div class=""><br class=""></div><div class="">Cheers, P</div><div class=""><br class=""></div></body></html>