> On Dec 20, 2017, at 05:36, Karl Wagner via swift-evolution > <swift-evolution@swift.org> wrote: > > > >> On 19. Dec 2017, at 23:58, Ted Kremenek via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through >> January 3, 2018. >> >> The proposal is available here: >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md >> >> <https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md>+1, >> it needs to happen (and ASAP, since it _will_ introduce source-breaking >> changes one way or the other). > > I think non-exhaustive is the correct default. However, does this not mean > that, by default, enums will be boxed because the receiver doesn’t know their > potential size?
It's not always boxing, but yes, there will be more indirection if the compiler can't see the contents of the enum. (More on that below.) > That would mean that the best transition path for multi-module Apps would be > to make your enums @exhaustive, rather than adding “default” statements > (which is unfortunate, because I imagine when this change hits, the way > you’ll notice will be complaints about missing “default” statements). Yep, that's going to be the recommendation. The current minimal-for-review implementation does not do this but I'd like to figure out how to improve that; at the very least it might be a sensible thing to do in the migrator. > > I do have some thoughts about how we could ease the transition (for this and > other resilience-related changes), but it’s best to leave that to a separate > discussion. > > The one thing I’m still not overly fond of is the name - I would like us to > keep the set of resilience/optimisation related keywords to a minimum. > “exhaustive” for enums feels an awful lot like “fixed_contents” for structs - > couldn’t we come up with a single name which could be used for both? I don’t > think anybody’s going to want to use “exhaustive” for structs. The core team was very focused on this too, but I contend that "exhaustive" is not about optimization and really isn't even about "resilience" (i.e. the ability to evolve a library's API while preserving binary compatibility). It's a semantic feature of an enum, much like 'open' or 'final' is for classes, and it affects what a client can or can't do with an enum. For libaries compiled from source, it won't affect performance at all—the compiler still knows the full set of cases in the current version of the library even if the programmer is forced to consider future versions. I'm working on the fixed-contents proposal now, though it won't be ready for a while, and the same thing applies there: for structs compiled from source, the compiler can still do all the same optimizations. It's only when the library has binary compatibility concerns that we need to use extra indirection, and then "fixed-contents" becomes important. (As currently designed, it doesn't affect what clients can do with the struct at all.) This means that I don't expect a "normal" package author to write "fixed-contents" at all (however it ends up being spelled), whereas "exhaustive" is a fairly normal thing to consider whenever you make an enum public. I hope that convinces you that "fixed-contents" and "exhaustive" don't need to have the same name. I don't think anyone loves the particular name "exhaustive", but as you see in the "Alternatives considered" we didn't manage to come up with anything significantly better. If reviewers all prefer something else we'd consider changing it. Thanks for responding! Jordan
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
