What doesn't happen today? The issue is not when they ship a new SDK: When
rebuilding your app against it, you'll get a warning for a missing case.
The problem is when running the app against a newer iOS version with a
newer version of the SDK where the enum has a new case.
On Sat, Jan 6, 2018 at 3:10 PM Jon Shier <j...@jonshier.com> wrote:
> Except it clearly doesn’t happen today when Apple ships new SDKs.
> Obviously there’s an alternate mechanism used in that case. I’m just
> curious what it is and why Swift so desperately needs an alternative.
>
>
> Jon
>
> On Jan 6, 2018, at 5:49 PM, Javier Soto <javier....@gmail.com> 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
>
> --
Javier Soto
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
