<html><body><div id="edo-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 style="-webkit-tap-highlight-color: transparent; -webkit-text-size-adjust: auto;">I struggle to think of why you might want to codify that a conformer should not have identity.</span></div><div><span style="-webkit-tap-highlight-color: transparent; -webkit-text-size-adjust: auto;"><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><div><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>- Karl</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 8:39 am, <<a href="mailto:swift-evolution@swift.org">Mike Kasianowicz via swift-evolution</a>> wrote:<br><br></div><div><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>
_______________________________________________
swift-evolution mailing list
<a dir="ltr" href="mailto:swift-evolution@swift.org" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="1">swift-evolution@swift.org</a>
<a dir="ltr" href="https://lists.swift.org/mailman/listinfo/swift-evolution" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="2">https://lists.swift.org/mailman/listinfo/swift-evolution</a>
</div></blockquote></div></div></body></html>