[swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Paul Cantrell]

> On Dec 10, 2017, at 8:00 AM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Dec 9, 2017, at 10:32 AM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> On Sat, Dec 9, 2017 at 11:20 Steven Brunwasser <sbrunwasser at gmail.com <mailto:sbrunwasser at gmail.com>> wrote:
>> Just wanted to give my 2¢
>> 
>> ¢
>> I don’t like empty protocols—they feel like an abuse of the feature.
>> 
>> 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.
> 
> 
> I also think it should be an attribute.
> 
> The last time I said this, I pointed out that this was a protocol which:
> 
> 1. Has no formal members,
> 2. But imposes informal requirements enforced by the compiler,
> 3. Permits and uses arbitrary overloads, and
> 4. Cannot be usefully used in a generic context or as a type constraint,
> 
> None of which are true of ordinary protocols. Since then, we have added:
> 
> 5. Can only be conformed to in the main declaration.
> 
> 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.

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.

This section laying out the reasons why it doesn’t work:

    https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#declare-an-explicit-subscript-requirement <https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#declare-an-explicit-subscript-requirement>

…reads like a todo list for rounding out protocols and generics.

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?

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.

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.

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.

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.

Cheers, P

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171210/f66deb26/attachment.html>