Ah right, sorry. In that case I don't see this happening, it would likely
introduce undefined behaviour.
···
On Friday, 1 July 2016, Austin Zheng <austinzheng@gmail.com> wrote:
Unions are a no-go.
https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md
On Jun 30, 2016, at 5:00 PM, Andrew Bennett via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:
How many of these use cases would be safely addressed if two Enum types
could be unioned to form a new type?It could use syntax similar to what is being proposed for existentials:
(A|B), or something like this:enum C: A, B {}
Swift could generate code like this:
enum A {
case A1, A2
}
enum B {
case B1, B2
}
enum C {
case A(Module.A)
case B(Module.B)init(_ a: Module.A) { self = .A(a) }
init(_ b: Module.B) { self = .B(b) }static let A1 = C(A.A1)
static let A2 = C(A.A2)
static let B1 = C(B.B1)
static let B2 = C(B.B2)
}
extension A {
init?(_ c: C) {
guard let case .A(a) = c else { return nil }
self = a
}
}
extension B {
init?(_ c: C) {
guard let case .B(b) = c else { return nil }
self = b
}
}If I remember correctly there was already some proposals like this, they
are probably more thought out than this suggestion. I know I'd find that
useful, I don't think I'd want the exhaustibility implications of extending
an enum in another module.On Friday, 1 July 2016, Marc Palmer via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:
Hi,
I too groan when faced with the lack of extensibility on enums. As a
potential framework writer, I'd like to be able to use an enum as a key to
dictionaries, supplying a minimum set of such enum cases, but allowing app
developers to add new ones they require.Having read the proposal however, I have a major concern and question the
entire idea.Given that there is unlikely to be a sane way to order the extended enum
cases supplied by other modules, we will never be able to rely on the
automatic ordinal values applied, nor their relative position in the
natural sequence, for there isn't one outside of the first set of cases in
the original definition.For many cases this may be fine, on the understanding that everything
would have to compile from source, but my understanding is that we don't
want that in future with ABI around the corner. Binary libraries would
probably need to bake in the value of e.g. Int enum cases. (I think?)I fear that if this proposal were implemented without some major
restrictions (such as never allowing use of rawValue), we would regret it
and suffer for example having to explicitly set enum case Int raw values
for every case in these enums in every module always, and suffer
compilation errors when other (maybe binary) modules change their explicit
raw values and clash with other modules. It could be a dependency nightmare.Essentially consigning extensible enums to never being useful for
serialising their raw values seems of limited use to me, as often you may
not know you need them to have unmoving raw values until it is too late and
your code is in the wild.Perhaps I am missing some secret sauce?
--
Marc Palmer_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution