On Tue, Jan 2, 2018 at 3:27 PM, Kevin Nattinger <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? 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
