[swift-evolution] [Proposal] Enums with static storedpropertiesfor each case

[Leonardo Pessoa]

So it should either be an exception when using tuples (which I know is not good) or ensure the combination of values in all tuple values are different from one another.



-----Original Message-----
From: "Jānis Kiršteins" <janis.kirsteins at gmail.com>
Sent: ‎28/‎05/‎2016 03:58 PM
To: "Leonardo Pessoa" <me at lmpessoa.com>
Cc: "Brent Royal-Gordon" <brent at architechies.com>; "swift-evolution" <swift-evolution at swift.org>
Subject: Re: [swift-evolution] [Proposal] Enums with static storedpropertiesfor each case

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 <me at 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 at 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<T> {
>                 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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160528/a039f6d0/attachment.html>