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

[Jānis Kiršteins]

The argument against giving away raw value is that it grants
uniqueness of cases when serialized. One can reliably do:

// serialize
let rawValue = Planet.mercury.rawValue

// and de-serialize
guard let planet = Planet(rawValue: rawValue) else {
// ...
}

Currently raw values cannot only be equatables that are also literals
so their uniqueness can be checked at compile time. An alternative
could be that you can serialize/deserialize by case name. For example:

// serialize
let caseName = Planet.mercury.caseName // "mercury"

// de-serialize
guard let planet = Planet(caseName: "mercury") else {
// ...
}

On Thu, May 26, 2016 at 8:26 AM, Charlie Monroe via swift-evolution
<swift-evolution at swift.org> 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> wrote:
>
>
> On May 25, 2016, at 10:27 PM, Jacob Bandes-Storch <jtbandes at gmail.com>
> wrote:
>
> On Wed, May 25, 2016 at 8:15 PM, David Sweeris via swift-evolution
> <swift-evolution at swift.org> wrote:
>>
>> On May 25, 2016, at 7:37 AM, Leonardo Pessoa via swift-evolution
>> <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
> 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
>