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
<[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] <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
