>>> In the past, we’ve discussed synthesizing predicate members onto enums.
>>> E.g. given:
>>>
>>> enum E {
>>> case X
>>> case Y(Int)
>>> }
>>>
>>> you’d get something like:
>>>
>>> exte
> syntax (so far as I’m aware). You can’t negate the comparison to do
>>>>>>> something for all cases except a particular case. You have to have an
>>>>>>> empty if block and use the else block, or have an empty case in a
>>>>>>>
ussed synthesizing predicate members onto enums.
> E.g. given:
>
> enum E {
> case X
> case Y(Int)
> }
>
> you’d get something like:
>
> extension E {
> func isX() -> Bool { return self == .X }
> func getY() -> Int? { … }
> }
>
> which w
rs onto enums.
>> E.g. given:
>>
>> enum E {
>> case X
>> case Y(Int)
>> }
>>
>> you’d get something like:
>>
>> extension E {
>> func isX() -> Bool { return self == .X }
>> func getY() -> Int? { … }
>> }
>
something like:
>
> extension E {
> func isX() -> Bool { return self == .X }
> func getY() -> Int? { … }
> }
>
> which would solve the client side of this nicely.
>
> -Chris
>
>
>
> On Dec 20, 2017, at 11:24 AM, Ethan Diamond via swift-evolution <
>
param)
*>* default:
*>* break
*>* }
*> >* I use this from time to time switching over, e.g., optional enums.
*> >* *: ugliest syntax ever, and it can't even be used as a
standalone expression.
*> > >>* On Dec 20, 2017, at 8:44 AM, Ethan Diamond via
swift
Hello everyone,
One major pain point I've run into with Swift is the inability to evaluate
the case of an enum that has associated values in a way that just returns a
bool. We've been given the ability in a switch statement:
enum Enum {
case a(param: String)
case b(param: String)
}
let enu
still appreciate you taking the time to listen.
-E
On Thu, Dec 31, 2015 at 9:26 PM, Chris Lattner wrote:
> On Dec 31, 2015, at 6:16 PM, Ethan Diamond via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> *There are three pieces at play here IMHO:*
> *1. How func
*There are three pieces at play here IMHO:*
*1. How functions (global and on types) are declared and implemented*
*2. How function specifications are indicated as types*
*3. How anonymous functions are declared and implemented*
Agreed, so lets flush out the rules a little more and see if we can fi
d also have the
same syntax everywhere, and be extremely similar to normal method
calls which would be easier for new Swift users.
-E
On Tue, Dec 29, 2015 at 10:13 PM, David Waite
wrote:
>
> On Dec 29, 2015, at 5:18 PM, Ethan Diamond via swift-evolution <
> swift-evolution@swif
statement in
all cases. The compiler can make more assumptions about what it's
parsing. I think it might limit what you have to work with to the
compilers benefit.
Thanks,
- Ethan
On Mon, Dec 28, 2015 at 5:44 PM, Chris Lattner wrote:
>
> On Dec 27, 2015, at 2:30 PM, Ethan Di
I realize this is on the commonly rejected list, but I really find closure
syntax to be one of the more unintuitive and unreadable parts of Swift so
I'd like to try to influence it. "Clarity at the point of use" is one of
the main stated goals of Swift, and the fact that
http://goshdarnclosuresynta
12 matches
Mail list logo
