<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">(responses to both Jon and Goffredo's most recent point inline)</div><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 28, 2017, at 16:15, Goffredo Marocchi <<a href="mailto:panajev@gmail.com" class="">panajev@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class="">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...”.</div></div></blockquote><div><br class=""></div><div>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.)</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><div class="">On 28 Sep 2017, at 23:57, Jon Shier via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>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. </div></blockquote></div></div></div></blockquote><br class=""></div><div>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 <i class="">sufficiently useful</i> one to justify the increased language complexity is, well, part of your evaluation of the proposal.</div><br class=""><div class="">Jordan</div></body></html>