I just noticed this too. I guess I was looking too closely at the “Default behavior” section.The inlining caveat scares me a little, as it would seem to have rather drastic consequences in the future, essentially requiring the worst case scenario, even in the same module, if we want inlining for functions that use enums.
Jon > On Sep 17, 2017, at 9:09 PM, Rod Brown via swift-evolution > <[email protected]> wrote: > >> >> On 18 Sep 2017, at 9:46 am, Christopher Kornher <[email protected] >> <mailto:[email protected]>> wrote: >> >> >>> On Sep 17, 2017, at 5:04 PM, BJ Homer <[email protected] >>> <mailto:[email protected]>> 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… > > Haha no problems. Yes, it seems clear people are jumping to conclusions. This > is a case specifically for framework developers purely for interface > consistency, with is *exactly* when you want the default behaviour to protect > you from external dependency changes. > > Within the context of a single application at compile time, you will always > know all cases already and therefore exhaustive can become the default. Cross > frameworks, not so much. > > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
