> On Dec 10, 2017, at 6: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.
Hi Brent, This approach definitely could work. I added it to the alternatives section with a breakdown of why I don’t think it’s the right direction: https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#make-this-be-a-attribute-on-a-type-instead-of-a-protocol-conformance <https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#make-this-be-a-attribute-on-a-type-instead-of-a-protocol-conformance> -Chris
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
