[swift-evolution] [Proposal] Enums with static stored properties foreach case

Thu May 26 10:15:36 CDT 2016

The problem is that PlanetInfo values are recreated each time while
they are static. Imagine if PlanetInfo where some type that expensive
to create performance wise.

You could solve it by:

enum Planet {
    struct PlanetInfo {
        var mass: Double
        var description: String
    }

    case earth
    case moon

    private static earthInfo = PlanetInfo(mass: 1.0, description:
"Earth is our home")
    private static moonInfo = PlanetInfo(mass: 0.2, description: "Just a moon")

    var info : PlanetInfo {
        switch self {
            case earth: return PlanetInfo.earthInfo
            case moon: return PlanetInfo.moonInfo
        }
    }
}

But that again more verbose. The proposed solution is explicit that
those properties are static for each case.

On Thu, May 26, 2016 at 5:58 PM, Vladimir.S via swift-evolution
<swift-evolution at swift.org> wrote:
> I support the proposal, but couldn't the initial target be achieved today
> with such (more verbose,yes) solution? :
>
> enum Planet {
>     struct PlanetInfo {
>         var mass: Double
>         var description: String
>     }
>
>     case earth
>     case moon
>
>     var info : PlanetInfo {
>         switch self {
>             case earth: return PlanetInfo(mass: 1.0, description: "Earth is
> our home")
>             case moon: return PlanetInfo(mass: 0.2, description: "Just a
> moon")
>         }
>     }
> }
>
>
> let e = Planet.earth
> print(e, e.info.description)
>
> let m = Planet.moon
> print(m, m.info.description)
>
>
>
> On 26.05.2016 8:26, Charlie Monroe via swift-evolution wrote:
>>>
>>> What this proposal is asking for is an easier way to have derived values
>>> from enum cases. Asking for more flexible RawValues means mass and radius
>>> are not derived, they are the source of truth. It goes against the whole
>>> point of RawRepresentable. You are not saying ‘Mercury is identified by
>>> the case .mercury’, you are saying ‘Mercury is identified by a mass of
>>> 3.303e+23’. It’s backwards.
>>
>>
>> I see what Janis meant in the first email. It's not that the planet would
>> be identified by the mass or radius. It could very much be
>>
>> case Mercury = 1 where (mass: 3, radius: 2),
>>
>> - Mercury's rawValue would be 1.
>>
>> The issue here is that sometimes you want additional information with the
>> enum. There are many cases where you extend the enum with a variable:
>>
>> enum Error {
>> case NoError
>> case FileNotFound
>> ...
>>
>> var isFatal: Bool {
>> /// swtich over all values of self goes here.
>> }
>>
>> var isNetworkError: Bool {
>> /// swtich over all values of self goes here.
>> }
>>
>> var isIOError: Bool {
>> /// swtich over all values of self goes here.
>> }
>> }
>>
>> What the propsal suggests is to simplify this to the following:
>>
>> enum Error {
>> var isFatal: Bool
>>
>> case NoError where (isFatal: false, isNetworkError: false, isIOError:
>> false)
>> case FileNotFound  where (isFatal: true, isNetworkError: false, isIOError:
>> true)
>> ...
>>
>> }
>>
>> So that you assign the additional information to the enum value itself.
>>
>> Charlie
>>
>>>
>>>
>>>> On 26 May 2016, at 1:47 PM, David Sweeris via swift-evolution
>>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>
>>>>
>>>>> On May 25, 2016, at 10:27 PM, Jacob Bandes-Storch <jtbandes at gmail.com
>>>>> <mailto:jtbandes at gmail.com>> wrote:
>>>>>
>>>>> On Wed, May 25, 2016 at 8:15 PM, David Sweeris via swift-evolution
>>>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>
>>>>>     On May 25, 2016, at 7:37 AM, Leonardo Pessoa via swift-evolution
>>>>>     <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>     Hi,
>>>>>>
>>>>>>     Couldn't this be solved by using tuples? If not because the syntax
>>>>>>     is not allowed I think this would be more coherent to do it using
>>>>>>     current syntax.
>>>>>>
>>>>>>     enum Planet : (mass: Float, radius: Float) {
>>>>>>         case mercury = (mass: 3.303e+23, radius: 2.4397e6)
>>>>>>         case venus = (mass: 4.869e+24, radius: 6.0518e6)
>>>>>>         case earth = (mass: 5.976e+24, radius: 6.37814e6)
>>>>>>         case mars = (mass: 6.421e+23, radius: 3.3972e6)
>>>>>>         case jupiter = (mass: 1.9e+27, radius: 7.1492e7)
>>>>>>         case saturn = (mass: 5.688e+26, radius: 6.0268e7)
>>>>>>         case uranus = (mass: 8.686e+25, radius: 2.5559e7)
>>>>>>         case neptune = (mass: 1.024e+26, radius: 2.4746e7)
>>>>>>     }
>>>>>
>>>>>
>>>>>     This would be my preferred solution… AFAIK, the only reason we
>>>>>     can’t do it now is that Swift currently requires RawValue be an
>>>>>     integer, floating-point value, or string. I don’t know why the
>>>>>     language has this restriction, so I can’t comment on how hard it
>>>>>     would be to change.
>>>>>
>>>>>     - Dave Sweeris
>>>>>
>>>>>
>>>>> Except you'd have to write Planet.mercury.rawValue.mass, rather than
>>>>> Planet.mercury.mass.
>>>>>
>>>>> This could be one or two proposals: allow enums with tuple RawValues,
>>>>> and allow `TupleName.caseName.propertyName` to access a tuple element
>>>>> without going through .rawValue.
>>>>
>>>>
>>>> Good point… Has there been a thread on allowing raw-valued enums to be
>>>> treated as constants of type `RawValue` yet? Either way, removing the
>>>> restriction on what types can be a RawValue is still my preferred
>>>> solution.
>>>>
>>>> - Dave Sweeris
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution