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

[Charles Srstka]

> On Oct 12, 2016, at 3:07 PM, Karl <razielim at gmail.com> wrote:
> 
> I disagree. I find the first better in a number of respects (although there are certainly things you could do to optimise legibility).
> 
> Firstly, I can more clearly see all of the various file errors. I can easily see how many there are, which associated values they take, etc. That’s important when writing a switch statement, for instance.

Since the definitions of the properties are implementation details, the generated interface would collapse to the simple list of cases and their associated values, just as methods, dynamic properties, etc. currently do.

> Secondly, related data is group together. All of the localised descriptions are together, etc.

I guess we disagree on this. To me, it is much clearer to have the description of each case grouped together, rather than all the localized descriptions. It’s also a lot less verbose, to my mind easier to read, and it also makes it a lot quicker to create new cases or delete unnecessary ones.

> In real code, things like localised descriptions will likely come from a common place - e.g. a localised string database.

The code shown was obviously simplified for the sake of example.

> Third: types. You never defined the type of any of these computed properties.

The type of the “url” property that I added was defined at the top of the example. The rest of the properties are defined in LocalizedError, where their types are given.

> It’s a fun example, but personally I don’t find it convincing. Several of those values are closely related and could be grouped as a struct or tuple if brevity is so important. Do you really need separate “failureReason” and “recoverySuggestion” and “helpAnchor” properties?

Given that these properties are specified by the LocalizedError protocol, I’m gonna go with… yes.

Charles

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161012/e97fe1c2/attachment.html>