> On Dec 10, 2017, at 13:01, Chris Lattner via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>>> 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> 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.
>
> 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
I think the protocol vs attribute debate is more about what it means to be an
attribute. I personally see attributes as eventually becoming a more extensible
meta-programming tool, but that might not be the community’s consensus.
Assuming that attributes are for meta-programming, this would make more sense
as an attribute, since its a tool for dynamically resolving undefined symbols
at compile-time.
- Steve
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
