[swift-evolution] Proposal: Add syntactic sugar for iterating over an Optional<SequenceType>

Jacob Bandes-Storch jtbandes at gmail.com
Fri Dec 18 15:20:47 CST 2015


How about `for? object in array` instead?

On Fri, Dec 18, 2015 at 1:13 PM, Paul Cantrell via swift-evolution <
swift-evolution at swift.org> wrote:

> `for object in? array` … suggests that there’s something optional about
> checking for inclusion, not about the array itself. It could easily be
> interpreted as “iterate for all non-nil elements of array (where array:
> [T?])” — a use case arguably more common than this.
>
>
> That’s a really good point.
>
> P
>
>
> On Dec 18, 2015, at 3:06 PM, Radosław Pietruszewski <radexpl at gmail.com>
> wrote:
>
> Personally, I’m -1 for the proposal. I see this as a solution to a very
> minor, fairly rare, and not generalizable problem.
>
> Perhaps more importantly: the syntax is confusing to my eyes. `for object
> in? array` doesn’t immediately convey its semantics to me. It suggests that
> there’s something optional about checking for inclusion, not about the
> array itself. It could easily be interpreted as “iterate for all non-nil
> elements of array (where array: [T?])” — a use case arguably more common
> than this.
>
> In the vast majority of cases, arrays shouldn’t be optional in the first
> place. It’s rare that there’s a semantic difference between “empty array”
> and “no array”.
>
> Sure, in that example it’s quite simple. It’s not the “?? []” syntax
> itself, which is perfectly clear; it’s having that dangling off the end of
> some longer expression. In real-world context, it does become additional
> noise.
>
>
> That is a good point, albeit one that’s more broad than that — I dislike
> how `as?` often forces me to add additional parentheses — and not strong
> enough to warrant an introduction of a new `in?` construct IMHO.
>
> — Radek
>
> On 18 Dec 2015, at 21:56, Paul Cantrell via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On Dec 17, 2015, at 4:08 AM, Jeremy Pereira <
> jeremy.j.pereira at googlemail.com> wrote:
>
>
> On 16 Dec 2015, at 19:52, Paul Cantrell via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I do this a lot:
>
>    for object in array ?? [] {
>
> …and it does impair readability a bit at times.
>
>
> Does it? It seems fairly understandable to me even though I have never
> seen it before.
>
>
> Sure, in that example it’s quite simple. It’s not the “?? []” syntax
> itself, which is perfectly clear; it’s having that dangling off the end of
> some longer expression. In real-world context, it does become additional
> noise.
>
> I think there is a good reason for keeping this construct a bit “clunky”.
> Generally APIs give you a nil array for one of two reasons:
>
> - there was some sort of error in retrieving the elements
> - there were no qualifying elements found.
>
>
> You’re forgetting the third case, the most common one: things not
> populated / initialized yet. In that case, we often just want to leave a UI
> blank, for example, and doing nothing is the right behavior.
>
> Doing nothing is the right behavior in a *lot* of cases, and since Swift
> provides optional sugar for “do nothing if nil” in other cases:
>
>     foo?.bar = baz
>     if let foo = bar { }
>
> …it makes sense to provide it in for loops too.
>
> True, “do nothing” is not the right behavior in all cases. Thus the
> `for…in` / `for … in?` distinction.
>
> In the second case, the API is wrong.
>
>
> Then a lot of APIs are wrong! NSURLComponents, for example:
>
>         for item in urlComponents.queryItems ?? []
>             { queryDict[item.name] = item.value }
>
> But then I don’t think NSURLComponents is making a mistake: it
> distinguishes “no query string” from “empty query string”, but for the
> purposes of the loop here, there upshot in both cases is “no query items.”
>
> True, ?? [] is minor noise — but given the clarity and low impact on
> existing code of a `for … in?` counterpart to `for … in`, it’s worth at
> least considering that option.
>
> Cheers,
>
> Paul
>
>
>
> _______________________________________________
> 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/20151218/baf12912/attachment.html>


More information about the swift-evolution mailing list