(responses to both Jon and Goffredo's most recent point inline)
> On Sep 28, 2017, at 16:15, Goffredo Marocchi <pana...@gmail.com> wrote:
>
> Agreed, I am not seeing this change doing so much good because maybe it could
> prevent issues Library writers or developers updating libraries without
> checking things... not trying to be rude and/or non empathetic, but
> exhaustive enums never struck me as a bad thing and the reasons why they
> could be bad very quickly leads one to think “maybe you should not have been
> switching on enums there...”.
I suspect this is correct! Which makes non-exhaustive enums a way to
communicate that this is probably not a good enum to switch exhaustively on.
(Since switch statements can be used for other pattern-matching purposes in
Swift, taking the F# route of disallowing matching cases altogether seems
unnecessary.)
> On 28 Sep 2017, at 23:57, Jon Shier via swift-evolution
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
>> Actually, since proper dependency management for Apple platforms has
>> existed outside of Apple for years now, this likely wouldn’t affect me at
>> all, as long as the libraries I was using properly followed semantic
>> versioning. I could keep using the compatible version of the libraries for
>> however long I needed before moving to the new version and updating my code
>> to exhaustively check for the new values. So please don’t make this change
>> thinking you’ll be helping non-Apple framework providers here. Aside from
>> actual binary compatibility I’m not sure there’s a compatibility case to be
>> made here.
>From the semantic versioning point of view, non-exhaustive enums allow you to
>add a new case while changing only the minor version number and not the major
>version number. That is certainly an extra feature for non-Apple framework
>providers; whether or not it's a sufficiently useful one to justify the
>increased language complexity is, well, part of your evaluation of the
>proposal.
Jordan
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
