On Sun, Dec 10, 2017 at 7:59 AM, Brent Royal-Gordon <br...@architechies.com>

> On Dec 9, 2017, at 10:32 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
> On Sat, Dec 9, 2017 at 11:20 Steven Brunwasser <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.

Synthesized conformances cannot be declared in extensions either. If you'd
like, you could consider that this protocol is one for which the compiler
synthesizes an infinite number of members.

I would like to see (4) addressed: a complete implementation should allow
me to call any member on a type T in a generic context where T :
DynamicMemberLookupProtocol, which I kind of assumed that this proposal
would eventually permit.
swift-evolution mailing list

Reply via email to