[swift-evolution] [Pitch] Retiring `where` from for-in loops

[Ryan Lovelett]

On Tue, Jun 14, 2016, at 01:37 PM, Xiaodi Wu via swift-evolution wrote:
> On Tue, Jun 14, 2016 at 12:16 PM, David Waite <david at alkaline-
> solutions.com> wrote:
>> I’m a bit late to this conversation, and I don’t totally understand
>> the goal.
>>
>> There are a *lot* of things you can do in for…in loop with pattern
>> matching that also would supposedly go against this interpretation of
>> approachability. Pattern matching in general might be considered to
>> go against this interpretation.
>>
>> Is this pitch saying statements such as:
>>
>> for i in 1..<100 where i%2 == 1 {…}
>>
>> should be disallowed, while statements like
>>
>> for case let view? in views { … }
>>
>> are still approachable enough to warrant being supported in the
>> language?
>
> Language design has to weigh many factors simultaneously, I think
> you'd agree. The argument, essentially, is that `where` is not
> approachable *for the functionality that it provides* (namely, as an
> alternative for a trivial `guard...continue` statement). Pattern
> matching is daunting no doubt, but it offers functionality not
> conducive to much simpler syntax. (Or could it be much simpler? If so,
> then I would support a proposal to that effect.)
>
> Put simply, `where` is a less-than-straightforward expression of a
> very straightforward concept (filtering an array), whereas pattern
> matching is an advanced concept with a commensurately difficult
> syntax. Others have brought up generics, for example, but again that's
> an advanced *concept*; filtering an array is not.
 
So you do not see that for case syntax as "a less-than-straightforward
expression of a very straightforward concept (filtering an array)"?
 
That's strange to me. Seems like that would be the _poster_ child for
such a syntax.
 
enum Things {
case One
case Two
case Three
case Four
}
 
let things: [Things] = [.One, .Two, .One, .Three, .Four, .One]
for case .One in things {
print("Found a .One")
}
 
That code prints "Found a .One" three times. If the `where` syntax is
non-obvious with regard to `continue` or `break` then surely _that_ code
is down right opaque!
 
>
>>
>> FWIW, I wouldn’t support removing where based on current arguments
>> without either the keyword “where" being eliminated completely from
>> the language, and/or adding equivalent intuitive functionality to
>> Sequence with same-class performance, e.g. a .where(...) equivalent
>> to .lazy.filter(…).
>>
>>
>
> I feel bad sending clearly passionate people over to crush another
> conversation, but I think you'll find in the Swift repository the
> beginnings of some explorations by a certain member of the core team
> to rename `.filter()` to `.where()` :D
>
> As to whether certain methods should be lazy or eager by default,
> that's a discussion certainly appropriate for this list.
>
>> I’ve known about and used the feature since it was first added to
>> Swift (learned via the language book), and don’t fully understand the
>> confusion that some developers may have - especially since ‘while’ is
>> already a keyword and could have been used if that was the actual
>> semantics.
>
> One source of confusion was that `while...where` was supported and had
> breaking semantics. Now that's gone with SE-0099. Still, the point is
> that `where` is favored by some *because* you don't have to write
> explicitly what happens when something doesn't pass the filter,
> whereas the counterpoint argument is that not writing explicitly what
> happens when a rejected element is encountered *is* the very source of
> confusion.
>
>>
>>
>> -DW
>>
>>
>>> On Jun 14, 2016, at 10:32 AM, Xiaodi Wu via swift-evolution <swift-
>>> evolution at swift.org> wrote:
>>>
>>> And from the WWDC Platforms SOTU: "Swift is super simple and
>>> approachable.... It's great as a first language. And in fact, we
>>> think this is so important that when we designed Swift this was an
>>> explicit design goal."
>>>
>>> I would be absolutely against adding any more sugar to the for loop.
>>> In that sense, `where` sets a terrible example that certain features
>>> of sequences deserve contextual sugar. (And before someone points it
>>> out again, I've already argued why `for...in` holds its own weight,
>>> namely difficulty of writing a correct `while` replacement and
>>> progressive disclosure to the learner so that the concept of
>>> iterators can be learned afterwards.)
>>>
>>> In short, I would very much be opposed to adding keywords "for fun."
>>
>>
> _________________________________________________
> 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/20160614/b1b5d57f/attachment.html>