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

[Xiaodi Wu]

We're going in circles again. I addressed this with relation to `guard`,
and I would reply in the same way about `for case`:

The fact is that there are even experienced users of Swift who see `where`
and affirmatively believe it does what it does not do. The same cannot be
said for `for case`. That is, a user might say, 'What in the world does for
case mean?', but even a totally new user is unlikely to say, 'I can guess
what for case means, and it means [something that for case does not in fact
mean].'

On Tue, Jun 14, 2016 at 12:55 Ryan Lovelett via swift-evolution <
swift-evolution at swift.org> wrote:

> 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
>
> _______________________________________________
> 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/8d0dc3bb/attachment.html>