@notjack you can have duplicate identifiers today already, so I think that we cannot add a constraint disallowing that. As for adding a note in the docs, IMHO I think people (should) know what they’re doing when they’re choosing names. Shadowing can be nice, and it can also bite you in the ass. Use at your own risk. Unless we’re going to add warnings everywhere about it, I don’t think for/fold should get one.

If we add the aforementioned feature, however, the docs should be crystal clear about how scope/binding works for the #:result clause.

@greg Loops ehh? Seen Shiver’s paper on loops?

http://www.ccs.neu.edu/home/shivers/papers/loop.pdf

@pnwamk it doesn’t feel like shadowing to me, it feels like (lambda (a b b c) body ...)

Which a language could allow by saying that later variables shadow earlier ones… but doing so is almost surely a mistake so it’s better to just error

Come to think of it, do regular for clauses allow duplicate loop variables?

well, it is what it is — right now you can have the same identifier as an accumulator and sequencing id. I see it as shadowing with the way the for/fold syntax is set up (one set of binders syntactically following another)… but that view is also possibly biased from looking at the expansion of the for macros many times.

If you’re asking if this works, it does not:

(for ([x (in-naturals)]
      [x (in-naturals)])
  (display x))

I’m curious if any packages would break with this restriction added to for/fold

error message: “unsaved editor:4:7: let-values: duplicate binding name at: x in: …”