Re: [swift-evolution] [Proposal] Enums with static stored properties for each case

[Jānis Kiršteins via swift-evolution]

I think you misunderstood my proposed syntax. To clarify:

enum Suit {
let bezierPath: UIBezierPath // Stored property declaration

case spades {
let bezierPath = UIBezierPath() // Declare and initialize and
local variable, this is not stored property declaration
// add drawing commands to bezierPath
self.bezierPath = bezierPath // Initialize stored property
with local variable. Stored property is shared among cases
}
}


I agree that cases should not be treated as pseudo-type, I am not
proposing that. What I am proposing is the that enum instance
behaviour and data can be very dependent of it case. And that there
should be easier and clearer ways to configure that using stored
properties.


On Thu, Jun 2, 2016 at 10:26 AM, Brent Royal-Gordon
 wrote:
>> As stated before it supposed to be per case initialization. You cannot
>> really have this analogy with other types as they have type and
>> instance while enums have type, case and instance.
>
> No. If structs have just type and instance, then so do enums.
>
> Cases in enums are analogous to stored properties in structs: they are a 
> means of organizing and representing concrete storage. They are not 
> first-class entities in the way that types and instances are. Much mischief 
> comes from thinking of cases as pseudo-types, or as some sort of peer to a 
> type.
>
>> But consider this:
>>
>> struct Struct {
>>static let bezierPath: UIBezierPath // shared
>>
>>static func initialize() {
>>bezierPath = UIBezierPath()
>>}
>> }
>
> Yes, because there's a `static` keyword on that declaration. That marks it as 
> something different from an ordinary `let`. Similarly, part of the idea of my 
> use of accessors is that the `accessor` keyword marks it as something 
> different from an ordinary `var`.
>
> (Also, you shouldn't use `initialize()` in Swift; you should set the variable 
> directly. Also also, I'm pretty sure that wouldn't work at all, because 
> `initialize()` is a normal method, not an initializer, and `bezierPath` is a 
> constant.)
>
> --
> Brent Royal-Gordon
> Architechies
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Enums with static stored properties for each case

[Jānis Kiršteins via swift-evolution]

As stated before it supposed to be per case initialization. You cannot
really have this analogy with other types as they have type and
instance while enums have type, case and instance. But consider this:

struct Struct {
static let bezierPath: UIBezierPath // shared

static func initialize() {
bezierPath = UIBezierPath()
}
}

On Thu, Jun 2, 2016 at 12:18 AM, Brent Royal-Gordon
 wrote:
>> UIBezierPath is shared for all instances of the enum case. So stored
>> properties are stored per case, not per instance (you have associated
>> values for per instance values).
>>
>>> that isn't really what this syntax suggests is happening
>>
>> Please explain what makes you think that way.
>
> Because you wrote `let bezierPath = UIBezierPath()` in the middle of a type 
> definition, and in all other types, you would get a new bezier path for each 
> instance.
>
> struct Struct {
> let bezierPath = UIBezierPath() // per instance
> }
> class Class {
> let bezierPath = UIBezierPath() // per instance
> }
> func function() {
> let bezierPath = UIBezierPath() // per call
> }
> enum Enum {
> case aCase {
> let bezierPath = UIBezierPath() // shared?!?!
> }
> }
>
> --
> Brent Royal-Gordon
> Architechies
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Enums with static stored properties for each case

[Jānis Kiršteins via swift-evolution]

UIBezierPath is shared for all instances of the enum case. So stored
properties are stored per case, not per instance (you have associated
values for per instance values).

> that isn't really what this syntax suggests is happening

Please explain what makes you think that way.


On Tue, May 31, 2016 at 11:52 PM, Brent Royal-Gordon
 wrote:
>>case spades {
> 
>>let bezierPath = UIBezierPath()
>
> Does each instance of `.spades` have a *separate* UIBezierPath, or do all 
> instances of `.spades` share one? If it's the former, I have strong doubts 
> you'll actually get this through. If it's the latter, that isn't really what 
> this syntax suggests is happening.
>
> --
> Brent Royal-Gordon
> Architechies
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Enums with static stored properties for each case

[Jānis Kiršteins via swift-evolution]

`swift
enum Suit {
var simpleDescription: String

case spades(Int) {
simpleDescription = "spades"
}
}
```

## Impact on existing code

Stored properties for enums are not currently not supported, so there
is no impact on existing code.

## Alternatives considered

- Use labeled tuple as `rawValue` of the enum case. This approach is
not compatible as it conflicts with intention of `rawValue` of Swift
enum;
- Use per case initializer like [Java
Enum](https://docs.oracle.com/javase/tutorial/java/javaOO/enum.html).
Swift enum uses custom initializer syntax to setup instances, not
cases. So this approach is not suitable for Swift.


On Sun, May 29, 2016 at 3:42 PM, Leonardo Pessoa <m...@lmpessoa.com> wrote:
> I think that's the case with enums. You're changing their current behaviour 
> of only having stored values to one in which it's computed (even if only once 
> and then stored). Enums are IMO something that have a static value you know 
> beforehand and can count on. That's why I'm not fond of the accessor 
> proposal. Otherwise I think we're transforming enums into a closed set of 
> struct instances and one could do that already by using a private init.
>
>
>> On 29 May 2016, at 3:38 am, Jānis Kiršteins via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>>
>> I agree with the argument about use of "where", not replacing the raw
>> value and having some kind of initialization block. But I cannot see
>> why "accessors" concept is any better than stored properties to solve
>> the particular problem. The "accessors" concept has much wider scope
>> than enums and is a separate proposal.
>>
>> On Sat, May 28, 2016 at 11:39 PM, Brent Royal-Gordon
>> <br...@architechies.com> wrote:
>>>>> - Abusing rawValue is just that: an abuse.
>>>>
>>>> My original proposal does not replace rawValue and is compatible with it.
>>>
>>> `rawValue` has a different purpose from how you're using it. It's supposed 
>>> to allow you to convert your type to some other *equivalent* type, like an 
>>> equivalent integer or string. Moreover, it's supposed to allow you to 
>>> *reconstruct* the instance from the raw value—remember, `RawRepresentable` 
>>> has an `init(rawValue:)` requirement.
>>>
>>> It is *not* supposed to be an ancillary bag of information on the side. 
>>> You're cramming a square peg into a round hole here.
>>>
>>> (Also, if you use `rawValue` for an ancillary bag of information, that 
>>> means you *can't* use it on the same type for its intended purpose. For 
>>> instance, you would not be able to assign numbers to your Planet enum's 
>>> cases to help you serialize them or bridge them to Objective-C. That's not 
>>> good.)
>>>
>>>>> - Using `where` just doesn't match the use of `where` elsewhere in the 
>>>>> language; everywhere else, it's some kind of condition.
>>>>
>>>> It is also used in generic type constraints. Plus it reads like human
>>>> language: `case mercury where (mass: 3.303e+23, radius: 2.4397e6)`
>>>
>>> But a generic constraint is also a type of condition: it specifies types 
>>> which are permitted and divides them from types that are not.
>>>
>>> This is *not* a condition. It's not anything like a condition. It's simply 
>>> not consistent with anything else in the language.
>>>
>>>>> - Dictionaries are the most straightforward way to handle this with the 
>>>>> current language, but their lack of exhaustiveness checking is a problem.
>>>>
>>>> Dictionaries can be used as workaround, but they cannot (lack of
>>>> exhaustiveness) solve the problem.
>>>
>>> I agree that they're a halfway solution.
>>>
>>> If `ValuesEnumerable` were to be accepted (and to have a generic 
>>> requirement for its `allValues` property), you could write a 
>>> Dictionary-like type which ensured at initialization time that it was 
>>> exhaustive. That's not as good as compile time, but it's not bad—sort of a 
>>> three-quarters solution.
>>>
>>>struct ExhaustiveDictionary>> ValuesEnumerable>: Collection, DictionaryLiteralConvertible {
>>>private var dictionary: [Key: Value]
>>>
>>>init(dictionaryLiteral elements: (Key, Value)...) {
>>>dictionary = [:]
>>>for (k, v) in elements {
>>>dictionary[k] = v
&

Re: [swift-evolution] [Proposal] Enums with static stored properties for each case

[Jānis Kiršteins via swift-evolution]

I agree with the argument about use of "where", not replacing the raw
value and having some kind of initialization block. But I cannot see
why "accessors" concept is any better than stored properties to solve
the particular problem. The "accessors" concept has much wider scope
than enums and is a separate proposal.

On Sat, May 28, 2016 at 11:39 PM, Brent Royal-Gordon
 wrote:
>>> - Abusing rawValue is just that: an abuse.
>>
>> My original proposal does not replace rawValue and is compatible with it.
>
> `rawValue` has a different purpose from how you're using it. It's supposed to 
> allow you to convert your type to some other *equivalent* type, like an 
> equivalent integer or string. Moreover, it's supposed to allow you to 
> *reconstruct* the instance from the raw value—remember, `RawRepresentable` 
> has an `init(rawValue:)` requirement.
>
> It is *not* supposed to be an ancillary bag of information on the side. 
> You're cramming a square peg into a round hole here.
>
> (Also, if you use `rawValue` for an ancillary bag of information, that means 
> you *can't* use it on the same type for its intended purpose. For instance, 
> you would not be able to assign numbers to your Planet enum's cases to help 
> you serialize them or bridge them to Objective-C. That's not good.)
>
>>> - Using `where` just doesn't match the use of `where` elsewhere in the 
>>> language; everywhere else, it's some kind of condition.
>>
>> It is also used in generic type constraints. Plus it reads like human
>> language: `case mercury where (mass: 3.303e+23, radius: 2.4397e6)`
>
> But a generic constraint is also a type of condition: it specifies types 
> which are permitted and divides them from types that are not.
>
> This is *not* a condition. It's not anything like a condition. It's simply 
> not consistent with anything else in the language.
>
>>> - Dictionaries are the most straightforward way to handle this with the 
>>> current language, but their lack of exhaustiveness checking is a problem.
>>
>> Dictionaries can be used as workaround, but they cannot (lack of
>> exhaustiveness) solve the problem.
>
> I agree that they're a halfway solution.
>
> If `ValuesEnumerable` were to be accepted (and to have a generic requirement 
> for its `allValues` property), you could write a Dictionary-like type which 
> ensured at initialization time that it was exhaustive. That's not as good as 
> compile time, but it's not bad—sort of a three-quarters solution.
>
> struct ExhaustiveDictionary ValuesEnumerable>: Collection, DictionaryLiteralConvertible {
> private var dictionary: [Key: Value]
>
> init(dictionaryLiteral elements: (Key, Value)...) {
> dictionary = [:]
> for (k, v) in elements {
> dictionary[k] = v
> }
>
> if dictionary.count != Key.allValues.count {
> let missingKeys = Key.allValues.filter { 
> dictionary[$0] == nil }
> preconditionFailure("ExhaustiveDictionary is 
> missing elements from \(Key.self): \(missingKeys)")
> }
> }
>
> var startIndex: Dictionary.Index {
> return dictionary.startIndex
> }
> var endIndex: Dictionary.Index {
> return dictionary.endIndex
> }
> subscript(index: Dictionary.Index) -> (Key, Value) {
> return dictionary[index]
> }
> func index(after i: Dictionary.Index) -> Dictionary.Index {
> return dictionary.index(after: i)
> }
>
> subscript(key: Key) -> Value {
> get { return dictionary[key]! }
> set { dictionary[key] = newValue }
> }
> }
>
>>> What I would do is borrow the "accessors" concept from the property 
>>> behaviors proposal and extend it so that it supported both functions and 
>>> variables.
>>
>> Wouldn't accessor just be a redundant keyword here? Currently enums do
>> not support stored properties, so I guess there is no extra need to
>> mark properties with any special keyword.
>
> The keyword is mainly to indicate the unusual syntax at the definition site, 
> where you only have to specify the name of the accessor you're defining, not 
> a `func` or `var` keyword, a return type, or even parameter names. (Like 
> `willSet`, there's a default parameter name you can use.) Secondarily, 
> though, I think it's helpful to indicate very explicitly that this is not an 
> ordinary method or property definition, even if the compiler could perhaps 
> sort things out without it. `accessor` is something a user can Google if 
> they've never seen it before.
>
>> Property accessors might work for 

Re: [swift-evolution] [Proposal] Enums with static stored propertiesfor each case

[Jānis Kiršteins via swift-evolution]

As previosly state there is one problem using tuples as rawValues - they 
currently must be static (literals) and unique. In example with planets the 
mass or radius is not unique so it cannot be used as raw value with current 
requirments. 



> On 28 May 2016, at 20:22, Leonardo Pessoa <m...@lmpessoa.com> wrote:
> 
> My suggestion of allowing tuples as raw values instead doesn't burden the 
> language and also does not eliminate rawValue (treat previously supported raw 
> value types as one value tuples), reads very cleanly and supports a syntax 
> we're already familiar with. I don't see how the 'where' syntax reads like 
> natural language and I agree it doesn't match other uses of where in the 
> language.
> 
> From: Jānis Kiršteins via swift-evolution
> Sent: ‎28/‎05/‎2016 10:54 AM
> To: Brent Royal-Gordon
> Cc: swift-evolution
> Subject: Re: [swift-evolution] [Proposal] Enums with static stored 
> propertiesfor each case
> 
> > - Abusing rawValue is just that: an abuse.
> 
> My original proposal does not replace rawValue and is compatible with it.
> 
> > - Using `where` just doesn't match the use of `where` elsewhere in the 
> > language; everywhere else, it's some kind of condition.
> 
> It is also used in generic type constraints. Plus it reads like human
> language: `case mercury where (mass: 3.303e+23, radius: 2.4397e6)`
> 
> > - Dictionaries are the most straightforward way to handle this with the 
> > current language, but their lack of exhaustiveness checking is a problem.
> 
> Dictionaries can be used as workaround, but they cannot (lack of
> exhaustiveness) solve the problem.
> 
> > What I would do is borrow the "accessors" concept from the property 
> > behaviors proposal and extend it so that it supported both functions and 
> > variables.
> 
> Wouldn't accessor just be a redundant keyword here? Currently enums do
> not support stored properties, so I guess there is no extra need to
> mark properties with any special keyword.
> 
> Property accessors might work for enums with associated values, but
> not so well without them.
> 
> On Fri, May 27, 2016 at 3:43 PM, Brent Royal-Gordon via
> swift-evolution <swift-evolution@swift.org> wrote:
> >> The suggested solution based on 'accessor' - will create assotiated 
> >> properties each time the enum instace created, for each instance of enum 
> >> type.
> >
> > No; property accessors would be either computed or constant (so that all 
> > instances of a given case can share storage). This is much the way they 
> > would behave if they were included in behaviors.
> >
> > You could write a property accessor with a setter, but it would have to be 
> > computed, and manipulate `self`'s cases and associated values:
> >
> > enum Optional {
> > accessor var unwrapped: T { get set }
> >
> > case none {
> > unwrapped {
> > get { fatalError("No value") }
> > set { self = .some(newValue) }
> > }
> > }
> > case some (_ value: T) {
> > unwrapped {
> > get { return value }
> > set { self = .some(newValue) }
> > }
> > }
> > }
> >
> > --
> > Brent Royal-Gordon
> > Architechies
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jānis Kiršteins via swift-evolution]

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
 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
 > wrote:


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

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

[Jānis Kiršteins via swift-evolution]

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

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

[Jānis Kiršteins via swift-evolution]

That would replace current enum raw value functionality and I see two
problems with that.

1. A lot of breaking changes
2. Raw values currently are unique values among all cases. That makes
a possibility that enums can be easily serialized/deserialized to
formats like JSON, property lists, etc. In "case mercury = (mass:
3.303e+23, radius: 2.4397e6)" neither mass nor radius is unique value
(it is possible that two different planets could have the same mass as
radius).



On Wed, May 25, 2016 at 3:37 PM, Leonardo Pessoa <m...@lmpessoa.com> 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)
> }
> ____
> From: Jānis Kiršteins via swift-evolution
> Sent: ‎25/‎05/‎2016 08:58 AM
> To: swift-evolution@swift.org
> Subject: [swift-evolution] [Proposal] Enums with static stored properties
> foreach case
>
> Hello everyone,
>
> Currently Swift only supports computed properties for each enum case.
> If you want to somehow get static values with each case you would
> probably do it like this:
>
> enum Planet {
> case mercury
> case venus
> case earth
> case mars
> case jupiter
> case saturn
> case uranus
> case neptune
>
> var mass: Float {
> switch self {
> case .mercury: return 3.303e+23
> case .venus: return 4.869e+24
> case .earth: return 5.976e+24
> case .mars: return 6.421e+23
> case .jupiter: return 1.9e+27
> case .saturn: return 5.688e+26
> case .uranus: return 8.686e+25
> case .neptune: return 1.024e+26
> }
> }
>
> var radius: Float {
> switch self {
> case .mercury: return 2.4397e6
> case .venus: return 6.0518e6
> case .earth: return 6.37814e6
> case .mars: return 3.3972e6
> case .jupiter: return 7.1492e7
> case .saturn: return 6.0268e7
> case .uranus: return 2.5559e7
> case .neptune: return 2.4746e7
> }
> }
> }
>
> However I see two problems with this approach:
>
> 1. These value definitions are spread out and difficult to read and
> maintain (especially if you have many computed properties for each
> enum case);
> 2. These values are not static. They are computed each time property
> is accessed. This can be a problem when value is expensive to create.
>
> The proposed solution is to have single static initializer for each
> enum case that initializes stored properties. For example,
>
> enum Planet {
> var mass: Float
> var radius: Float
>
> static init(mass: Float, radius: Float) {
> self.mass = mass
> self.radius = radius
> }
>
> case mercury where (mass: 3.303e+23, radius: 2.4397e6)
> case venus where (mass: 4.869e+24, radius: 6.0518e6)
> case earth where (mass: 5.976e+24, radius: 6.37814e6)
> case mars where (mass: 6.421e+23, radius: 3.3972e6)
> case jupiter where (mass: 1.9e+27, radius: 7.1492e7)
> case saturn where (mass: 5.688e+26, radius: 6.0268e7)
> case uranus where (mass: 8.686e+25, radius: 2.5559e7)
> case neptune where (mass: 1.024e+26, radius: 2.4746e7)
> }
>
> This approach do not affect enums that have raw or associated values,
> or custom enum initializers:
>
> case A = "A" where (id: 0)
>
> or
>
> case B(Int, Int, Int) where (id: 0)
>
> Benefits:
> 1. Less verbosity
> 2. Improved readability
> 3. Related values are closer to each other
> 4. Static values are not recomputed
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jānis Kiršteins via swift-evolution]

Hello everyone,

Currently Swift only supports computed properties for each enum case.
If you want to somehow get static values with each case you would
probably do it like this:

enum Planet {
case mercury
case venus
case earth
case mars
case jupiter
case saturn
case uranus
case neptune

var mass: Float {
switch self {
case .mercury: return 3.303e+23
case .venus: return 4.869e+24
case .earth: return 5.976e+24
case .mars: return 6.421e+23
case .jupiter: return 1.9e+27
case .saturn: return 5.688e+26
case .uranus: return 8.686e+25
case .neptune: return 1.024e+26
}
}

var radius: Float {
switch self {
case .mercury: return 2.4397e6
case .venus: return 6.0518e6
case .earth: return 6.37814e6
case .mars: return 3.3972e6
case .jupiter: return 7.1492e7
case .saturn: return 6.0268e7
case .uranus: return 2.5559e7
case .neptune: return 2.4746e7
}
}
}

However I see two problems with this approach:

1. These value definitions are spread out and difficult to read and
maintain (especially if you have many computed properties for each
enum case);
2. These values are not static. They are computed each time property
is accessed. This can be a problem when value is expensive to create.

The proposed solution is to have single static initializer for each
enum case that initializes stored properties. For example,

enum Planet {
var mass: Float
var radius: Float

static init(mass: Float, radius: Float) {
self.mass = mass
self.radius = radius
}

case mercury where (mass: 3.303e+23, radius: 2.4397e6)
case venus where (mass: 4.869e+24, radius: 6.0518e6)
case earth where (mass: 5.976e+24, radius: 6.37814e6)
case mars where (mass: 6.421e+23, radius: 3.3972e6)
case jupiter where (mass: 1.9e+27, radius: 7.1492e7)
case saturn where (mass: 5.688e+26, radius: 6.0268e7)
case uranus where (mass: 8.686e+25, radius: 2.5559e7)
case neptune where (mass: 1.024e+26, radius: 2.4746e7)
}

This approach do not affect enums that have raw or associated values,
or custom enum initializers:

case A = "A" where (id: 0)

or

case B(Int, Int, Int) where (id: 0)

Benefits:
1. Less verbosity
2. Improved readability
3. Related values are closer to each other
4. Static values are not recomputed
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution