> Am 28.12.2015 um 02:31 schrieb Kevin Ballard via swift-evolution
> <[email protected]>:
>
> 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 none of the bound
> identifiers are visible inside of the else.
Which is correct because "case let" can fail as it is not a simple let-binding
but pattn matching. That's why a real simple let-binding might be attractive to
have. Names bound by these (or rather by let-bindings that happen before a
failable binding like pattern matching or optionla unwrapping) should be
available in the else block.
> But this really ends up being the equivalent of
>
> let r = returnsResult()
> guard case let .Succeed(m) = r else { return r }
>
> anyway so I don't really see the point in pursuing this.
The point was about keeping the scope of "r" restricted to the guard clause.
This might not be worth the effort, of course.
> As for changing if-let and guard-let by default to do this style of matching,
> I believe the Swift team did consider doing that, but the overwhelming
> prevalence of Optionals in Swift is why they didn't go ahead with it. I bet
> if you examine your own code you'll find that normal if-let and guard-lets
> outweigh if-case and guard-case by a very large amount.
I agree without having to examine my code but I'm still unsure whether it
wouldn't be better to unify let bindings with pattern matching while
disambiguating simple bindings from pattern matching and optional unwrapping as
special case of pattern matching:
let pattern = expression
If "pattern" is a simple variable the pattern matching cannot fail, so we have
a simple let-binding. Using this in an if- or guard-statement would make the
bound name available in the statement block(s) unless a failable pattern
matching came before it.
For syntactically light optional unwrapping "expression" can be "x?", i.e. "if
let x = x? {...}".
This syntax sugar would be in line with optional chaining, like "x?.property =
42" where we can understand "x?" to mean the unwrapped optional if present and
otherwise skipping the statement.
-Thorsten
>
> -Kevin
>
>> On Sun, Dec 27, 2015, at 08:25 AM, Thorsten Seitz via swift-evolution wrote:
>> 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
>> explicit):
>>
>> 1. allow let-bindings in if- and guard-statements and
>> 2. require explicit optional unwrapping by pattern matching in if- and
>> guard-statements
>>
>> In addition I’d like to add the following (but that’s really a separate
>> proposal):
>> 3. drop the „case“ keyword for pattern matching
>>
>> The example would then look like follows (written in multiple lines for
>> adding comments):
>>
>> guard
>> let r = returnsResult(), // simple let-binding
>> let .Succeed(m) = r // pattern matching
>> else {
>> return r
>> }
>>
>> Unwrapping optionals would then look like follows (i.e. no special syntax
>> for unwrapping optionals):
>>
>> if let .Some(x) = x {
>> …
>> }
>>
>> A shorter alternative might be: if let x ?= x { … }
>>
>> IIRC this or something similar was part of an earlier Swift release and was
>> streamlined to the current syntax because optionals are quite common and
>> already have special syntax sugar. The problem is that the current syntax
>> while being convenient for its succinctness is ambiguous with simple
>> let-bindings which is inconsistent and - more importantly - makes extending
>> if-statements and guard-statements by simple let-bindings impossible.
>>
>> -Thorsten
>>
>>
>>> Am 24.12.2015 um 18:13 schrieb Félix Cloutier <[email protected]>:
>>>
>>> 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
>>>> <[email protected]> a écrit :
>>>>
>>>> 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
>>>>> <[email protected]> a écrit :
>>>>>
>>>>> 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
>>>>> }
>>>>>
>>>>> -Thorsten
>>>>>
>>>>>> Am 24.12.2015 um 01:02 schrieb Andrew Duncan via swift-evolution
>>>>>> <[email protected]>:
>>>>>>
>>>>>> 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 latter.
>>>>>>
>>>>>>> On 23 Dec, 2015, at 15:58, Joe Groff <[email protected]> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On Dec 23, 2015, at 3:56 PM, Andrew Duncan <[email protected]>
>>>>>>>> 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
>>>>>>>> }
>>>>>>>>
>>>>>>>> guard case let .Succeed(m) = returnsResult() else case let .Failure(r)
>>>>>>>> {
>>>>>>>> return r // Looks like r is bound to the error String.
>>>>>>>> // But maybe you meant r = the entire returnsResult() result.
>>>>>>>> }
>>>>>>>
>>>>>>> I see. If it's an arbitrary pattern, you can match 'case let r' to bind
>>>>>>> the entire value instead of picking out the payload of the other case.
>>>>>>> That would still be exhaustive.
>>>>>>>
>>>>>>> -Joe
>>>>>>>
>>>>>>>>
>>>>>>>> The sort of message-passing error-handling I have in mind is where
>>>>>>>> each method in the call chain returns a full Result enum and each
>>>>>>>> stage checks it for Succeed/Fail, and immediately bails on Fail,
>>>>>>>> returning (propagating) the Result. To be sure, this is sort of what
>>>>>>>> exceptions do under the hood anyway.
>>>>>>>>
>>>>>>>> My use-case is a recursive descent parser that I want to bail when a
>>>>>>>> syntax error is found. This could happen way deep in the stack of
>>>>>>>> calls. If I consistently return a .Fail(ErrorCode) or
>>>>>>>> .Succeed(ASTNode) from each method, I just pass on the Result in case
>>>>>>>> of .Fail, or use it in case of .Succeed.
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 23 Dec, 2015, at 15:35, Joe Groff <[email protected]> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Dec 23, 2015, at 10:16 AM, Andrew Duncan via swift-evolution
>>>>>>>>>> <[email protected]> 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 the "guard" and "else" patterns form an
>>>>>>>>> exhaustive match when taken together. That feels nicer than
>>>>>>>>> special-case knowledge of two-case enums, though I admit it punishes
>>>>>>>>> what's likely to be a common case.
>>>>>>>>>
>>>>>>>>> -Joe
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>
>> _______________________________________________
>> 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
