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.
-----Original Message-----
From: "Jānis Kiršteins via swift-evolution" <swift-evolution@swift.org>
Sent: 28/05/2016 10:54 AM
To: "Brent Royal-Gordon" <br...@architechies.com>
Cc: "swift-evolution" <swift-evolution@swift.org>
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<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@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
