[swift-evolution] [Pitch] Synthesized static enum property to iterate over cases

[Tony Allevato]

On Sat, Sep 9, 2017 at 11:36 AM Matthew Johnson via swift-evolution <
swift-evolution at swift.org> wrote:

>
>
> Sent from my iPad
>
> On Sep 9, 2017, at 11:42 AM, gs. <griotspeak at gmail.com> wrote:
>
> How does fragility play into this? Does this only work for fragile
> (closed) and internal/private/fileprivate enums?
>
>
> That's a great question.  I think it would have to have that limitation.
> Using Jordan's terminology, by definition a nonexhaustive cannot provide a
> complete list of all values.
>

This one is tougher for me to make a call. I definitely see the point of
view that says that if a nonexhaustive enum doesn't provide a complete
list, then it would make sense to not synthesize it. On the other hand,
some nonexhaustive enums may still benefit from that. For example, I've
been tinkering with wrapping the ICU APIs in Swift, and I have an enum for
Unicode code blocks
<https://github.com/allevato/icu-swift/blob/master/Sources/ICU/Block.swift>.
That would be a good candidate for a nonexhaustive enum because the spec is
always growing, but it would still be very useful to have the compiler
synthesize the collection and count for me (for example, to display in a
table), especially since it is large.



>
>
> TJ
>
>
> On Sep 9, 2017, at 15:23, Matthew Johnson via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
>
> Sent from my iPad
>
> On Sep 9, 2017, at 7:33 AM, Brent Royal-Gordon <brent at architechies.com>
> wrote:
>
> On Sep 8, 2017, at 5:14 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Here, people just want an array of all cases. Give them an array of all
> cases. When it's not possible (i.e., in the case of cases with associated
> values), don't do it.
>
>
> I agree it should be Int-indexed; that seems to be what people want from
> this.
>
> I seem to recall that there is information about the available enum cases
> in the module metadata. If so, and if we're willing to lock that in as part
> of the ABI design, I think we should write—or at least allow for—a custom
> Int-indexed collection, because this may allow us to recurse into
> associated value types. If we aren't going to have suitable metadata,
> though, I agree we should just use an Array. There are pathological cases
> where instantiating a large Array might be burdensome, but sometimes you
> just have to ignore the pathological cases.
>
> (The "infinite recursion" problem with associated values is actually
> relatively easy to solve, by the way: Don't allow, or at least don't
> generate, `ValuesEnumerable` conformance on enums with `indirect` cases.)
>
>
> This is the direction I think makes the most sense in terms of how we
> should approach synthesis.  The open question in my mind is what the exact
> requirement of the protocol should be.  Should it exactly match what we
> synthesize (`[Self]` or an associated `Collection where Iterator.Element ==
> Self, Index == Int`) or whether the protocol should have a more relaxed
> requirement of `Sequence where Iterator.Element == Self` like Tony proposed.
>
>
> --
> Brent Royal-Gordon
> Architechies
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> 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/20170909/f7ecb5c5/attachment.html>