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

[Xiaodi Wu]

On Tue, Oct 11, 2016 at 8:21 PM, Charles Srstka via swift-evolution <
swift-evolution at swift.org> wrote:

> On Oct 11, 2016, at 4:42 PM, Braeden Profile via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> enum RectSize
> {
>    let height:Int
>    let width:Int
>    case small(width: 30, height: 30)
>    case medium(width: 60, height: 60)
>    case large(width: 120, height: 120)
> }
>
>
> I like the concept, but this doesn’t seem as flexible as it could be, and
> could get ugly when mixing these defaults with enum associated values. How
> about dynamic properties instead? Something like:
>
> enum RectSize {
> var height: Int { get }
> var width: Int { get }
>
> case small {
> height { return 30 }
> width { return 30 }
> }
>
> case medium {
> height { return 60 }
> width { return 60 }
> }
>
> case large {
> height { return 120 }
> width { return 120 }
> }
>
> case custom(width: Int, height: Int) {
> height { return height }
> width { return width }
> }
> }
>

I'd be interested in expanding raw values to accommodate other types, but
computed properties are already possible:

```
enum RectSize {
    case small, medium, large

    var height: Int {
        switch self {
        case .small:
            return 30
        case .medium:
            return 60
        case .large:
            return 120
        }
    }

    var width: Int {
        return height
    }
}
```

There have been off-and-on proposals to change the syntax from what it is
currently, but none have been deemed a significant enough advantage to
merit a change--even before source-breaking changes in Swift 3 were over.
Keeping in mind that sugar is the lowest priority for Swift 4 (and not in
scope for the current phase), what's the advantage of your proposed syntax
for computed properties over the existing one?


(syntax not exact; this is pseudocode, modify the syntax as appropriate)
>
> This would keep the property implementations separate from the associated
> values, and would also allow for the computed properties to do more complex
> calculations if necessary.
>
> Charles
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161011/097af52f/attachment.html>