<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 9, 2015, at 8:49 AM, <a href="mailto:thorsten@portableinnovations.de" class="">thorsten@portableinnovations.de</a> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">I would prefer if no "magic" methods would be generated automatically, but only when marked with @derivestandardmethods (fill in better name here).</span></div></div></div></blockquote><div><br class=""></div><div>Yes, making it opt-in could make sense.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">What about enums with more than one associated value?</span></div></div></div></blockquote><div><br class=""></div><div>It would return an optional tuple of the associated values, the tuple corresponds to the case parameter list.</div><div><br class=""></div><div>-Chris</div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">-Thorsten</span></div><div class=""><br class="">Am 09.12.2015 um 07:29 schrieb Alex Lew via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">Thanks, Chris, for all the time you're putting into responding to these proposals (and the kindness with which you're responding!). I really like that solution.<div class=""><br class=""><div class=""><div class="">Brainstorming some names for the auto-generated functions:</div><div class=""><br class=""></div><div class="">1. If a case has no associated values, isX() -> Bool is generated, where X is the case name.</div><div class=""> If a case has an associated value of type T, asX() -> T? is generated, where X is the case name.</div></div><div class=""> This mirrors is/as? operators, which return Bool / Optional respectively.</div><div class="">2. projectX() -> Bool / projectX() -> T?</div><div class="">3. isX() -> Bool / xValue() -> T?</div><div class=""><br class=""></div><div class="">Another option (probably the wrong option, but it's worth putting out there) is that instead of returning Bool in the no-associated-value case, we return ()?. This would make me feel better about using the same naming convention (asX(), projectX(), xValue(), etc.) for each case, and would allow for != nil checks on all cases. But it would probably be a little confusing for newcomers to the language.</div><div class=""><br class=""></div><div class=""><div class="">One (potentially misguided) question. I noticed in proposal 0002 (on removing function currying) that there are "plans to move away from the arguments-are-a-single-tuple model" in the near future. Would this also affect associated values of enums? That is, might</div><div class=""><br class=""></div><div class="">case Dog(name: String, age: Int, breed: String)</div><div class=""><br class=""></div><div class="">one day not have the semantics of a single associated value of type (name: String, age: Int, breed: String)? Or is the de-ML-ification planned only for function arguments?</div></div><div class=""><br class=""></div><div class="">-Alex</div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Dec 9, 2015 at 12:45 AM, Chris Lattner <span dir="ltr" class=""><<a href="mailto:clattner@apple.com" target="_blank" class="">clattner@apple.com</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 Dec 7, 2015, at 8:05 PM, Alex Lew via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">
><br class="">
> Hi all,<br class="">
><br class="">
> Curious to hear thoughts on allowing non-binding pattern matches to be used as boolean values outside of an if, guard, for...in, while, switch, etc. Something like:<br class="">
><br class="">
> enum List<T> {<br class="">
> case Empty<br class="">
> indirect case Link(T, List<T>)<br class="">
><br class="">
> func isEmpty() -> Bool {<br class="">
> return case .Empty = self<br class="">
> }<br class="">
> }<br class="">
<br class="">
</span>I agree with you that this is a problem that we should solve, but I think it could be solved in a different way. Imagine if:<br class="">
<br class="">
enum Foo {<br class="">
case X(a : Float), Y, Z(a : Int)<br class="">
}<br class="">
<br class="">
automatically synthesized these members (the exact names are just a strawman proposal, not serious :-)<br class="">
<br class="">
extension Foo {<br class="">
func isX() -> Float? {…}<br class="">
func isY() -> Bool {…}<br class="">
func isZ() -> Int? {…}<br class="">
}<br class="">
<br class="">
This would tie into all of the mechanics we have for dealing with optionals, e.g. if/let and ??<br class="">
<span class="HOEnZb"><font color="#888888" class=""><br class="">
-Chris</font></span></blockquote></div><br class=""></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=Z0lfE0AvBRKWSDAcltP5-2FwA6tH7CtZqjBw6KQdxzh8UeEAuMESPncyStoaIO7wH-2B4wV31SO34Q6zf1p5bk5X1N6Wamwdw1XtgoA2GUjK7R4hBUOHyWZg-2BtZLegj9LIGxExoBzWXlfVQymtCnuad4-2B4ejILsXtf34gw7Yp0uv4nFtyOoXqfrYeQgYDm1Rq6RUmV2Vfv6OuXZ-2FtL2xYULXhl3ZNK-2FBUrovQPS6MDg4fPg-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></blockquote></div><br class=""></body></html>