> On Oct 12, 2016, at 3:10 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> On Wed, Oct 12, 2016 at 2:27 PM, Sean Heber <s...@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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to