[swift-evolution] [Proposal] Enums with static stored properties foreach case
Vladimir.S
svabox at gmail.com
Thu May 26 10:43:01 CDT 2016
Or(if we are sure we'll don't forget to udpate `infoDict` in case of new
added case in future):
enum Planet {
case earth
case moon
struct PlanetInfo {
var mass: Double
var description: String
}
private static let infoDict = [
Planet.earth :
PlanetInfo(mass: 1.0, description:"Earth is our home"),
.moon:
PlanetInfo(mass: 0.2, description:"Just a moon"),
]
var info : PlanetInfo { return Planet.infoDict[self]! }
}
But I agree with you, IMO we need static stored properties for each case.
On 26.05.2016 18:15, Jānis Kiršteins wrote:
> 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
>
More information about the swift-evolution
mailing list