> Am 28.12.2015 um 02:31 schrieb Kevin Ballard via swift-evolution
> :
>
> You actually can do simple let-bindings in if-let and guard-let via the `case
> let` syntax:
>
> guard case let r = returnsResult(), case let .Succeed(m) = r else { ... }
>
> Although the problem with this is `r` stil
You actually can do simple let-bindings in if-let and guard-let via the `case
let` syntax:
guard case let r = returnsResult(), case let .Succeed(m) = r else { ... }
Although the problem with this is `r` still isn't visible inside of the else
block, because it's part of the guard statement and n
On Wed, Dec 23, 2015, at 03:35 PM, Joe Groff via swift-evolution wrote:
> A slight generalization would be to allow for an arbitrary pattern in the
> `else` clause:
>
> guard case let .Succeed(m) = returnsResult() else case let .Failure(r) {
>return r
> }
>
> with the requirement that th
The problem is that currently the if-let and guard-let syntax is reserved for
unwrapping optionals and therefore cannot be used (at least not unambiguously)
for simple let-bindings as well, which is required here.
My example therefore needs the following change (sorry, I did not make this
expli
Wait, no, there's a problem with that. You can't use `r` in the guard scope
because `returnsResult()` might not have succeeded.
Félix
> Le 24 déc. 2015 à 09:37:36, Félix Cloutier via swift-evolution
> a écrit :
>
> I like that it's consistent with the if syntax (even though I don't really
>
I like that it's consistent with the if syntax (even though I don't really like
the if syntax) and that there's no dangling parts after the else.
Félix
> Le 24 déc. 2015 à 06:29:17, Thorsten Seitz via swift-evolution
> a écrit :
>
> What do you think of
>
> guard let r = returnsResult(), cas
What do you think of
guard let r = returnsResult(), case let .Succeed(m) = r else {
return r
}
Which binds r only within the scope of the guard as desired.
Written in multiple lines
guard
let r = returnsResult(),
case let .Succeed(m) = r
else {
return r
}
-
Yes, which would revert to Brent’s suggestion. But you have generalized it in a
very compatible way.
As I read somewhere, improving programming languages comes from removing
limitations rather than adding features. I intend for this Pitch to be the
former, although it does kind of look like the
> On Dec 23, 2015, at 3:56 PM, Andrew Duncan wrote:
>
> More progress! This sounds good, but it looks like what you intend is for r
> to be the error message in the Result enum type.
>
> enum Result {
> case .Fail(String)// Error message
> case .Succeed(MyType) // Something to work with
>
More progress! This sounds good, but it looks like what you intend is for r to
be the error message in the Result enum type.
enum Result {
case .Fail(String)// Error message
case .Succeed(MyType) // Something to work with
}
guard case let .Succeed(m) = returnsResult() else case let .Failure(
> On Dec 23, 2015, at 3:35 PM, Joe Groff via swift-evolution
> wrote:
>
>>
>> On Dec 23, 2015, at 10:16 AM, Andrew Duncan via swift-evolution
>> wrote:
>>
>> In fact, I feel the same way too. I have definite views about indefinite
>> pronouns. When I am teaching, I studiously avoid “it”, “
> On Dec 23, 2015, at 10:16 AM, Andrew Duncan via swift-evolution
> wrote:
>
> In fact, I feel the same way too. I have definite views about indefinite
> pronouns. When I am teaching, I studiously avoid “it”, “this”, and “that”: at
> any given instant half the students have wandering minds, a
> What about an enumeration with three cases?
>
> For example:
>
> enum Result {
> case Success
> case Failure
> case Cancelled
> }
What about it? The case permitted by the `guard` continues through the
surrounding scope; the other cases are handled by the `else` block.
--
Brent Royal-Gordon
> On Dec 22, 2015, at 11:58 PM, Andrew Duncan via swift-evolution
> wrote:
>
> Motivation
>
> The guard statement rescues us from the pyramid of doom, and lets our code
> hug the left margin more... if the failure case is false or nil. I'd like to
> guard against specific values in an enum,
In fact, I feel the same way too. I have definite views about indefinite
pronouns. When I am teaching, I studiously avoid “it”, “this”, and “that”: at
any given instant half the students have wandering minds, and if they miss the
referent, they get lost. My old HyperTalk habits must be resurfaci
I feel exactly like Brent.
Félix
> Le 23 déc. 2015 à 04:15:24, Brent Royal-Gordon via swift-evolution
> a écrit :
>
>> guard case let .Succeed(m) = returnsResult() else {
>>return it
>> }
>> // Can safely use m, otherwise Result is passed back the call stack.
>
> I didn't unders
>guard case let .Succeed(m) = returnsResult() else {
> return it
>}
>// Can safely use m, otherwise Result is passed back the call stack.
I didn't understand what you wanted to begin with, so to summarize: you want to
be able to bind the return value of `returnsResult()` to a
Motivation
The guard statement rescues us from the pyramid of doom, and lets our code hug
the left margin more... if the failure case is false or nil. I'd like to guard
against specific values in an enum, and get the same flattening of code flow.
This generalizes Swift’s convenient handling of
18 matches
Mail list logo
