[GROOVY-9993] CLONE - Field and a property with the same name: clarification of boundary cases

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 4.0.0-alpha-3
• Labels: breaking
• Assignee: Paul King
• Reporter: Paul King
• Created: 21/Mar/21 11:51
• Updated: 02/May/21 09:18
• Resolved: 01/Apr/21 06:20

Description

A field and property with the same name cause the field to become the backing field for the property. This provides a way to override how the default private field that would normally be created, however there are a number of anomalies:

1. the initial value, if supplied as part of the property is ignored:

   class X {
       protected x
       def x = 3
   }
   
   new X().x // => current: null, expected: 3
   

2. The @PackageScope AST transform on the backing field used in conjunction with a property doesn't yield a property at all.

   class X {
       @PackageScope x
       def x
   }
   // current: The property 'x' is declared multiple times
   // expected: a property is created with a package scope backing field
   

3. the semantics for copying of annotations onto the field and getters/setters is unclear

   // the idea will be to leave the current semantics for the normal property case but document it more accurately
   // but have a cleaner semantics for the split definition with explicit backing case
   

4. the type of the field is currently used as the type for the getter return type and setter param type, ignoring the type, if given, for the property

   // the idea will be to instead fail compilation if the types don't match
   

Issue Links

• is a clone of: GROOVY-7968 A field and a property with the same name and both having an initial value leads to an ambiguity over what the initial value should be, so should fail compilation