<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 Aug 18, 2017, at 2:19 PM, Adrian Zubarev <<a href="mailto:adrian.zubarev@devandartist.com" class="">adrian.zubarev@devandartist.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="bloop_markdown" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(254, 254, 254);"><p style="margin: 15px 0px; -webkit-margin-before: 0px;" class="">Wasn’t Joe Groff and Daniel Duan proposing anonymous enum cases in some of the early draft of the ‘Normalize Enum Case Representation’ proposal?<span class="Apple-converted-space"> </span></p><p style="margin: 15px 0px;" class="">Maybe it’s time to revive that topic.</p><p style="margin: 15px 0px;" class="">Matthew Johnson has also some interesting ideas in hist gist:<span class="Apple-converted-space"> </span><a href="https://gist.github.com/anandabits/5b7f8e3836387e893e3a1197a4bf144d#structural-unions" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none; -webkit-margin-before: 0px;" class="">https://gist.github.com/anandabits/5b7f8e3836387e893e3a1197a4bf144d#structural-unions</a></p></div></div></blockquote>As far as I know that turns out to be equivalent to the commonly rejected feature. :)<br class=""><blockquote type="cite" class=""><div class=""><div class="bloop_markdown" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(254, 254, 254);"><div style="margin: 15px 0px;" class=""><br class="webkit-block-placeholder"></div></div><div class="bloop_original_html" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(254, 254, 254);"><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><br class=""></div><br class=""><div id="bloop_sign_1503083492661984000" class="bloop_sign"></div><br class=""><p class="airmail_on" style="margin: 15px 0px;">Am 18. August 2017 um 21:08:22, Robert Bennett via swift-evolution (<a href="mailto:swift-evolution@swift.org" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;" class="">swift-evolution@swift.org</a>) schrieb:</p><blockquote type="cite" class="clean_bq" style="margin: 15px 0px;"><span style="margin-top: 0px; margin-bottom: 0px;" class=""><div class=""><div class=""></div><div class="">The better solution would be to allow the creation of new enums from the union of existing enums, which was proposed recently.<br class=""><br class="">On Aug 18, 2017, at 2:36 PM, John McCall via swift-evolution <<a href="mailto:swift-evolution@swift.org" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">>> On Aug 18, 2017, at 6:36 AM, Jonathan Hull via swift-evolution <<a href="mailto:swift-evolution@swift.org" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;" class="">swift-evolution@swift.org</a>> wrote:<br class="">>> The typed throws discussion brought me back to an old thought.<br class="">>><span class="Apple-converted-space"> </span><br class="">>> I would really like to see a new structural type, similar to tuples, which act as an anonymous enum. These would actually be a distinct type from enums (not sure what to call them), in the same way that structs and tuples are different. They would have a very similar syntax to enums though, so they would be easy to learn.<br class="">><span class="Apple-converted-space"> </span><br class="">> This is the commonly-rejected "Disjunctions in type constraints" feature.<br class="">><span class="Apple-converted-space"> </span><br class="">> John.<br class="">><span class="Apple-converted-space"> </span><br class="">>><span class="Apple-converted-space"> </span><br class="">>> There would be two major difference from enums:<br class="">>><span class="Apple-converted-space"> </span><br class="">>> 1) Because they are structural, they can’t have associated functions or extensions<br class="">>><span class="Apple-converted-space"> </span><br class="">>> 2) They can concatenate with one another freely<span class="Apple-converted-space"> </span><br class="">>><span class="Apple-converted-space"> </span><br class="">>> For example:<br class="">>><span class="Apple-converted-space"> </span><br class="">>> func foo( speed: .slow | .med | .fast ){<br class="">>> bar(speed: speed)<br class="">>> }<br class="">>><span class="Apple-converted-space"> </span><br class="">>> func bar(speed: .slow | .med | .fast | .ludicrous) {<br class="">>> //but we couldn't call foo here because it doesn’t take .ludicrous<br class="">>> }<br class="">>><span class="Apple-converted-space"> </span><br class="">>> Each case is it’s own mini-type in a way. One ‘.slow’ is equivalent to any ‘.slow’ (even one from a regular enum). Essentially, it is a loosely bound group of cases, and type checking just means seeing if the list/value being passed is a subset of the list of possible cases.<br class="">>><span class="Apple-converted-space"> </span><br class="">>> I’d also like to see sugar for quick conversion from normal Swift enums:<br class="">>><span class="Apple-converted-space"> </span><br class="">>> enum Speed {<br class="">>> case slow<br class="">>> case med<br class="">>> case fast<br class="">>> }<br class="">>><span class="Apple-converted-space"> </span><br class="">>> func foo(speed: Speed | .ludicrous) {<br class="">>> //we can’t call any functions/extensions of Speed, just like we can’t call a func from int on (Int, Int)<span class="Apple-converted-space"> </span><br class="">>> }<br class="">>><span class="Apple-converted-space"> </span><br class="">>> In the above case, Speed gets converted via sugar to “.speed(Speed)” and then gets concatenated with .ludicrous. Ideally, it would have the added ability to truly convert to ".slow | .med | .fast | .ludicrous” when passed to something that doesn’t know about Speed:<br class="">>><span class="Apple-converted-space"> </span><br class="">>> func foo(speed: Speed | .ludicrous) {<br class="">>> switch speed {<br class="">>> case .speed(let s): //Do something with the Speed value<br class="">>> case .ludicrous: //Do something ludicrous<br class="">>> }<span class="Apple-converted-space"> </span><br class="">>> bar(speed: speed) //This can convert to pass by unwrapping Speed to a bag of cases<br class="">>> }<br class="">>><span class="Apple-converted-space"> </span><br class="">>> func bar(speed: .slow | .med | .fast | .ludicrous) {<br class="">>> switch speed {<br class="">>> case .slow: //<br class="">>> case .med: //<br class="">>> case .fast: //<br class="">>> case .ludicrous: //<br class="">>> }<br class="">>> //We can’t reference Speed above because we just passed a bag of potential cases<br class="">>> }<br class="">>><span class="Apple-converted-space"> </span><span class="Apple-converted-space"> </span><br class="">>><span class="Apple-converted-space"> </span><br class="">>> The end result here is that in addition to building one-off enums quickly, it lets us concatenate and extend enums for use in a limited scope. I don’t know about you, but I run into the situation of “I want exactly this enum, but with one extra case” all the time.<br class="">>><span class="Apple-converted-space"> </span><br class="">>> I don’t know if we want typed throws, but this type of quick concatability would be very useful for adding/merging potential errors. With the same sugar used on Speed above, it would also allow something similar to Union types, but without the most of the implementation headache that would cause. You can take in multiple types, and you get back something you can switch on to recover the type which was passed:<br class="">>><span class="Apple-converted-space"> </span><br class="">>> func myFakeUnion(_ intOrStr: Int | String){<br class="">>> switch intOrStr {<br class="">>> case .int(let i): //Do something with int<br class="">>> case .string(let s): //Do something with string<br class="">>> }<br class="">>> }<span class="Apple-converted-space"> </span><br class="">>><span class="Apple-converted-space"> </span><br class="">>> myFakeUnion(12) //Sugar!<br class="">>> myFakeUnion(.string(“Hey”)) //This works too<br class="">>><span class="Apple-converted-space"> </span><br class="">>><span class="Apple-converted-space"> </span><br class="">>> Finally, I would love to see the switch equivalent of ‘a ? b : c’ in Swift. I am not sure what the best syntax would be, but it would essentially work a bit like like a dictionary:<br class="">>><span class="Apple-converted-space"> </span><br class="">>> let mph = speed ? [.slow:10, .med:35, .fast:75]<br class="">>><span class="Apple-converted-space"> </span><br class="">>><span class="Apple-converted-space"> </span><br class="">>> Thanks,<br class="">>> Jon<br class="">>><span class="Apple-converted-space"> </span><br class="">>><span class="Apple-converted-space"> </span><br class="">>><span class="Apple-converted-space"> </span><br class="">>><span class="Apple-converted-space"> </span><br class="">>> _______________________________________________<br class="">>> swift-evolution mailing list<br class="">>><span class="Apple-converted-space"> </span><a href="mailto:swift-evolution@swift.org" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;" class="">swift-evolution@swift.org</a><br class="">>><span class="Apple-converted-space"> </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">><span class="Apple-converted-space"> </span><br class="">> _______________________________________________<br class="">> swift-evolution mailing list<br class="">><span class="Apple-converted-space"> </span><a href="mailto:swift-evolution@swift.org" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;" class="">swift-evolution@swift.org</a><br class="">><span class="Apple-converted-space"> </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="color: rgb(65, 131, 196); background-color: inherit; text-decoration: none;" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></span></blockquote></div><div class="bloop_markdown" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(254, 254, 254);"></div></div></blockquote></div><br class=""></body></html>