> 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
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>
>>> On May 25, 2016, at 10:27 PM, Jacob Bandes-Storch <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> On Wed, May 25, 2016 at 8:15 PM, David Sweeris via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>> On May 25, 2016, at 7:37 AM, Leonardo Pessoa via swift-evolution
>>> <[email protected] <mailto:[email protected]>> 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
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
