<html><body><div id="edo-message"><div>Copying is a much more nuanced issue than just reference-or-value though. I would also support some good copying protocols in the standard library, but that's additive.<br><br><style>#edo-signature img {max-width: 90%}</style><div id="edo-signature" style="font-family: 'Helvetica Neue','Helvetica',Helvetica,Arial,sans-serif;font:'-apple-system-body';"></div><br><div id="edo-link"></div></div></div><div id="edo-original"><div><br><br><blockquote type="cite" style="margin:1ex 0 0 0;border-left:1px #ccc solid;padding-left:0.5ex;"><div>On Oct 21, 2016 at 5:11 pm, <<a href="mailto:mike@ap14.com">Mike Kasianowicz</a>> wrote:<br><br></div><div><div dir="ltr">Just from an outside perspective, the class restriction seems to be there as a kludge for technical reasons... but that's neither here nor there.<div><br></div><div>It is not so much to enforce a lack of identity - in the struct case, it would be to enforce copy-by-value semantics. I think the strongest argument I've got is, say, a serialization or caching framework where you want to enforce that something is entirely writeable via memory pointer or copyable. A value-type restriction would get us mostly there, albeit there would still be ways to break the contract. However, as noted in my previous email, I see a lot of possibilities for enums too - in that case the protocol somewhat acts as 'base type' without adding the complexity of a base type.</div><div><br></div><div>I listed some of my examples in my previous email - I could elaborate if it helps.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 21, 2016 at 9:51 AM, Karl Wagner <span dir="ltr"><<a href="mailto:razielim@gmail.com" target="_blank">razielim@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div id="m_-3655154836993588012edo-message"><div>IIRC, the reason we have "class" there is for the optimiser, so it can optimise for the protocol being satisfied by a reference-counted type. Classes are semantically unique from values because they have identity, which is also something a protocol might want to codify.</div><div><br></div><div>There may be some optimisation gains by requiring all conformers to be values, but <span>I struggle to think of why you might want to codify that a conformer should not have identity.</span></div><div><span><br></span></div><div>Personally I don't really like this asymmetry in the language either, and would support changes to make these two elements more explicit. For example, a magic "hasIdentity" protocol which is automatically satisfied only by classes, and moving the optimisation guides to usage site (e.g. when declaring a variable of type MyProto, I could declare it of type AnyClass<MyProto> or AnyValue<MyProto> instead, to annotate this specific instance as being refcountable or not, without making such optimisation hints part of the MyProto definition)</div><span class="HOEnZb"><font color="#888888"><div><div id="m_-3655154836993588012edo-signature" style="font-family:'Helvetica Neue','Helvetica',Helvetica,Arial,sans-serif;font:'-apple-system-body'"></div><br><div id="m_-3655154836993588012edo-link"></div></div><div>- Karl</div></font></span></div><div id="m_-3655154836993588012edo-original"><div><br><br><blockquote type="cite" style="margin:1ex 0 0 0;border-left:1px #ccc solid;padding-left:0.5ex"><div><div class="h5"><div>On Oct 21, 2016 at 8:39 am, <<a href="mailto:swift-evolution@swift.org" target="_blank">Mike Kasianowicz via swift-evolution</a>> wrote:<br><br></div></div></div><div><div><div class="h5"><div dir="ltr">Currently protocols can have the class constraint:<div>protocol MyProtocol : class {}<br></div><div><br></div><div>It would be (a) intuitive and (b) useful to allow such things as:</div><div>protocol Model : struct {} or protocol Event : enum {}</div><div><br></div><div>These types of restrictions can help prevent accidental anti-patterns or misuse of APIs.</div><div><br></div><div>Seems simple and non-controversial... right?</div><div><br></div><div>[Note: I'd like to see even more heavy-handed protocol restrictions in the future. For example, a protocol describing an enum with a common case, or a struct with no reference members. Great stuff for defensively coding APIs.]</div></div></div></div><span class="">
______________________________<wbr>_________________
swift-evolution mailing list
<a dir="ltr" href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>
<a dir="ltr" href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a>
</span></div></blockquote></div></div></div></blockquote></div><br></div>
</div></blockquote></div></div></body></html>