On Sun, Dec 10, 2017 at 7:59 AM, Brent Royal-Gordon <br...@architechies.com> wrote:
> 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 swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
