[swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

[Patrick Smith]

I’ve always had a funny feeling about the `where` keyword in `if` statements. It feels like it adds structure, but it’s not the most flexible of keywords. I sometimes find myself writing to match the structure it wants rather than the other way around. I rather like this proposal.

What if `where` could be used to constrain the unwrapping of the optional rather than being an independent boolean expression? You could possibly use it normally outside of `if` like so:

let a: Optional<String> = "hello"

…

let b = a where a?.count > 4  // .some(“hello”)
let c = a where a?.count > 10  // .none


That way when used in an `if` statement, the `where` is actually part of the optional unwrap rather than a separate sibling.

if let x = x where x < 3 {
  …
}

So people keep their ability to group related things together, with the simple elegance of this proposal. Just an idea, and I’m sure it can be improved.


Another idea is a .filter() method added to Optional.

if let x = x.filter({ $0 < 3 }) {
  …
}


Patrick


> On 1 Jun 2016, at 8:38 PM, Haravikk via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On 1 Jun 2016, at 02:47, Xiaodi Wu via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Q: How is an arbitrary boolean assertion introduced after `if let`?
>> 
>> Option 1 (present scenario)--using `where`
>> Advantages: expressive when it means exactly the right thing
>> Drawbacks: makes obligatory the suggestion of a semantic relationship between what comes before and after even when there is no such relationship
> 
> Like I said a little earlier, this drawback is not strictly true. No matter how unrelated to the binding a where clause may seemingly be, the binding is still dependent upon it; i.e- no value is bound if the condition fails, so regardless of what the condition is actually testing for it is very much related to the binding, like-so:
> 
> 	if let value = foo where somethingUnrelatedIsTrue() { … }
> 
> The variable named “value” doesn’t exist outside of this condition if somethingUnrelatedIsTrue() fails, so I’d say there is still very much a relationship between these two things. A lot of the time you probably do want to test the unwrapped value, but it’s not a requirement for the condition to be related, because one cannot succeed without the other.
> 
>> Option 3--using a symbol never encountered in conditional statements (e.g. semicolon)
>> Advantages: doesn't need to be disambiguated from any existing uses
>> Drawbacks: looks out of place
> 
> How out of place does it really look? It’s no different from semi-colons for separating statements in code, and if where remains supported you’ll only need to use it in a handful of cases anyway (much like semi-colons for statement separation).
> 
>> It does occur to me that there is one more option. I don't know that I like it, but it's an option no one has put forward before: recite the opening keyword when beginning a new boolean expression:
>> 
>> `if let x = x where x < 3 { ... }` becomes
>> `if let x = x if x < 3 { ... }`
>> 
>> `while let item = sequence.next() where item > 0 { ... }` becomes
>> `while let item = sequence.next() while item > 0 { ... }`
> 
> I’m not sure what the difference is here; it doesn’t seem to have any capability that where doesn’t, surely it’s just changing the name of the keyword or is the point to have the full range of capabilities on both sides of the keyword? This could be done with where just as easily, no need for renaming, like so:
> 
> 	if let value = foo where case .Some(let value2) = bar { … }
> 
> Bad example I know, but I don’t use pattern matching much. This currently doesn’t compile, but where could be extended to include all conditional types, so you could chain it to do pattern matching, conditional binding and a conditional all in one, is that the kind of thing you mean?
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160601/ad8623bb/attachment.html>