What's your use case for distinguishing structs and enums?<br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 21, 2016 at 1:40 AM Mike Kasianowicz via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg">Currently protocols can have the class constraint:<div class="gmail_msg">protocol MyProtocol : class {}<br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">It would be (a) intuitive and (b) useful to allow such things as:</div><div class="gmail_msg">protocol Model : struct {} or protocol Event : enum {}</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">These types of restrictions can help prevent accidental anti-patterns or misuse of APIs.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Seems simple and non-controversial... right?</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">[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>
_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>