Why isn't that a problem today? Like I showed in that example, that's
undefined behavior and will potentially result in a bug (or even a crash if
instead of an int you end up with an unexpected nil pointer)
On Sat, Jan 6, 2018 at 4:47 PM Jon Shier <j...@jonshier.com> wrote:
> Which isn’t a problem right now, AFAICT. Apps compiled under older SDKs
> continue to work fine (sometimes better than when compiled under the new
> SDK, as the older one avoids new bugs). My question is about how that
> compatibility is accomplished today and how and why the Obj-C and Swift
> cases are apparently different here.
>
>
>
> Jon
>
> On Jan 6, 2018, at 6:12 PM, Javier Soto <javier....@gmail.com> wrote:
>
> 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
>
> --
Javier Soto
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
