> 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:
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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
