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

[Xiaodi Wu]

On Tue, Jan 2, 2018 at 8:25 PM, Matthew Johnson <matthew at anandabits.com>
wrote:

>
> On Jan 2, 2018, at 3:41 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> On Tue, Jan 2, 2018 at 3:27 PM, Kevin Nattinger <swift at nattinger.net>
> wrote:
>
>> [...]
>>
>> in what other circumstances do we insist that the compiler inform the end
>>> user about future additions to the API at compile time?
>>>
>>>
>>> This isn’t a request for the compiler to inform the user about future
>>> additions to an API.  It is a request to validate the compiler’s knowledge
>>> of the *current* state of an API with the *current* state of the source
>>> code.
>>>
>>
>> Well, it's of course impossible to inform the user about future
>> additions, so that's poorly phrased on my part. It's about the compiler
>> informing the end user about *new* additions, part of the *current* state
>> of the API, that have cropped up since the user last revised the code when
>> the API was in a *previous* state (or, indistinguishably, members of which
>> a user is unaware regardless of the temporal sequence of when such members
>> were added). In what other circumstances do we insist that the compiler
>> perform this service?
>>
>>
>> Enums. That's literally how they work today. You are arguing in favor of
>> actively removing compiler-aided correctness.
>>
>> There's also protocol requirements
>>
>
> No, that's now how enums work today, and it's not how protocol
> requirements work today. Enums today are all semantically exhaustive; if a
> case is added in a later version of a library, it's semantically a
> *different* enum type that happens to share the same name. Not considering
> all the cases of an exhaustive enum is an _error_, not a _warning_, because
> there is no basis on which to proceed. This will not change with the
> proposal. Likewise, adding a protocol requirement without a default
> implementation is source-breaking. The result is a compiler _error_.
>
> The question is, what non-source breaking API additions today cause the
> compiler to inform the end user of such additions?
>
>
> Posing the question this way takes it as a given that adding a case to a
> resilient enum is non-source breaking with a full stop.
>

Ah, yes. As I wrote in an earlier email in reply to Jon and others, it
seems we have a fundamental difference here. I take it as a given, full
stop, that this is what we are setting out to do. If it is not, then we are
trying to design with different end goals in mind.

The position of everyone asking for something like `future` / `unknown` as
> an alternative to `default` is exactly that this should not be the case.
> Instead, adding a case should always be binary compatible and should be
> source compatible by default, but authors should have the ability to opt-in
> to making case additions be source-breaking for individual switch
> statements.
>
> When you view it this way we are not asking the compiler to inform us of a
> non-source breaking addition.  We are asking the compiler to treat an
> addition as source breaking in a specific context.
>
> The answer is: none whatsoever. Not new methods or properties on a type,
> not even new protocol requirements that have a default implementation.
>
>
> and, arguably, deprecated methods with a proper message ("use foo
>> instead").
>>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20180102/e5d58a6e/attachment.html>