Add -Weverything and you can ensure you are switching exhaustively ;).
Sent from my iPhone
> On 8 Jan 2018, at 19:02, Javier Soto via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> This is very much an issue in Obj-C today. If you have an NS_ENUM defined
> with cases A, B, and C, this switch is correct:
>
> int foo;
> swith (e) {
> case A: foo = 0; break;
> case B: foo = 1; break;
> case C: foo = 2; break;
> }
>
> (Note the lack of a default case)
>
> If that enum is defined in a framework and it changes after the app is
> compiled (like it's the case with Apple frameworks), then that code produces
> no warning, yet the foo variable will have a garbage value (undefined
> behavior, but as far as the compiler can tell at compile time your code is
> fine)
>
> Adding a default clause to that switch has the downside of not getting
> warnings for new added cases, like has been discussed before, which is very
> useful.
>> On Fri, Jan 5, 2018 at 7:11 PM Jon Shier via swift-evolution
>> <swift-evolution@swift.org> wrote:
>> At this point I think it might be useful to outline how binary compatibility
>> works for Objective-C on Apple platforms right now. As an app developer I’m
>> not intimately familiar with what happens when you run an app compiled with
>> the iOS 10 SDK on iOS 11. Are there just runtime checks to call old code
>> paths or something else? The more this thread goes on the more confused I
>> get about why Swift would have this issue while it doesn’t appear to be one
>> for Obj-C. If an enum adds a case now, I don’t have to care until I
>> recompile using the new SDK. Is the intention for Swift to be different in
>> this regard?
>>
>>
>>
>> Jon Shier
>>
>>> On Jan 5, 2018, at 6:41 PM, Jordan Rose via swift-evolution
>>> <swift-evolution@swift.org> wrote:
>>>
>>>
>>>
>>>> On Jan 3, 2018, at 00:54, Jason Merchant via swift-evolution
>>>> <swift-evolution@swift.org> wrote:
>>>>
>>>> Is it hard to imagine that most everyone can get what they want and keep
>>>> the syntax clean and streamlined at the same time? Without any "@" signs
>>>> or other compiler hints?
>>>
>>> For what it's worth, the original version of the proposal started with a
>>> modifier (a context-sensitive keyword, like 'final'), but the core team
>>> felt that there were a lot of modifiers in the language already, and this
>>> didn't meet the bar.
>>>
>>>
>>>>> "Rather, we are how to enable the vendor of a nonexhaustive enum to add
>>>>> new cases without breaking binaries compiled against previous versions"
>>>>
>>>> When an enum changes, and the change causes the code to break, the user
>>>> can be presented with migration options from an automated IDE tool. In
>>>> what specific way does this not solve the issue about having to upgrade
>>>> your code when using someone else's code library? This very notion implies
>>>> your disgruntled about doing work when things are upgraded, is that really
>>>> what this fuss is all about?
>>>>
>>>> A well written language interpreter and auto-tooling IDE would not need
>>>> hints embedded in the code syntax itself. Migration hints from version to
>>>> version should not be a part of either the past or future version of the
>>>> code library.
>>>
>>> Thanks for bringing this up! Unfortunately, it falls down in practice,
>>> because if there's a new enum case, it's unclear what you want to do with
>>> it. If you're handling errors, it's not obvious that the way you've handled
>>> any of the other errors is appropriate. In the (admittedly controversial)
>>> SKPaymentTransactionState case, none of the existing code would be
>>> appropriate to handle the newly-introduced "deferred" case, and nor could
>>> StoreKit provide "template" code that would be appropriate to the client
>>> app.
>>>
>>>
>>> In any case, though, the key point on this particular quoted sentence is
>>> "without breaking binaries". Any such change must be valid without
>>> recompilation, and indeed without any intervention from the developer or an
>>> IDE, because that's what happens when the user updates their OS.
>>>
>>> Jordan
>>>
>>>
>>>
>>>>
>>>> ...
>>>>
>>>> I don't expect the community to agree on language grammar, but the common
>>>> sense here on how to achieve the intended goals seems to be out of wack.
>>>>
>>>> If someone can present a clear logical statement as to how an automated
>>>> migration tool behind the scenes in the IDE to handle all your versioning
>>>> worries, does not make this whole discussion about adding more convoluted
>>>> syntax additions irrelevant, I'd love to hear it.
>>>>
>>>> ___________________
>>>>
>>>> Sincerely,
>>>> Jason
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> On Tue, Jan 2, 2018 at 12:36 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>>>>>> On Tue, Jan 2, 2018 at 12:11 PM, Jason Merchant via swift-evolution
>>>>>> <swift-evolution@swift.org> wrote:
>>>>>
>>>>>> I think this whole thing has been unnecessarily convoluted. As a result,
>>>>>> the majority of the replies are rabbit holes.
>>>>>>
>>>>>> In my opinion, the true root of the concept in question is as follows:
>>>>>>
>>>>>> A list of something is desired:
>>>>>> 1 - Pancake
>>>>>> 2 - Waffle
>>>>>> 3 - Juice
>>>>>>
>>>>>> Developer wishes to be able to:
>>>>>> A) Add new things to the list of choices in the future as they come up
>>>>>> with new ideas
>>>>>> B) Sometimes select one of the choices to be chosen as the normal choice
>>>>>> if no choice is made by the user
>>>>>>
>>>>>> A and B are separate desires. In some circumstances a developer may want
>>>>>> to add a new choice and make it the normal choice when there was no
>>>>>> normal choice was clarified before.
>>>>>
>>>>> I don't think this is an accurate summary of the problem being tackled
>>>>> here. Rather, we are how to enable the vendor of a nonexhaustive enum to
>>>>> add new cases without breaking binaries compiled against previous
>>>>> versions. There is little here to do with what a "default" should be.
>>>>> Indeed, it is an explicit design decision of Swift not to support types
>>>>> having an implicit default value.
>>>>>
>>>>>> ____________________
>>>>>>
>>>>>> Part 2:
>>>>>>
>>>>>> After this simple desire is clear, there should be two discussions:
>>>>>> A) In a text only coding language, what would we like the syntax to look
>>>>>> like? (Without regard to past-bias. What should it really be, forget
>>>>>> what mistaken design choices were made in Swift in the past)
>>>>>> B) How do we approach making this happen behind the scenes?
>>>>>>
>>>>>> Bonus: Given that some of us have changed our approach to programming
>>>>>> significantly beyond text based coding, and into more dynamic mediums of
>>>>>> programming in other niches, and even here and there in Xcode - I would
>>>>>> recommend considering how the IDE would show a modern version of this
>>>>>> concept. I feel too often that Swift design syntax has a lack of
>>>>>> awareness between the distinctions of what the IDE should do, as opposed
>>>>>> to what the syntax of the language should be, and what should be handled
>>>>>> behind the scenes by automated tooling.
>>>>>>
>>>>>> _____________________
>>>>>>
>>>>>> My opinion, in answering the above questions is in preference to a
>>>>>> simple easy to read and write syntax, something like the following:
>>>>>>
>>>>>> choices Breakfast {
>>>>>> Pancake, Waffle, Juice
>>>>>> }
>>>>>>
>>>>>> If a "default" choice is desired, it is obvious to me that I would
>>>>>> select the choice from the IDE, and it would be visually indicated that
>>>>>> it was the default.
>>>>>>
>>>>>> When changes occur, whether new choices are added, old ones are removed
>>>>>> or changed, or a default is added, changed, or removed - a behind the
>>>>>> scenes automated tool analyzes the changes and presents migration
>>>>>> options through the IDE.
>>>>>>
>>>>>> _____________________
>>>>>>
>>>>>> Sincerely,
>>>>>> Jason
>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>
> --
> Javier Soto
> _______________________________________________
> 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
