Thanks for your comments, Jon. Responses inline. > On Dec 20, 2017, at 12:46, Jonathan Hull <jh...@gbis.com> wrote: > > >> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> When reviewing a proposal, here are some questions to consider: >> >> What is your evaluation of the proposal? >> > Strong -1 as is. > > I think I would support having an explicit ‘futureCase’ which is different > from ‘default’. Requiring default is asking for bugs. With a separate > ‘futureCase’, we would still get a compile-time error when all of the current > cases aren’t handled. Note that ‘ futureCase’ is also different than > ‘default’ in that it wouldn’t have to go at the bottom. It would only be > triggered when the value isn’t one of the values which was known at compile > time. We should also bike shed the name of ‘futureCase’ to come up with > something that might allow us to make other types of extendable enums…. > Maybe something like ‘unknownCase’ or ‘unexpectedCase’. > > As for the issue of testing, we could add (later) a universally unexpected > case that non-exhaustive enums can be set to for testing. I am not convinced > that this is actually a big enough issue to warrant that though. Forcing > ‘default’ is a much larger real-world problem, IMO (and this use of ‘default’ > is just as untestable).
Both of these are discussed in "Alternatives considered", and they have flaws that led me to leave them out of the proposal. Do you have any ideas on how to improve on that? > > I also dislike the name @exhaustive because I think it will cause confusion > (i.e. “Of course my Enum is exhaustive”). I think we should just have @fixed > for both enums and structs. The word fixed has the connotation that it > shouldn’t change. I don't think anybody loves "exhaustive", but using the same attribute for enums and structs isn't really appropriate, as discussed in my response to Karl yesterday <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171218/042248.html>. I'm not opposed to a better name if we can gravitate towards one, though. Jordan > >> Is the problem being addressed significant enough to warrant a change to >> Swift? >> > Yes, I think the problem is significant, but this is not the correct solution. >> Does this proposal fit well with the feel and direction of Swift? >> > Not quite. While I think ABI safety is Swifty, I feel like this design > actually encourages a lack of safety in other areas. Much better to > explicitly deal with the issue of added/future cases in code than to hide it > with ‘default’. > >> If you have used other languages or libraries with a similar feature, how do >> you feel that this proposal compares to those? >> > I have used Enums in several languages, but Swift is the only one which has > required exhaustive enums… I have a hard time going back to languages which > don’t have it now. > >> How much effort did you put into your review? A glance, a quick reading, or >> an in-depth study? >> > Thoroughly read proposal, casually followed the original discussion. > > Thanks, > Jon > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
