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:[email protected])> 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 > ([email protected] (mailto:[email protected])) schrieb: > > > > > > > > > > > > > > > > > > > > > > On Jul 31, 2017, at 1:19 AM, Xiaodi Wu <[email protected] > > > (mailto:[email protected])> 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 > > > <[email protected] (mailto:[email protected])> wrote: > > > > > > > > > > > > On Jul 30, 2017, at 5:03 PM, Tino Heth <[email protected] > > > > (mailto:[email protected])> 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 > > [email protected] > > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ swift-evolution > > mailing list [email protected] > > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
