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" <[email protected]>
Sent: 28/05/2016 03:58 PM
To: "Leonardo Pessoa" <[email protected]>
Cc: "Brent Royal-Gordon" <[email protected]>; "swift-evolution"
<[email protected]>
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 <[email protected]> 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 <[email protected]> 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
> [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
