[swift-evolution] [Pitch][Bug?] Test for Anti-Conformance During Generics

[Daryle Walker]

> On Jul 30, 2017, at 5:03 PM, Tino Heth <2th at gmx.de> wrote:
> 
>> [Apologies if this is in Swift 4 already.]
>> 
>> We can have generic parameters match a protocol. But I have an idea in my head that involves the type NOT conforming to a protocol. I don’t think we have a way currently to work with this.
> Why do you want that?
> When something conforms, you know that you can call the methods of the protocol, but without conformance, you can't do anything that's not possible using "is".
> Also:
> Don't forget retroactive conformance — you can never rely on non-conformance.

I forgot about that last part. But my idea still has merit, due to why I desired it in the first place.

The “AnyObject” protocol is marked on all class types. All class types conform to it, and it’s illegal (as I understand it) to put on a type that isn’t already a class. I have been working on a “strong type-alias” proposal, and it has a similar protocol. And I came up with ideas that depend on a type NOT being a strong type-alias. That’s what prompted the post. Note that these protocols cannot be retroactively applied, so negation has merit.

Since there’s a limited number of them, a better solution could be to add a “NeverAnObject” protocol that’s automatically slapped onto non-class types (and cannot be added onto class types). And like “AnyObject,” it can be a base protocol, but this time it forces the conforming protocol to not be for classes.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com