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

[Vladimir.S]

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
>