Ah, well, I largely agree with you then. To get what you want, we don't need an ABI-breaking change. The proposal really is for nicer syntax. I can sympathize with that. But, the same argument you make about the evolution process could be said for any sugar that's out of scope at the moment, no?<br><br>A complex reworking of enums is in scope, but no proposal that boils down to a workaround to introduce new syntax would pass muster, I bet. Hence the question, are there use cases not possible now that require ABI-breaking changes to enum types? If not, we can safely pause the conversation.<br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 12, 2016 at 15:22 Sean Heber <<a href="mailto:sean@fifthace.com">sean@fifthace.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
> On Oct 12, 2016, at 3:10 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> On Wed, Oct 12, 2016 at 2:27 PM, Sean Heber <<a href="mailto:sean@fifthace.com" class="gmail_msg" target="_blank">sean@fifthace.com</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> > With the improved syntax, this could look something like this instead:<br class="gmail_msg">
> ><br class="gmail_msg">
> > enum FileError: Error, LocalizedError {<br class="gmail_msg">
> > var url: URL { get }<br class="gmail_msg">
> ><br class="gmail_msg">
> > case notFound(url: URL) {<br class="gmail_msg">
> > errorDescription = "Could not access the file \(url.lastPathComponent) because it could not be found."<br class="gmail_msg">
> > failureReason = "The file \(url.lastPathComponent) could not be found."<br class="gmail_msg">
> > recoverySuggestion = "Please locate the correct file and try again."<br class="gmail_msg">
> > helpAnchor = "notFound"<br class="gmail_msg">
> > url = url<br class="gmail_msg">
> > }<br class="gmail_msg">
> ><br class="gmail_msg">
> > case accessDenied(url: URL) {<br class="gmail_msg">
> > errorDescription = "Could not access the file \(url.lastPathComponent) because access was denied."<br class="gmail_msg">
> > failureReason = "We do not have permission to view the file \(url.lastPathComponent)"<br class="gmail_msg">
> > recoverySuggestion = "You can change the file's permissions using the Finder's Get Info window."<br class="gmail_msg">
> > helpAnchor = "accessDenied"<br class="gmail_msg">
> > url = url<br class="gmail_msg">
> > }<br class="gmail_msg">
> ><br class="gmail_msg">
> > case incorrectFormat(url: URL) {<br class="gmail_msg">
> > errorDescription = "Could not access the file \(url.lastPathComponent) because it was not in the expected format."<br class="gmail_msg">
> > failureReason = "The file \(url.lastPathComponent) was not in the expected format."<br class="gmail_msg">
> > recoverySuggestion = "The file may have become corrupt."<br class="gmail_msg">
> > helpAnchor = "incorrectFormat"<br class="gmail_msg">
> > url = url<br class="gmail_msg">
> > }<br class="gmail_msg">
> ><br class="gmail_msg">
> > case ioError(url: URL) {<br class="gmail_msg">
> > errorDescription = "Could not access the file \(url.lastPathComponent) because an I/O error occurred."<br class="gmail_msg">
> > failureReason = "An I/O error occurred while accessing the file \(url.lastPathComponent)."<br class="gmail_msg">
> > recoverySuggestion = "Dear Lord, the hard drive may be failing."<br class="gmail_msg">
> > helpAnchor = "ioError"<br class="gmail_msg">
> > url = url<br class="gmail_msg">
> > }<br class="gmail_msg">
> ><br class="gmail_msg">
> > // ... etc ...<br class="gmail_msg">
> > }<br class="gmail_msg">
> ><br class="gmail_msg">
> > I don’t think it can be denied that the second is orders of magnitude easier to read and comprehend.<br class="gmail_msg">
> ><br class="gmail_msg">
> > Charles<br class="gmail_msg">
><br class="gmail_msg">
> I’m 100% in favor of something approaching this syntax where the case-specific values are all grouped by the case and not the other way around.<br class="gmail_msg">
><br class="gmail_msg">
> This particular suggestion has been made multiple times in the past. It is a proposal for sugar that did not converge on a consensus during either Swift 2 or 3 evolution. Since sugar is not in scope now and is still low priority for phase 2, let's focus on the potentially ABI-impacting issues here.<br class="gmail_msg">
<br class="gmail_msg">
I know - I’ve been here for some of those discussions and they always seem to get deferred with various excuses.<br class="gmail_msg">
<br class="gmail_msg">
My point is that, IMO, this is all I want. Thus what I’m implying is that there’s probably not any ABI impact to (IMO) “fix” enums with associated values, and so I don’t know why this discussion keeps going on and veering into (what seems to me to be) overly complex territory when many of us just want a nicer way to express cases likes these - not a whole new enum model that has to break everything.<br class="gmail_msg">
<br class="gmail_msg">
Such a “simple” change as this may not be in scope right now, but it seems as if the implication is that a far more complex breaking reworking of enum *is* somehow in scope and we should ignore simple syntactical improvements that might solve the same problems? That doesn’t make sense to me.<br class="gmail_msg">
<br class="gmail_msg">
l8r<br class="gmail_msg">
Sean<br class="gmail_msg">
<br class="gmail_msg">
</blockquote></div>