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

Adrian Zubarev adrian.zubarev at devandartist.com
Mon Jul 31 00:46:17 CDT 2017


We had some really really long talks about that before. Search for something like `AnyValue` and `ValueSemantics`. ;)

--  
Adrian Zubarev
Sent with Airmail  

Am 31. Juli 2017 um 07:33:36, Daryle Walker via swift-evolution (swift-evolution at swift.org(mailto:swift-evolution at swift.org)) schrieb:

>  
>  
> > On Jul 31, 2017, at 1:19 AM, Xiaodi Wu <xiaodi.wu at gmail.com(mailto:xiaodi.wu at gmail.com)> wrote:  
> > Daryle, this discussion has indeed taken place before. One good place to start is the Google result for "swift evolution non-conformance".  
>  
> I added SR-5589, to request a counter protocol to AnyObject.  
>  
> > On Sun, Jul 30, 2017 at 5:30 PM, Daryle Walker via swift-evolution <swift-evolution at swift.org(mailto:swift-evolution at swift.org)> wrote:
> > >  
> > > > On Jul 30, 2017, at 5:03 PM, Tino Heth <2th at gmx.de(mailto: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  
>  
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170731/af57e8cf/attachment.html>


More information about the swift-evolution mailing list