> On Apr 22, 2016, at 11:11 PM, Jacob Bandes-Storch <jtban...@gmail.com> wrote:
> On Fri, Apr 22, 2016 at 10:50 PM, John McCall <rjmcc...@apple.com
> <mailto:rjmcc...@apple.com>> wrote:
>
> I have not been following this discussion, but I would be extremely antsy
> about guaranteeing any particular representation for the set of values.
> Guaranteeing a contiguous array implementation seems like a really bad idea,
> especially if that's taken to mean that we're going to actually provide a
> static global array. But there's no way to avoid providing a public API,
> because a public conformance itself implies a public API with some level of
> corresponding overhead.
>
> A "compiler magic" version of the feature, like #allValues(MyEnum), could
> generate a static array *internal* to the caller's module, but I'm sure there
> are implications or details of this which I'm not aware of.
That cannot be reconciled with resilience. The caller cannot reliably know the
set of stored cases; only the defining module can.
For similar reasons, only the defining module can be allowed to magically
derive a conformance to your protocol, if indeed it's done with a protocol.
> I don't remember the details of Java enums from my days as a Java programmer,
> but reading between the lines of your description, it sounds to me like Java
> originally made overly-strong guarantees that it decided to walk back in a
> later release. That's a lesson we should heed.
>
> Maybe I missed something, but that's not how I interpreted it. The guarantee
> was/is simply that getEnumConstants() returns the values in source order. If
> the class being loaded changes (excuse my Java ignorance if that's the wrong
> terminology), you may end up with different results at runtime, but it's
> still an array of the values in the order they're defined in the class. Of
> course, Java enums seem to be much simpler (they can have payloads/members,
> but the values are fixed for the cases you define at compile-time).
I see. Yes, they're just saying that getEnumConstants makes a stronger
guarantee.
> I just noticed there's a MyEnum.values() method too, but it seems to do the
> same thing as getEnumConstants().
> <http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html
> <http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html>>
Note that getEnumConstants() has to create a new array every time, since Java
arrays are mutable and have reference semantics.
> The interaction of resilience with enums is in principle quite
> straightforward: you ought to be able to arbitrarily change the set of stored
> cases for a resilient enum. That includes adding cases, changing existing
> cases to be "computed", and so on. (We haven't yet designed what it ought to
> mean for a case to be computed, but I assume it at least means providing an
> injector (Payload -> Enum) and a projector (Enum -> Payload?); whether and
> how to allow computed cases to factor into exhaustiveness checking is a
> separate but crucial question.) The fundamental problem for features like
> this is that adding a case with a payload is not compatible with actually
> being enumerable, outside of special cases and/or some formal-but-useless
> notion of recursive enumerability. But even if you couldn't add new cases
> with payloads (which is something we might consider adding as an intermediate
> opt-in constraint), and thus the type was necessarily finite, I can't imagine
> wanting to promise to return a static global array.
>
> Non-"simple" enums (those with cases with payloads, generic enums, etc.) are
> out of scope for this proposal. There are multiple ways in which you might
> want them to be "enumerable", and anyway, it seems like a job for better
> reflection. There's some discussion in the "Future directions" section at the
> bottom (which I'll probably remove):
> <https://github.com/jtbandes/swift-evolution/blob/case-enumerable/proposals/0000-derived-collection-of-enum-cases.md
>
> <https://github.com/jtbandes/swift-evolution/blob/case-enumerable/proposals/0000-derived-collection-of-enum-cases.md>>
> For now we'd like to start with something simple but functional.
I have no idea why you're ruling out generic enums if you're ruling out enums
with payloads.
John.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
