Doesn’t this imply more performance cost? Don’t get me wrong but the value here is not fixed and computed all over again which might waste resources if the calculation is complicated. Sure we could build some workarounds here and there, but the codebase won’t get any prettier after that.
Another though is that enums just need stored properties to solve the main problem here nicely. I don’t remember what the outcome of that talk was back then. I’ll search for that conversation soon. Anyways, thank you Joe for showing us the possible workaround. -- Adrian Zubarev Sent with Airmail Am 4. Oktober 2016 um 19:52:11, Joe Groff ([email protected]) schrieb: On Oct 3, 2016, at 12:50 PM, Adrian Zubarev via swift-evolution <[email protected]> wrote: Hi there, I’m interested if this idea has some potential future in Swift or not. Currently RawRepresentable enums accept only a subset of literal types like String, Character and the Integer family (enum Name : String { … }). Sometimes this is not enough for my use-case and I wish I could feed my enums with other Hashable types! As a workaround I can create a custom struct or even a class and conform it to RawRepresentable and fake an enum with some static variables (similar to what is done with OptionSet types). The literal type constraint only affects the sugar syntax using the ': String' and 'case X = 1' syntax. If you write an enum's conformance explicitly, you can use any raw type you like: enum Test: RawRepresentable { case something, nothing init?(rawValue: A) { switch rawValue.value { case "something": self = .something case "nothing": self = .nothing default: return nil } } var rawValue: A { switch self { case .something: return A(value: "something") case .nothing: return A(value: "nothing") } } } though it's up to you at this point to guarantee the 1:1 correspondence between raw values and enum values that RawRepresentable assumes. -Joe The problem there is that I cannot use the same switch pattern matching like with enums. I’d wish either enums could accept Hashable types (maybe with some restriction) or the existence on a protocol to build custom enum-like types with strucs/classes and use the same switch pattern matching. struct A : Hashable { /* implement everything */ } // Variant 1: enum Test : A { case something = A(rawValue: A(value: "something")) case nothing = A(rawValue: A(value: "nothing")) } // Variant 2: protocol SomeFancyName : RawRepresentable { … } struct Test : SomeFancyName { let rawValue: A init?(rawValue: A) { // Implement + reject unwanted `A`s } static let something = A(rawValue: A(value: "something")) static let nothing = A(rawValue: A(value: "nothing")) } let value = Test.something switch value { case .something: // handle case .nothing: // handle // Because of `SomeFancyName` the switch can use enum-like pattern matching + does not need the `default` case when all cases are present } -- Adrian Zubarev Sent with Airmail _______________________________________________ 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
