<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=""><div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 29, 2017, at 07:25, Chris Lattner 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=""><div class=""><br class=""><blockquote type="cite" class="">On Nov 29, 2017, at 12:46 AM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="">brent@architechies.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">On Nov 28, 2017, at 8:35 PM, Chris Lattner <<a href="mailto:clattner@nondot.org" class="">clattner@nondot.org</a>> wrote:<br class=""><br class="">We’ve had a lot of discussions over the years about how to balance simplicity vs power, implicitness vs explicitness, intentionality vs accidental behavior, etc. For example, in very early discussions about Swift generics, some folks where strong proponents of protocol conformance being fully implicit: satisfying all the requirements of a protocol meant that you conformed to it, even if you didn’t explicitly “inherit” from it.<br class=""><br class="">This is obviously not the design we went with over the long term, and I’m glad we didn’t.<br class=""></blockquote><br class="">I get that, but an attribute in particular would be just as explicit as a protocol conformance.<br class=""></blockquote><br class="">Sure, I’m not attached to spelling. I think that conformance is the right way to do this (following the pattern of the other ExpressibleBy etc types), but if you have a compelling argument for some specific spelling, I’m more than happy to discuss it.<br class=""></div></div></blockquote><div><br class=""></div><div>I completely agree that protocol conformance is the right away to do it. One similar approach is Scala’s <a href="https://blog.scalac.io/2015/05/21/dynamic-member-lookup-in-scala.html" class="">Dynamic</a> protocol.</div><div><br class=""></div><div>I can’t think of a good “-able” word for this. "DynamicMemberLookupProtocol" is probably good enough IMO.</div><div><br class=""></div><div>-Richard</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">I think that DynamicMemberLookup requiring conformance is the same thing: it makes it explicit that the behavior is intentional, and it allows somewhat better error checking (if you conform to the protocol but don’t implement the (implicitly known) requirement, you DO get an error). That said, this is just my opinion. <br class=""></blockquote><br class="">So you envision that the compiler knows that `DynamicMemberLookupProtocol`-conforming types ought to have `subscript(dynamicMember:)` members, and these members ought to have certain traits (unary, ExpressibleByStringLiteral parameter, etc.), and it should enforce those traits, even though there's no matching requirement in the protocol?<br class=""></blockquote><br class="">Yes, this is implemented in the patch, it is a straight-forward additional check in protocol conformance.<br class=""><br class="">Keep in mind that the compiler has other similar things for features that are not expressible in the Swift type system, e.g. the type(of:) function.<br class=""><br class=""><blockquote type="cite" class="">That seems like a lot of compiler magic to attach to a particular protocol. A `@dynamicMember` attribute would have a similar amount of magic, but people *expect* that kind of magic from an attribute. For instance, the `@objc` attribute places lots of conditions on the types of parameters, etc., and nobody is surprised by that.<br class=""></blockquote><br class="">I don’t really think that’s the case. Attributes have their place, for sure, but there in high precedent for Protocols providing exposing language features to types.<br class=""><br class=""><blockquote type="cite" class=""><br class="">Other reasons to prefer an attribute:<br class=""><br class="">* I can't think of a use case where you would want dynamic members but not want to make the subscript itself accessible. If `@dynamicMember` could be applied to any subscript, then you could use any label (or no label) for sugar-free use of the dynamic functionality. For instance, the JSON example could decorate its existing subscript instead of introducing a redundant one:<br class=""></blockquote><br class="">I see the small advantage, but isn’t precedented at all. The ExpressibleBy protocols require redeclaring redundant methods just like this.<br class=""><br class=""><blockquote type="cite" class="">* If we eventually want to support multiple subscripts with different types (either by using different return types, <br class=""></blockquote><br class="">This is already supported in the patch, and the patch includes a test case.<br class=""><br class=""><blockquote type="cite" class="">Basically, you're using a hammer to drive a screw. Why not use a screwdriver instead?<br class=""></blockquote><br class="">I don’t see a connection between this rhetorical mechanic and the topic at hand :-)<br class=""><br class="">-Chris<br class=""><br class="">_______________________________________________<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></div></blockquote></div><br class=""></div></div></body></html>