The better solution would be to allow the creation of new enums from the union of existing enums, which was proposed recently.
On Aug 18, 2017, at 2:36 PM, John McCall via swift-evolution <[email protected]> wrote: >> On Aug 18, 2017, at 6:36 AM, Jonathan Hull via swift-evolution >> <[email protected]> wrote: >> The typed throws discussion brought me back to an old thought. >> >> 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. > > This is the commonly-rejected "Disjunctions in type constraints" feature. > > John. > >> >> There would be two major difference from enums: >> >> 1) Because they are structural, they can’t have associated functions or >> extensions >> >> 2) They can concatenate with one another freely >> >> For example: >> >> func foo( speed: .slow | .med | .fast ){ >> bar(speed: speed) >> } >> >> func bar(speed: .slow | .med | .fast | .ludicrous) { >> //but we couldn't call foo here because it doesn’t take .ludicrous >> } >> >> 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. >> >> I’d also like to see sugar for quick conversion from normal Swift enums: >> >> enum Speed { >> case slow >> case med >> case fast >> } >> >> func foo(speed: Speed | .ludicrous) { >> //we can’t call any functions/extensions of Speed, just like we can’t >> call a func from int on (Int, Int) >> } >> >> 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: >> >> func foo(speed: Speed | .ludicrous) { >> switch speed { >> case .speed(let s): //Do something with the Speed value >> case .ludicrous: //Do something ludicrous >> } >> bar(speed: speed) //This can convert to pass by unwrapping Speed to a >> bag of cases >> } >> >> func bar(speed: .slow | .med | .fast | .ludicrous) { >> switch speed { >> case .slow: // >> case .med: // >> case .fast: // >> case .ludicrous: // >> } >> //We can’t reference Speed above because we just passed a bag of >> potential cases >> } >> >> >> 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. >> >> 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: >> >> func myFakeUnion(_ intOrStr: Int | String){ >> switch intOrStr { >> case .int(let i): //Do something with int >> case .string(let s): //Do something with string >> } >> } >> >> myFakeUnion(12) //Sugar! >> myFakeUnion(.string(“Hey”)) //This works too >> >> >> 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: >> >> let mph = speed ? [.slow:10, .med:35, .fast:75] >> >> >> Thanks, >> Jon >> >> >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
