[swift-evolution] Enums and Source Compatibility
jon at jonshier.com
Mon Sep 18 01:06:18 CDT 2017
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.
> On Sep 17, 2017, at 9:09 PM, Rod Brown via swift-evolution <swift-evolution at swift.org> wrote:
>> On 18 Sep 2017, at 9:46 am, Christopher Kornher <ckornher at me.com <mailto:ckornher at me.com>> wrote:
>>> On Sep 17, 2017, at 5:04 PM, BJ Homer <bjhomer at gmail.com <mailto:bjhomer at gmail.com>> 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
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution