> On Sep 17, 2017, at 5:04 PM, BJ Homer <bjho...@gmail.com> wrote:
>
> Please note that, as proposed, enums are always treated as exhaustive *within
> the same module*. A new user writing MyFirstEnum is likely using it within
> the same module, and will thus get exhaustive behavior with no extra keywords
> required.
• What is your evaluation of the proposal?
Uh, +1
• How much effort did you put into your review? A glance, a quick reading, or
an in-depth study?
not enough
Apologies for wasting everyone’s time...
> -BJ
>
> On Sep 17, 2017, at 3:20 PM, Christopher Kornher via swift-evolution
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
>>
>>> On Sep 17, 2017, at 6:33 AM, Rod Brown via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>
>>>
>>>> On 17 Sep 2017, at 4:35 am, Christopher Kornher <ckorn...@me.com
>>>> <mailto:ckorn...@me.com>> wrote:
>>>>
>>>>> On Sep 16, 2017, at 11:28 AM, Christopher Kornher via swift-evolution
>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>
>>>>> If a library writer can’t remember to declare non-exhaustive enums as
>>>>> such, they probably will forget many more important aspects of creating a
>>>>> library. They probably should not be writing libraries. Arguments like
>>>>> this make sense on the surface, but creating libraries involves hundreds
>>>>> or thousands of decisions. I wish you luck in making that process idiot
>>>>> proof. A library linter could easily warn that exposed enums are
>>>>> exhaustive. The exhaustive keyword should be optional to make the
>>>>> decision obvious and suppress warnings. Complicating the user experience
>>>>> in a vain attempt to make “expert" coding safer is misguided.
>>>
>>> I think the same logic goes both ways: If a library author can’t remember
>>> to declare exhaustive enums as such, they will probably forget many more
>>> important aspects of creating a library.
>>>
>>> The problem here is fundamental: Exhaustive is a guarantee. A guarantee
>>> should require action. Non-Exhaustive guarantees nothing. It makes you
>>> safer. That is all.
>>
>> 1) Exhaustive enums are inherently better: they allow a developer to know
>> that they have covered all possible cases by not using a default.
>> 2) This proposal forces developers to add a keyword to get this behavior in
>> their apps, which is common to all other languages with enums that I have
>> used. This proposal breaks the model common to all (?) current
>> implementations of enums.
>>
>>
>>>
>>>>
>>>> This may be a little harsh, but there don’t seem to be many advocates for
>>>> novice and “ordinary” application developers on this list. That is not
>>>> unexpected given the number of extremely knowledgeable compiler and
>>>> library developers on this list (for whom I have the highest respect). I
>>>> believe that there are more creative (and probably more difficult to
>>>> build) possible solutions to some of the tough problems in Swift’s future.
>>>> In that spirit, see below.
>>>
>>> I personally am an “ordinary” application developer.
>>>
>>> I think the issue here is that everyone is seeing Swift as *they* intend to
>>> use it. For App Devs, exhaustive switches are nice, which means they really
>>> are fighting tooth and nail to keep them. I understand that. But I’m also
>>> trying to keep my mind open for “what happens to an app I compiled in iOS
>>> 15 that I compiled for iOS 11?” And this gives me pause. I can’t ask Apple
>>> or any other library author to be completely knowledgable about every case
>>> in the future, and to audit every line of code and manually give
>>> non-exhaustive.
>>>
>>> Why do people want “exhaustive” to be the default?
>>> Because we like things as they are.
>>
>> No, because it makes sense to make common things easy and uncommon things
>> possible.
>>
>>> Because we like not having to consider edge cases. Because we want to
>>> imagine that will give framework developers the control to make our lives
>>> difficult because they’ll just be lazy and make our lives hard by not
>>> annotating. And this certainly is a concern. But I think a larger concern
>>> is breaking apps left, right and centre, or not being able to extend
>>> frameworks because an earlier developer on a project made an oversight.
>>
>> This happens all the time: Apple deprecates APIs and asked developers to use
>> new ones. If a library writer does not run (the as-yet hypothetical )
>> library lint, not participate in thorough code reviews,…, they can simply
>> create a new non-exhaustive enum and deprecate the old one. Yes, there will
>> be some redundant function calls for a while, but again, similar things
>> happen, even in APIs like Apple’s, that (one hopes, at least) are thoroughly
>> reviewed. It is not the end of the world to deprecate and migrate APIs. You
>> may remember garbage collected Objective-C, the change that “viewWillAppear”
>> suddenly was not called when it used to be in iOS. We all survived the
>> elimination of GC and moving our view initialization code. Libraries and
>> developers can survive mistakes and improvements.
>>
>> ABI stability does not require foolproof, immutable, ABIs. In essence, it is
>> just a guarantee that the build system won’t require rebuilds if library
>> source code stays the same, or is added to, not that applications will never
>> have to be rebuilt in the real world where breaking changes are often
>> required. Adding ABI stability when enums change (in limited ways, don’t
>> forget, removing a case is a breaking change) is a good addition, but it
>> does not rise to the level of requiring degradation of the experience for
>> beginners, IMO.
>>
>>
>>> Its in everyone’s best interest to think before we put handcuffs on, no
>>> matter how painful that is. Even if that means you make apps where you just
>>> write “default: fatalError(“I don’t handle unreachable defaults”)"
>>>
>>> And lets be clear: Swift isn’t an app development language. It also isn’t a
>>> framework development language. It’s a multipurpose language designed to
>>> Take Over The World™. This means we need to think holistically about what
>>> is better for everyone. Not just ourselves.
>>
>> That includes being easy to learn and understand. Enums are exhaustive in
>> other languages and should be exhaustive by default in Swift. No extra
>> keywords should be required to create “MyFirstEnum” that behaves in a
>> sensible way. The documentation that describes why you need to write a
>> ‘default’ clause or 'exhaustive' when you have all the possible cases
>> written down should be interesting. May I suggest: “You see, if you write a
>> library (don’t worry about what that means right now) you don’t have to
>> worry about being not very good at it. If and when you write one, it will be
>> a tiny bit easier, so write this meaningless clause or the magical keyword —
>> your choice.”
>>
>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> If you declare it is exhaustive and it was an oversight, and then
>>>>>> realise after the fact that you are wrong, you have to open it up. This
>>>>>> will break third party apps. It will be disallowed by the ABI
>>>>>> compatibility requirements.
>>>>>>
>>>>>> If you declare it isn’t exhaustive due to an oversight (or perhaps
>>>>>> you’re just not sure yet), and then realise after the fact it is
>>>>>> exhaustive, you can close it up. This will not break third party apps.
>>>>>> It will also be allowed for ABI compatibility.
>>>>>>
>>>>>> This benefits everyone. Make library owners choose a guarantee, rather
>>>>>> than be defaulted into it. Much like they have to declare choose to
>>>>>> declare “final” on a class: you can’t retroactively reneg that promise:
>>>>>> it will break everyone who assumed it to be the case!
>>>>>
>>>>> It does not benefit the creation of 90+% of enums. It is one more arcane
>>>>> rule for the vast majority of developers.
>>>>
>>>> The Swift compiler could offer a “strict enum exhaustiveness”
>>>> (bikeshedding not included) switch that could be enabled by default for
>>>> library targets and disabled by default for “application” targets. The
>>>> switch would make not explicitly specifying exhaustiveness an error or
>>>> warning when enabled. Perhaps this could be combined with other options
>>>> that would tailor the development experience for library/application
>>>> developers. This would help avoid “zero-sum” choices between benefitting
>>>> library or application developers in the future.
>>>
>>> The Swift team have fundamentally opposed such pushes for “compiler modes”
>>> for a long time. I don’t expect they will embrace them now, nor do I think
>>> they should just to avoid us devs having to write the occasional “default”
>>> clause. This is, to be clear, a relatively rare case.
>>
>> It is probably a good choice, but there are potential upsides. Oh, course,
>> this could easily lead to a library dialect and an application dialect of
>> Swift. That is already the de-facto state of affairs for many languages,
>> including Swift. Would formalizing the difference make of “taking over the
>> world” more attainable or just create a mess? A "library switch" could be
>> horribly abused, and should only be used as a last resort. Ideally, it would
>> only generate warnings in library mode.
>>
>>
>>>
>>>>
>>>> Xcode and the SPM should be able to distinguish between the target types
>>>> and generate the proper defaults. I do not believe that this is too
>>>> mysterious for developers. There would be learning step for developers
>>>> wiring their first library, but that is not necessarily a bad thing since
>>>> creating a reusable library requires a different mindset than creating an
>>>> application.
>>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> Exhaustive and open by default with keywords to close things down if
>>>>>>> the framework author wants them.
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>> On 16 Sep 2017, at 09:55, David Hart via swift-evolution
>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>>>
>>>>>>>> I’m still very much bothered by having 2 new keywords. I would really
>>>>>>>> prefer the following plan:
>>>>>>>>
>>>>>>>> Exhaustive by default in Swift 4
>>>>>>>> No new keyword in Swift 4 to change that behaviour
>>>>>>>> Non-exhaustive by default outside the module in Swift 5
>>>>>>>> exhaustive keyword to change the default behaviour
>>>>>>>>
>>>>>>>> Like that, we don’t need nonexhaustive.
>>>>>>>>
>>>>>>>> Thoughts?
>>>>>>>> David.
>>>>>>>>
>>>>>>>>> On 13 Sep 2017, at 21:16, Jordan Rose via swift-evolution
>>>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>>>>>
>>>>>>>>> Proposal updated, same URL:
>>>>>>>>> https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums/proposals/nnnn-non-exhaustive-enums.md
>>>>>>>>>
>>>>>>>>> <https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums/proposals/nnnn-non-exhaustive-enums.md>.
>>>>>>>>>
>>>>>>>>> Thanks again for all the feedback so far, everyone!
>>>>>>>>> Jordan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Sep 12, 2017, at 17:55, Jordan Rose via swift-evolution
>>>>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>>>>>>
>>>>>>>>>> Sorry, I got distracted by other tasks! Both the discussion here and
>>>>>>>>>> within Apple has moved towards making "non-exhaustive" the default,
>>>>>>>>>> which, to be honest, I too think is the best design. I'll update the
>>>>>>>>>> proposal today to reflect that, though I still want to keep both the
>>>>>>>>>> "nonexhaustive" and "exhaustive" keywords for Swift 4 compatibility
>>>>>>>>>> for now (or whatever we end up naming them). The compatibility
>>>>>>>>>> design is a little less ambitious than Brent's; as currently
>>>>>>>>>> proposed, Swift 4 mode continues to default to 'exhaustive' all the
>>>>>>>>>> time, even in the actual Swift 5 release.
>>>>>>>>>>
>>>>>>>>>> I still want to respond to Brent's points directly, but I think you
>>>>>>>>>> and Vladimir have done a good job discussing them already. I'll send
>>>>>>>>>> out the updated proposal tomorrow, after I have a little more time
>>>>>>>>>> to think about #invalid.
>>>>>>>>>>
>>>>>>>>>> Thanks for putting time into this!
>>>>>>>>>> Jordan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On Sep 9, 2017, at 17:34, Rod Brown <rodney.bro...@icloud.com
>>>>>>>>>>> <mailto:rodney.bro...@icloud.com>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Jordan,
>>>>>>>>>>>
>>>>>>>>>>> Do you have any other thoughts about the ongoing discussion here,
>>>>>>>>>>> especially regarding Chris’ comments? As you’re the one pushing
>>>>>>>>>>> this forward, I’d really like to know what your thoughts are
>>>>>>>>>>> regarding this?
>>>>>>>>>>>
>>>>>>>>>>> - Rod
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> swift-evolution mailing list
>>>>>>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> swift-evolution mailing list
>>>>>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> swift-evolution mailing list
>>>>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>>> _______________________________________________
>>>>>>> swift-evolution mailing list
>>>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>> _______________________________________________
>>>>>> swift-evolution mailing list
>>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
