<html><body><div id="edo-message"><div></div>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.</div><div id="edo-message"><br></div><div id="edo-message">I think we should suggest it for Swift 5.</div><div id="edo-message"><br></div><div id="edo-message">- Karl </div><div id="edo-original"><div><br><blockquote type="cite" style="margin:1ex 0 0 0;border-left:1px #ccc solid;padding-left:0.5ex;"><div>On Jul 31, 2017 at 7:48 am, <<a href="mailto:swift-evolution@swift.org">Adrian Zubarev via swift-evolution</a>> wrote:<br><br></div><div>We had some really really long talks about that before. Search for something like `AnyValue` and `ValueSemantics`. ;)<br> <br><div class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div> <p class="gmail_quote" style="color:#000;">Am 31. Juli 2017 um 07:33:36, Daryle Walker via swift-evolution (<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>) schrieb:</p> <blockquote type="cite" class="gmail_quote"><span><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div></div><div>
<title></title>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Jul 31, 2017, at 1:19 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">Daryle, this discussion has indeed taken
place before. One good place to start is the Google result for
"swift evolution non-conformance".</div>
</div>
</blockquote>
<div><br class=""></div>
<div>I added SR-5589, to request a counter protocol to
AnyObject.</div>
<div><br class=""></div>
<blockquote type="cite" class="">
<div class="">
<div class="gmail_extra">
<div class="gmail_quote">On Sun, Jul 30, 2017 at 5:30 PM, Daryle
Walker via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br class="">
> On Jul 30, 2017, at 5:03 PM, Tino Heth <<a href="mailto:2th@gmx.de" class="">2th@gmx.de</a>> wrote:<br class="">
><br class="">
>> [Apologies if this is in Swift 4 already.]<br class="">
>><br class="">
>> 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.<br class="">
> Why do you want that?<br class="">
> 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".<br class="">
> Also:<br class="">
> Don't forget retroactive conformance — you can never rely on
non-conformance.<br class="">
<br class=""></span>I forgot about that last part. But my idea
still has merit, due to why I desired it in the first
place.<br class="">
<br class="">
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.<br class="">
<br class="">
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.<br class=""></blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
<div class="">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="">— </div>
<div class="">Daryle Walker<br class="">
Mac, Internet, and Video Game Junkie<br class="">
darylew AT mac DOT com </div>
<div class=""><br class=""></div>
</div>
</div>
</div>
_______________________________________________<br>swift-evolution mailing list<br>swift-evolution@swift.org<br>https://lists.swift.org/mailman/listinfo/swift-evolution<br></div></div></span></blockquote>_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
</div></blockquote></div></div></body></html>