P.P.S. (sorry for these esprits d'escalier, I'm working on a project and can't focus optimally on this) — quite the contrary, allowing the distinction in the case of for/in would be a breaking change too, but one which would bring a benefit for the programmers to be able to use both forms
=== def foo // [1] ... for (def foo in ....) // would not use [1], would scope a new variable instead for (foo in ...) // would use [1] === If you are cosy with breaking backward compatibility, well, you should do this change, not that one which breaks it for no benefit at all. Thanks and all the best, OC > On 5. 9. 2025, at 18:01, OCsite <o...@ocs.cz> wrote: > > P.S. > >> it's quite unfortunate to cripple the language by forbidding that > > among others also since it would break legacy code which relies on [1] — > without any gain for that :( > > All the best, > OC > >> On 5. 9. 2025, at 17:55, OCsite <o...@ocs.cz> wrote: >> >> 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 >>> <dev@groovy.apache.org <mailto:dev@groovy.apache.org>> 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 <dev@groovy.apache.org >>> <mailto:dev@groovy.apache.org>> >>> Sent: Friday, September 5, 2025 10:02 AM >>> To: Groovy_Developers <dev@groovy.apache.org <mailto:dev@groovy.apache.org>> >>> Cc: Milles, Eric (TR Technology) <eric.mil...@thomsonreuters.com >>> <mailto:eric.mil...@thomsonreuters.com>> >>> 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 <o...@ocs.cz <mailto:o...@ocs.cz>> >>> Sent: Thursday, September 4, 2025 5:54 PM >>> To: Groovy_Developers <dev@groovy.apache.org <mailto:dev@groovy.apache.org>> >>> 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> >
