<div dir="ltr">Hooray, I'm not the only one.<div><br></div><div>I agree copying is a much more nuanced issue- but sometimes struct is close enough. </div><div><br></div><div>What I would really like is "this is a data-only type" rather than "struct". But short-term, I'd take the struct restriction if it's a simple change. If we ever had a more specific constraint like that, my hypothetical API will break many more clients if people have implemented my protocol as a class. I'm considering runtime enforcement, but this is clearly something that the compiler can do, and the question is whether it should. I would argue yes - one of the great things about Swift is getting your head out of the technical weeds and thinking at a higher level.</div><div><br></div><div>Protocol-oriented programming could be much more concise and allow for some really awesome high-level things to be done and enforced - ex: MVC, MVVM, MVP, VIPER whatever your UI approach is today - you could codify the infrastructural paradigm and then require data-only types for the models, or enum-only types for the events, to prevent dependency violations. Great for making frameworks safer, enforcing coding standards, etc.</div><div><br></div><div>Maybe long-term there could be user-defined constraints similar to the proposed property decorator/annotation notation? </div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 21, 2016 at 11:38 AM, T.J. Usiyan <span dir="ltr"><<a href="mailto:griotspeak@gmail.com" target="_blank">griotspeak@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 dir="ltr">I would like the ability to specify that something is an enum so that I could model a generic `Result` type. <div><br></div><div>```</div><div>protocol Result : enum {</div><div> associatedtype Payload</div><div> case success(Payload)</div><div> case failure(Error)</div><div>}</div><div>```</div><div><br></div><div>the basic idea being that I could then, while conforming, state which cases in the concrete type serve as the protocol's case. I don't have a great vision for the syntax of spelling this conformance so I will make this painfully verbose to be clear</div><div><br></div><div>```</div><div>enum UserParseResult {</div><div> case success(User)</div><div> case failure(Error)</div><div>}</div><div><br></div><div>extension UserParseResult : Result {</div><div> protocol(Result) case success = UserParseResult.success</div><div> protocol(Result) case failure = UserParseResult.failure<br></div><div>}</div><div>```</div><div><br></div><div><br></div><div>The benefit of this, in my opinion, is that we could have code commonly used on results everywhere written once on the protocol without sacrificing the ability to switch with guarantees. I can see that this suggestion has some rough points so all I will finish by restating the problem that I want to solve. </div><div><br></div><div>There is code that is fairly common to enum types that have shared characteristics and/or purpose. I would find it useful to have a way to implement shared algorithms in a generic way while retaining core features of enums.</div></div><div class="m_218923446769591141m_3080819724774828764HOEnZb"><div class="m_218923446769591141m_3080819724774828764h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 21, 2016 at 11:11 AM, Mike Kasianowicz via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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="m_218923446769591141m_3080819724774828764m_2457637474634150925HOEnZb"><div class="m_218923446769591141m_3080819724774828764m_2457637474634150925h5"><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_218923446769591141m_3080819724774828764m_2457637474634150925m_-4430716572333047373m_-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="m_218923446769591141m_3080819724774828764m_2457637474634150925m_-4430716572333047373HOEnZb"><font color="#888888"><div><div id="m_218923446769591141m_3080819724774828764m_2457637474634150925m_-4430716572333047373m_-3655154836993588012edo-signature" style="font-family:'Helvetica Neue','Helvetica',Helvetica,Arial,sans-serif;font:'-apple-system-body'"></div><br><div id="m_218923446769591141m_3080819724774828764m_2457637474634150925m_-4430716572333047373m_-3655154836993588012edo-link"></div></div><div>- Karl</div></font></span></div><div id="m_218923446769591141m_3080819724774828764m_2457637474634150925m_-4430716572333047373m_-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="m_218923446769591141m_3080819724774828764m_2457637474634150925m_-4430716572333047373h5"><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="m_218923446769591141m_3080819724774828764m_2457637474634150925m_-4430716572333047373h5"><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>
______________________________<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/mailma<wbr>n/listinfo/swift-evolution</a>
</span></div></blockquote></div></div></div></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>