> Because var currently only exists in Groovy to be Java syntax compatible.
My opinion is that this should be documented as such then, because right now it's been documented as an alias for `def` but it is not. > Doing so would prevent a possible future extension of Groovy to do type inference where var is used. What use cases require type inference in Groovy? Would it be useful only when coupled with @CompileStatic? Are there use cases where it is useful also with @CompileDynamic? Cheers, Gianluca Gianluca Sartori -- Cell. +39 388 1026822 On Sat, 23 Nov 2024 at 21:27, MG <mg...@arscreat.com> wrote: > On 23/11/2024 13:43, Gianluca Sartori wrote: > > When we use @CompileStatic or @TypeChecked we are declaring we care about > types. > > > Groovy always cares about the types of variables (unless you use > def/Object, which is a design choice) - the question is only whether it > checks for correct types during compile (@CompileStatic/@TypeChecked) or > runtime (@CompileDynamic, or, more precisely > @TypeChecked(TypeCheckingMode.SKIP) (the default)). > > That said, why should we make a Groovy `var` that is not exactly the same > as the Groovy `def`? > > > Because: > > 1. var currently only exists in Groovy to be Java syntax compatible. > 2. var implies something different, more restricted than def (see > replies by other mailing list members). > 3. Doing so would prevent a possible future extension of Groovy to do > type inference where var is used. > > Cheers, > mg > > > > >
