> On Dec 10, 2017, at 8:00 AM, Brent Royal-Gordon via swift-evolution 
> <swift-evolution@swift.org> wrote:
>> On Dec 9, 2017, at 10:32 AM, Xiaodi Wu via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> On Sat, Dec 9, 2017 at 11:20 Steven Brunwasser <sbrunwas...@gmail.com 
>> <mailto:sbrunwas...@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:


…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

swift-evolution mailing list

Reply via email to