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

[Karl Wagner]

 Indeed. I think something that is missing from the generics manifesto is that we need more type constraints. Value/reference semantics is one badly-needed distinction, but there are others, too (e.g. trivial types). There are lots of generic structures and algorithms which developers would like to restrict to some combination of those type properties.
  

  
I think we should suggest it for Swift 5.
  

  
- Karl   
  
  

  
>   
> On Jul 31, 2017 at 7:48 am,  <Adrian Zubarev via swift-evolution (mailto:swift-evolution at swift.org)>  wrote:
>   
>   
> 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
> >      _______________________________________________ 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/b6c96774/attachment.html>