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
> <[email protected]> wrote:
>
>
>> On 1 Jun 2016, at 02:47, Xiaodi Wu via swift-evolution
>> <[email protected] <mailto:[email protected]>> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
