> On Oct 12, 2016, at 3:10 PM, Xiaodi Wu <[email protected]> wrote: > > On Wed, Oct 12, 2016 at 2:27 PM, Sean Heber <[email protected]> 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
