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

[Andrew Bennett]

Looking into the commonly rejected proposals unions are only rejected in
the general case because they "cannot and should not" be supported by the
type system.

What I suggested is only for enums, and is possible in the type system, as
demonstrated.

On Friday, 1 July 2016, Austin Zheng <austinzheng at gmail.com
<javascript:_e(%7B%7D,'cvml','austinzheng at 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 at 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 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
>>
>> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160701/83e37d40/attachment.html>