[swift-evolution] Allowing enum extensions to also be able to expand case options

[Andrew Bennett]

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 at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160701/c0d9a110/attachment.html>