Well I would argue that's terribly wrong, for it does not bring any new functionality, just limits the existing one. Sometimes the form
=== def foo, bar // [1] ... for (foo=1, bar=2, ....) // works with the very variables [1] === makes perfect sense and it's quite unfortunate to cripple the language by forbidding that :( And when the user does not want to use existing variables, nothing easier (and more logical and intuitive) than simply adding def. All the best, OC > On 5. 9. 2025, at 17:17, Milles, Eric (TR Technology) via dev > <[email protected]> wrote: > > NOTE: Groovy 5 removes the expression list support from the first part of a > classic form — variable declaration is the only option. > > So, "for (foo = 1, bar = 2;' ...; ...)" is no longer possible. You must > write "for (def foo = 1, bar = 2; ...; ...)" or "for (def (foo,bar) = [1,2]; > ...; ...)". > > > forControl > : enhancedForControl > | originalForControl > ; > > enhancedForControl > : (indexVariable COMMA)? variableModifiersOpt type? identifier (COLON | IN) > expression > ; > > indexVariable > : (BuiltInPrimitiveType | DEF | VAR)? identifier > ; > > originalForControl > : forInit? SEMI expression? SEMI forUpdate? > ; > > forInit > : localVariableDeclaration > ; > > forUpdate > : expressionList[false] > ; > > > From: Milles, Eric (TR Technology) via dev <[email protected]> > Sent: Friday, September 5, 2025 10:02 AM > To: Groovy_Developers <[email protected]> > Cc: Milles, Eric (TR Technology) <[email protected]> > Subject: Re: Ugly inconsistence betw. for and for/in > > for-each and for-in always declare a new collection variable, which may have > its type elided. And now an index variable is also supported. > > def foo = null > for (foo : []) {} > for (foo in []) {} > > should produce an error of duplicate variable declared in outer scope. > > > for (classic) is a sequence of three expressions. I don't think there is a > hard requirement of a variable declaration expression as the first > expression. So "foo = 1" is seen as an assignment not a declaration. There > may be some history where the variables were all set into script binding > > > From: Ondra Cada <[email protected]> > Sent: Thursday, September 4, 2025 5:54 PM > To: Groovy_Developers <[email protected]> > Subject: [EXT] Ugly inconsistence betw. for and for/in > > External Email: Use caution with links and attachments. > > Hi there, > > I've just bumped into the problem that the c-like for properly scopes/does > not scope based on whether its control variable is declared or just used, > whilst for/in always scopes, regardless the form (see the example below for > detailed explanation). > > Is this a bug or an intended behaviour? > > It would be nice to fix it so that for/in does not scope when there's no > declaration, but I fear it might be a breaking change for legacy code :( > > Thanks and all the best, > OC > > === > 5 ocs /tmp> <q.groovy > class Foo { > def foo > def bar() { println "foo='$foo'" } > def test() { > println "Should not change" > for (def foo in [1,2]) bar() > println "Precisely like does not here" > for (def foo=1; foo<3; foo++) bar() > println "Should change but does not" > for (foo in [1,2]) bar() > println "Precisely like does here" > for (foo=1; foo<3; foo++) bar() > } > static main(args) { > Foo.newInstance().test() > } > } > 6 ocs /tmp> groovy q > Should not change > foo='null' > foo='null' > Precisely like does not here > foo='null' > foo='null' > Should change but does not > foo='null' > foo='null' > Precisely like does here > foo='1' > foo='2' > 7 ocs /tmp> groovy -version > Groovy Version: 4.0.27 JVM: 1.8.0_452 Vendor: Tencent OS: Mac OS X > 8 ocs /tmp> >
