[swift-evolution] [Proposal] Enums with stored properties

[Sean Heber]

> On Oct 12, 2016, at 3:10 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
> On Wed, Oct 12, 2016 at 2:27 PM, Sean Heber <sean at fifthace.com> wrote:
> 
> > With the improved syntax, this could look something like this instead:
> >
> > enum FileError: Error, LocalizedError {
> >     var url: URL { get }
> >
> >     case notFound(url: URL) {
> >         errorDescription = "Could not access the file \(url.lastPathComponent) because it could not be found."
> >         failureReason = "The file \(url.lastPathComponent) could not be found."
> >         recoverySuggestion = "Please locate the correct file and try again."
> >         helpAnchor = "notFound"
> >         url = url
> >     }
> >
> >     case accessDenied(url: URL) {
> >         errorDescription = "Could not access the file \(url.lastPathComponent) because access was denied."
> >         failureReason = "We do not have permission to view the file \(url.lastPathComponent)"
> >         recoverySuggestion = "You can change the file's permissions using the Finder's Get Info window."
> >         helpAnchor = "accessDenied"
> >         url = url
> >     }
> >
> >     case incorrectFormat(url: URL) {
> >         errorDescription = "Could not access the file \(url.lastPathComponent) because it was not in the expected format."
> >         failureReason = "The file \(url.lastPathComponent) was not in the expected format."
> >         recoverySuggestion = "The file may have become corrupt."
> >         helpAnchor = "incorrectFormat"
> >         url = url
> >     }
> >
> >     case ioError(url: URL) {
> >         errorDescription = "Could not access the file \(url.lastPathComponent) because an I/O error occurred."
> >         failureReason = "An I/O error occurred while accessing the file \(url.lastPathComponent)."
> >         recoverySuggestion = "Dear Lord, the hard drive may be failing."
> >         helpAnchor = "ioError"
> >         url = url
> >     }
> >
> >     // ... etc ...
> > }
> >
> > I don’t think it can be denied that the second is orders of magnitude easier to read and comprehend.
> >
> > Charles
> 
> 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.
> 
> 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.

I know - I’ve been here for some of those discussions and they always seem to get deferred with various excuses.

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.

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.

l8r
Sean