[swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

[Zach Waldowski]

On Tue, Dec 19, 2017, at 5:58 PM, Ted Kremenek wrote:
>  * What is your evaluation of the proposal?
+1.

I strongly prefer all additions to service ABI follow progressive
disclosure, but it’s not reason alone to make the annotation be mystery
meat. Like the inlining proposal, the spelling needs some consideration
by the core team to provide an ergonomic through-line through the
language. I liked reusing `final` way back when the proposal first came
up, but that ship appears to have sailed. If an annotation is our
preference, I do like `@frozen` if we see it come up in interesting ways
elsewhere.
>  * Is the problem being addressed significant enough to warrant a
>    change to Swift?
I see this proposal and its discussion mostly as prevarication on the
spelling and the default behavior. Those aside, it solves a bug, so bar-
none something must be done. In a perfect world, no annotation or
closed/open would be needed, but this is unrealistic, and a solution
that involves compile-time diagnostics over runtime failures is
preferable.
>  * Does this proposal fit well with the feel and direction of Swift?
ABI stability is a high-level goal, and this fits within it.

The Core Team and Apple could do a better job with messaging its
compatibility impact. Though I understand it now, changing a feature’s
behavior is indeed surprising at this point. My understanding is that
nothing will change for creating enums in the single target happy path,
with a stretch goal being to extend that to all  source targets that
produce a single (in Apple terminology) bundle. I know y’all can’t
discuss future dev tools directions, but it may have helped us to know
the plan for what constitutes the compiler “seeing” an enum’s source to
make a resilience decision.
>  * If you have used other languages or libraries with a similar
>    feature, how do you feel that this proposal compares to those?
I’m most familiar if the impact of this problem on ObjC, where it was
only really solved for Apple. We’re forging new territory for solving
this at the ABI level for any binary module, so some uncertainty is to
be expected.
>  * How much effort did you put into your review? A glance, a quick
>    reading, or an in-depth study?
I’ve followed the proposal in depth since its early stages.

Sincerely,
  Zachary Waldowski
  zach at waldowski.me
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171227/2044189f/attachment.html>