<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="">On Nov 20, 2017, at 7:15 PM, Michel Fortin via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><blockquote type="cite" class="">As in `SupplementalDynamicMemberLookupProtocol` and `supplementalDynamicMember` for the subscript.<br class=""></blockquote></blockquote><blockquote type="cite" class=""><br class=""></blockquote><blockquote type="cite" class=""><div class=""><div style="font-family: SourceSansPro-Regular; font-size: 15px; 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="">I’m totally open to suggestions for a better name, but I don’t see what “Supplemental” is adding here. Recall that this protocol is compiler “magic” that is part of an implementation of a type, it isn’t really part of the user-exposed API of the type. I wouldn’t expect a user to ever write:</div><div style="font-family: SourceSansPro-Regular; font-size: 15px; 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: SourceSansPro-Regular; font-size: 15px; 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=""> pyVal[dynamicMember: “foo”]</div><div style="font-family: SourceSansPro-Regular; font-size: 15px; 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: SourceSansPro-Regular; font-size: 15px; 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="">Even though they could.</div></div></blockquote><div class=""><br class=""></div><div class="">I'm not sure why you say it's not part of the user-exposed API. The type conforms to the protocol, and the protocol has this subscript, and there is nothing preventing someone from using it. </div></div></div></div></blockquote><div><br class=""></div><div>Yes, I understand that of course.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class="">And if for some reason you have the name of the member in a string variable and want to use it, you *have to* use it to get to the variable. So it'll definitely get used.</div></div></div></div></blockquote><div><br class=""></div><div>Not necessarily. Nothing prevents a *specific* client from implementing a better accessor for their specific use, and I’d strongly encourage them to do so. This is a compiler hook - just like ExpressibleByArrayLiteral exposes an ArrayLiteralElement associated type and init(arrayLiteral:..) initializer… even on Set! </div><div><br class=""></div><div>I have definitely seen user code using these, but that isn’t the intention. The best solution to this is either to prevent them from being exported as API (my suggestion of something something like a “private conformance” implementation detail thing) or by simply marking these members with an attribute, so they don’t show up in code completion.</div><div><br class=""></div><div>I do care about this sort of thing getting fixed, and I personally prefer the attribute+code completion change, but this is an existing problem in swift, orthogonal from this proposal. If you’d like to see if fixed, then by all means, please bring this up and fix it. It is more offensive that Int gets weird members like IntegerLiteralType and an integerLiteral initializer [[[which show up all the time…. :-( :-( ]]] than the specific impact this proposal will have on a small set of narrow types people hardly interact with.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class="">Perhaps supplemental isn't the right word, but I wanted to convey that it supplements the Swift-defined methods and does not shadow them. For instance, in your PyVal protocol type there's a member `ownedPyObject` that won't be accessible with `dynamicMember` but will be dispatched through the protocol witness table.</div></div></div></div></blockquote><div><br class=""></div><div>Yes, I understand what you’re saying, but specific naming does matter. I don’t think that ownedPyObject is in huge danger of conflicting with something that matters, but if it were, I’d suggest name mangling it to something even less likely to conflict, and I’d mark ownedPyObject with the same attribute to hide it from code completion, so people don’t see it every time they code complete on a PyVal.</div><div><br class=""></div><div>-Chris</div><div><br class=""></div></div></body></html>