[swift-evolution] Enums and Source Compatibility

[Jon Shier]

	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 <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...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170918/f97f9769/attachment.html>