> On Jan 2, 2018, at 3:41 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>
> On Tue, Jan 2, 2018 at 3:27 PM, Kevin Nattinger <sw...@nattinger.net
> <mailto:sw...@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. 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").
>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
