Actually this make much more sense than original proposal.
Good call!
Just to check...
Its not better this?
public enum HomeworkExcuse {
case eatenByPet
default case thoughtItWasDueNextWeek}
If i understood correctly, if the enum is not exhaustible, must be
considered as this default value after a new case be introduced in a new
version of the lib right?
And for this one:
public enum HomeworkExcuse {
case eatenByPet
case thoughtItWasDueNextWeek
fallback unknown // any word of course right?}
In this case fallback is the same as default right? But has as explicit new
label/case?
So, this is not enough?
public enum HomeworkExcuse {
case eatenByPet
fallback case thoughtItWasDueNextWeek}
If the dev wants to do make a default/fallback just use them for a regular
case, if not, if he wants to make a totally different case for a fallback
just declare another one to be the default/fallback (like unknown).
I understood your idea correctly?
Em qui, 21 de dez de 2017 às 20:48, Andrew Bennett via swift-evolution <
swift-evolution@swift.org> escreveu:
> Can you go into more detail about why the core team didn't like this?
>
> public enum HomeworkExcuse {
> case eatenByPet
> case thoughtItWasDueNextWeek
> default // NEW}
>
>
> To me this is very close to an ideal solution, it fixes ABI concerns, it
> has sensible defaults. If it was changed a little bit:
>
> public enum HomeworkExcuse {
> case eatenByPet
> case thoughtItWasDueNextWeek
> fallback unknown // NEW}
>
>
> Then I believe you would be able to have an exhaustive switch like this:
>
> switch thing {
> case eatenByPet: break
> case thoughtItWasDueNextWeek: break
> case unknown: break}
>
>
> Which would *still allow compile-time errors if new cases are introduced*,
> while providing a concise way to show something is not exhaustible.
>
> This would also *support existing enums with "unknown" equivalent cases*
> would be able to explicitly label those fields as fallback without needing
> to make large code changes.
>
> I see no reason why you shouldn't be able to use ".unknown", which *should
> still allow this to be testable*.
>
> Thanks,
> Andrew
>
> On Tue, Oct 3, 2017 at 8:10 AM, Jordan Rose via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> I don't think I have anything to say on this topic that I haven't already
>> said:
>>
>> - Switching exhaustively over non-exhaustive enums is uncommon.
>> - It's more important for a library to build without errors when its
>> dependencies change than it is to get an error. (This doesn't apply to
>> warnings, though.)
>> - Untestable code is dangerous, so having a language feature inherently
>> for untestable code seems bad.
>>
>> None of that negates your points; it just affects the weighting of
>> whether or not 'future' or 'switch!' is worth it. However, I've added a
>> link to your email in the proposal proper so that the Core Team and wider
>> review audience have a chance to decide differently.
>>
>> Jordan
>>
>>
>> On Oct 2, 2017, at 08:25, Vladimir.S via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> Sorry to bother, but I still can't understand how the proposed change
>> *without* a 'future' case in switch will change our life and what would be
>> our steps to support our code and to not make our code buggy.
>> If I misunderstand something - sorry, please point me on this and I hope
>> this also help some one like me to understand the subject better.
>>
>> For example. I use OAuth2 framework, built by Carthage. Did add the
>> OAuth2.framework to my project.
>>
>> Currently OAuth2 exports 'public enum OAuth2Error'. I do have a place in
>> my code where I switch on each case of such error instance to do my best
>> with error: generate detailed description for user, other additional steps
>> depending on error.
>>
>> Will/should author of OAuth2 make OAuth2Error 'exhaustive' ? No.
>> Will new cases be added to that enum in future: Most likely Yes.
>> Do I need to switch on each case in my code? Yes.
>> Can I currently rely on compiler to keep my error processing in sync with
>> error cases defined in framework? Yes.
>> Can new cases appear in *run-time* of my app: NO, framework in embedded.
>> Will I be able to rely on compiler after the proposed change? No?!
>> What should I do to keep my switch in sync with OAuth2Error cases after
>> each update of OAuth2 library(framework)? Manually check if new cases are
>> added?! Configure lint/other tools to help me with this?!
>>
>> What I, as a developer, as a consumer of framework, need - is a way to
>> exhaustively switch on *some* external non-exhaustive enums *at the moment
>> of compilation*. And we can accomplish this only(AFAICT) with 'future' case
>> in 'switch'.
>> In case we'll have 'future' case my life will not be *worse* for this
>> project : I'll add it to my switch and still can receive help from compiler
>> to keep switch exhaustive.
>>
>> I don't support the opinion that we can't introduce 'future' case because
>> of we can't test it:
>>
>> 1. Not being able to keep my switch exhaustive when I need this, and so
>> not being able to provide users of my app with best experience - IMO is
>> worse.
>> 2. In my particular example, 'future' case will be *never* called, if I
>> understand correctly.
>> 3. If switch on non-exhaustive enum is exhaustive by fact, we can't test
>> the 'default' branch also. So, 'future' is in same position here with
>> 'default'
>> 4. I believe if we'll decide we need 'future' case - we can suggest a way
>> to call code in that case during the test process.
>>
>> Seems like for embedded frameworks we should apply the same
>> rules(regarding enums) as for sources, as we compile the app with concrete
>> binary of framework and there just can't be new cases in enums. No?
>>
>> Thank you for your time.
>> Vladimir.
>>
>> On 01.10.2017 3:00, Slava Pestov via swift-evolution wrote:
>>
>> On Sep 30, 2017, at 4:46 PM, Karl Wagner via swift-evolution <
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org
>> <swift-evolution@swift.org>>> wrote:
>>
>> I don’t see how it’s impractical. Quite a lot about how the library
>> should be optimally compiled and used depends on what you plan to do with
>> it. If it’s going to be installed somewhere private and you can guarantee
>> clients will always have the latest version, you can assume all data types
>> are final, @_fixed_layout, @exhaustive, whatever (essentially in-module).
>> An example of that would be a library embedded inside an iOS app bundle. If
>> it’s going to be installed somewhere public and expose some API (like
>> Apple’s frameworks), then you’re going to have to think about binary
>> compatibility.
>>
>> That also means that in-app libraries are optimised as much as they can
>> be, and that resilience-related changes on the declaration side can be
>> limited to the limited set of Swift developers who truly have to care about
>> that.
>>
>> We do plan on exposing an -enable-resilience flag which basically does
>> what you describe. When a library is built without -enable-resilience, all
>> types are assumed to be fixed layout, etc. However, we don’t want language
>> flags to change language semantics, so exhaustive/nonexhaustive still make
>> sense even when building without resilience, I think. When you switch over
>> a non-exhaustive enum that came from a library built without
>> -enable-resilience, the compiler can still use the most efficient possible
>> access pattern and assume that no new cases will be introduced, but the
>> type checker would still require a default case to be present. The
>> optimizer can then basically strip out the default case as dead code.
>> Slava
>>
>>
>> - Karl
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
