> On Dec 19, 2017, at 3:58 PM, Ted Kremenek via swift-evolution
> <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>
> When reviewing a proposal, here are some questions to consider:
>
> What is your evaluation of the proposal?
>
A very strong -1. I do not believe this is the appropriate solution to the
problem.
• While the goal of the proposal is to ensure the correctness of *client* code,
it does nothing to enforce the correctness of evolving *library* code. As a
library author, I can declare a public enum as “exhaustive”, yet still add a
new case in the next release. Nothing in the proposal prevents me from doing
this, yet doing so would obviously break any clients of my library.
• The name “exhaustive” is misleading for uninformed library authors. An author
creates an enum and then thinks “is that all of the cases? Yep! OK, it’s
@exhaustive”. Then the next evolution of the library occurs, new cases arise,
and now the enum isn’t exhaustive to handle the new cases. So a case gets
added, and the formerly-but-not-actually-exhaustive enum is re-stamped as
exhaustive, because it once again handles all known cases. “Exhaustive” is not
a strong enough name. It does not contain the idea of eternal permanence. Once
an enum gets branded as exhaustive and shipped as such, *it can never change*.
“Exhaustive” does not imply that, and the lack of that implication will confuse
library authors.
• This proposal does not address the case of “publicly exhaustive enums with
private cases”. Consider NSExpression.ExpressionType: when creating
NSPredicates from format strings, it is easy to create sub-expressions whose
expression types are not one of the publicly listed cases. Based on the
proposal, NSExpression.ExpressionType would be correctly imported as a
non-exhaustive enum. HOWEVER. There is nothing *stopping* a library author from
declaring a publicly exhaustive enum (like NSExpression.ExpressionType), but
having private cases that get leaked (accidentally or not) past the public
barrier and end up in client code. This proposal does nothing to prevent that.
The summary of these objections is this: you fundamentally cannot trust
libraries that are not bundled with your application to not change in
unexpected ways. Or in other words, if you don’t have the source code, you
cannot trust it. And even if you do have the source code, it’s still
questionable once you start bridging things in from other languages where this
sort of safety is not enforced.
To summarize the summary: Leaving a judgement of “exhaustive or not” up to
fallible library authors isn’t safe.
To summarize the summary of the summary: people are a problem.
> Is the problem being addressed significant enough to warrant a change to
> Swift?
>
Yes, the problem is significant, but in my opinion this is the wrong answer.
> Does this proposal fit well with the feel and direction of Swift?
>
No. Implementing this proposal would give the appearance of safety while still
leaving developers subtly but dangerously vulnerable to imperfectly written
libraries (ie, all of them).
> How much effort did you put into your review? A glance, a quick reading, or
> an in-depth study?
>
I’ve been following the email threads, and I’ve spent years as a library
author, both on Apple frameworks and my own personal libraries.
Dave
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
