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

[Xiaodi Wu]

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?

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.
On Wed, Oct 12, 2016 at 15:22 Sean Heber <sean at fifthace.com> wrote:

>
> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161012/9b0d2fd7/attachment.html>