<div dir="ltr">There are a number of things being talked about in this thread, all of which are solved by proper automated IDE tooling.<div><br></div><div>Javier, In my opinion the situation you've described is based on how overall nil is handled by the language parser before it generates LLVM IR.</div><div><br></div><div>A smart compiler would know what to do here without any changes to the language syntax. (Having implemented a similar language parser for LLVM IR, I can say for certain there is no excuse for the ugly syntax choices that Swift has been making, and it appears to me the result of laziness and bad design choices)</div><div><br></div><div>I solved this without setting a value before the switch/case statements and without forcing a default clause to be written. No doubt, it has been clear that these things appear troubling because of the incorrect design choices and approach to the underlying problem.</div><div><br></div><div>I will present another situation outside of the realm of enums in which Swift syntax has been made incorrect syntax choices in the handling of nil.</div><div><br></div><div>The most obvious is optionals. There are several things wrong with the swift implementation of optionals:</div><div><br></div><div>A: When an object is nil, swift syntax itself changes to try to protect the user. This results in extra code the developer has to type, even if they program in genres in which optional situations are irrelevant. (Forcing the user to unwrap optionals with things like "if let" and "guard" is ugly, bloated, and unnecessary) In my implementation I have seen that there is no need for optionals to be written like this in the syntax.</div><div><br></div><div>B: The symbols "?" and "!" are littered throughout code needlessly as <b>compiler hints</b>. Meaning the swift parser programmer team was essentially too lazy to implement what I'm describing and sacrificed the syntax of the language to avoid writing a parser that would be able to know if something was set or nil without adding extra garbage to the syntax. Again in my implementation, I have verified that this can be done and in fact if done correctly, the resulting<b> compile time is faster</b> than the swift compiler, and the code is cleaner.</div><div><br></div><div>What is happening in this thread is that there are core underlying philosophies that the swift design has adopted which are incorrect approaches to big picture problems. As a result of swift making these big picture mistakes, there arise a plethora of these other troubles that come as domino effects in circumstances here and there. This is why there is a lot of talk about patching the syntax here or there, and forcing things to be written, and then down wind of this trail of derailed logic, there arise a number of people debating what grammar to use for something that shouldn't be written in the first place. If the big picture problem is solved, the majority of these discussions are mute. </div><div><br></div><div>If Swift can accept that these choices were incorrect, we can cleanup the syntax and rewrite the parser within an impressively short time as I've seen myself. However, this requires the agreement of those involved, and based on this thread and the fact that this line of derailed logic has gone on for several years, means that the likely response to what I'm suggesting is one of "That sounds like a lot of work to change, and I already spent a lot of time and effort making it like this" - Laziness is no excuse for sticking to bad choices made in the past and causing more bad syntax choices to be made in the present. If we are truly going to make swift the dominant language for the future, then we have to adopt a different attitude toward rewriting design flaws as a community.</div><div><br></div><div>We can't always see into the future and know if a choice will be good or bad, but when we are far enough along the trail to see that the choices swift made in the past and are a core part of the language, are in fact the root of the problem, rather than clinging to backward compatibility of a clearly misguided architecture, <b>we should do the wise thing and rewrite the foundation of the language to be built on solid concepts of what we have learned from the mistakes.</b></div><div><br></div><div><br></div><div>_______________</div><div><br></div><div>Sincerely,</div><div>Jason</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 6, 2018 at 8:07 PM, Javier Soto <span dir="ltr"><<a href="mailto:javier.api@gmail.com" target="_blank">javier.api@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="auto">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)</div><br></div><div class="HOEnZb"><div class="h5"><div><div class="gmail_quote"><div>On Sat, Jan 6, 2018 at 4:47 PM Jon Shier <<a href="mailto:jon@jonshier.com" target="_blank">jon@jonshier.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div></div><div>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. </div></div><div dir="auto"><div><br></div><div><br></div><div><br></div><div>Jon</div></div><div dir="auto"><div><br>On Jan 6, 2018, at 6:12 PM, Javier Soto <<a href="mailto:javier.api@gmail.com" target="_blank">javier.api@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div>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.<br><div class="gmail_quote"><div>On Sat, Jan 6, 2018 at 3:10 PM Jon Shier <<a href="mailto:jon@jonshier.com" target="_blank">jon@jonshier.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div></div><div>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. </div></div><div dir="auto"><div><br></div><div><br></div><div>Jon</div></div><div dir="auto"><div><br>On Jan 6, 2018, at 5:49 PM, Javier Soto <<a href="mailto:javier.api@gmail.com" target="_blank">javier.api@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div>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:<br><br>int foo;<br>swith (e) { <br> case A: foo = 0; break;<br> case B: foo = 1; break;<br> case C: foo = 2; break;<br>}<br><br>(Note the lack of a default case)<br><br>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)<br><br>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.<br><div class="gmail_quote"><div>On Fri, Jan 5, 2018 at 7:11 PM Jon Shier via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div></div><div>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?</div></div><div dir="auto"><div><br></div><div><br></div><div><br></div><div>Jon Shier</div></div><div dir="auto"><div><br>On Jan 5, 2018, at 6:41 PM, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><br><div><br><blockquote type="cite"><div>On Jan 3, 2018, at 00:54, Jason Merchant via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-3277726359775968144m_2869098012422135526m_-363521382771626617m_-9068075720851543494m_-7770952582770382623Apple-interchange-newline"><div><div><div>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?<br></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><br><blockquote type="cite"><div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span style="font-size:12.800000190734863px">"Rather, we are how to enable the vendor of a nonexhaustive enum to add new cases without breaking binaries compiled against previous versions"</span></blockquote><div><br></div><div>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?</div><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>Thanks for bringing this up! Unfortunately, it falls down in practice, because if there's a new enum case, <i>it's unclear what you want to do with it.</i> If you're handling errors, it's not obvious that the way you've handled any of the <i>other</i> 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.</div><div><br></div><div><br></div><div>In any case, though, the key point on this particular quoted sentence is "without breaking <i>binaries"</i>. Any such change must be valid <i>without</i> recompilation, and indeed without any intervention from the developer or an IDE, because that's what happens when the user updates their OS.</div><div><br></div><div>Jordan</div><div><br></div><div><br></div><br><blockquote type="cite"><div><div><div><br></div><div>...</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>___________________</div><div><br></div><div>Sincerely,</div><div>Jason</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 2, 2018 at 12:36 PM, Xiaodi Wu <span><<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><span>On Tue, Jan 2, 2018 at 12:11 PM, Jason Merchant via swift-evolution <span><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br></span><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div>I think this whole thing has been unnecessarily convoluted. As a result, the majority of the replies are rabbit holes.</div><div><br></div><div>In my opinion, the true root of the concept in question is as follows:</div><div><br></div><div><b>A list of something is desired:</b></div><div>1 - Pancake</div><div>2 - Waffle</div><div>3 - Juice</div><div><br></div><div><b>Developer wishes to be able to:</b></div><div><b>A)</b> Add new things to the list of choices in the future as they come up with new ideas</div><div><b>B)</b> Sometimes select one of the choices to be chosen as the normal choice if no choice is made by the user</div><div><br></div><div>A and B are <b>separate desires</b>. 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.</div></div></blockquote><div><br></div></span><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span><div><div></div><div>____________________</div><div><br></div><div><b>Part 2:</b></div><div><br></div><div>After this simple desire is clear, there should be two discussions:</div><div><b>A)</b> 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)</div><div><b>B)</b> How do we approach making this happen behind the scenes?</div><div><br></div><div><b>Bonus:</b> 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 <b>lack of awareness between the distinctions of what the IDE should do, as opposed to what the syntax of the language should be</b>, and what should be handled behind the scenes by automated tooling.</div><div><br></div><div>_____________________</div><div><br></div><div><b>My opinion</b>, in answering the above questions is in preference to a simple easy to read and write syntax, something like the following:</div><div><br></div><div>choices Breakfast {</div><div> Pancake, <b>Waffle</b>, Juice</div><div>}</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>_____________________</div><div><br></div><div>Sincerely,</div><div>Jason</div><div><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br></blockquote></div><br></div></div>
<br></span><span>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></span></blockquote></div><br></div></div>
</blockquote></div><br></div></div>
______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></div></blockquote></div><br></div></blockquote><blockquote type="cite"><div><span>______________________________<wbr>_________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a></span><br></div></blockquote></div>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</blockquote></div><div>-- <br></div><div class="m_-3277726359775968144m_2869098012422135526m_-363521382771626617m_-9068075720851543494gmail_signature" data-smartmail="gmail_signature"><div>Javier Soto</div></div>
</div></blockquote></div></blockquote></div><div>-- <br></div><div class="m_-3277726359775968144m_2869098012422135526m_-363521382771626617gmail_signature" data-smartmail="gmail_signature"><div>Javier Soto</div></div>
</div></blockquote></div></blockquote></div></div></div></div><span class="HOEnZb"><font color="#888888"><div dir="ltr">-- <br></div><div class="m_-3277726359775968144gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Javier Soto</div></div>
</font></span></blockquote></div><br></div>