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