[ 
https://issues.apache.org/jira/browse/GROOVY-11621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Milles updated GROOVY-11621:
---------------------------------
    Description: 
I was recently experimenting with @CompileStatic for performance improvements 
and noticed that when using the short notation of putAt to assign a null value 
I get the following compilation error

[Static type checking] - Cannot call <T> 
org.codehaus.groovy.runtime.DefaultGroovyMethods#putAt(java.util.List<T>, int, 
T) with arguments [java.util.List<java.lang.String>, int, java.lang.Object]

 

Here is an example:
{code:groovy}
import groovy.transform.CompileStatic
import org.junit.jupiter.api.Test

@CompileStatic
class PutAtTest {

  @Test
  void testList() {
    // These all work
    def list = ['a', 'b', 'c']
    list[0] = 'aa'
    assert list[0] == 'aa'

    list.set(2, null)
    assert list[2] == null

    list.putAt(0, null)
    assert list[0] == null

    // This Fails
    list[1] = null
    assert list[1] == null : "Short notation not working when assigning null"
  }

  @Test
  void testMap() {
    // These all work
    def map = [a: 'foo', b: 'bar', c: 'baz', d: 'qui']
    map['a'] = 'aa'
    assert map['a'] == 'aa'

    map.put('c', null)
    assert map['c'] == null

    map.putAt('a', null)
    assert map['a'] == null

    map.d = null
    assert map['d'] == null

    // This Fails
    map['b'] = null
    assert map['b'] == null  : "Short notation not working when assigning null"
  }
}
{code}

As pointed out by [~paulk] on the users list, a workaround is to cast e.g.
{code:groovy}
list[1] = (String)null
map['b'] = (String)null
{code}
But it would be groovier if assigning null using short bracket notation "just 
worked". Also note that property notation for maps works (map.d = null) but 
fails with brackets (map['d'] = null) which is surprising from a user 
perspective as they are seen as alternative but equivalent ways to do the same 
thing. 

  was:
I was recently experimenting with @CompileStatic for performance improvements 
and noticed that when using the short notation of putAt to assign a null value 
I get the following compilation error

[Static type checking] - Cannot call <T> 
org.codehaus.groovy.runtime.DefaultGroovyMethods#putAt(java.util.List<T>, int, 
T) with arguments [java.util.List<java.lang.String>, int, java.lang.Object]

 

Here is an example:

 

import groovy.transform.CompileStatic
import org.junit.jupiter.api.Test

@CompileStatic
class PutAtTest {

  @Test
  void testList() {
    // These all work
    def list = ['a', 'b', 'c']
    list[0] = 'aa'
    assert list[0] == 'aa'

    list.set(2, null)
    assert list[2] == null

    list.putAt(0, null)
    assert list[0] == null

    // This Fails
    list[1] = null
    assert list[1] == null : "Short notation not working when assigning null"
  }

  @Test
  void testMap() {
    // These all work
    def map = [a: 'foo', b: 'bar', c: 'baz', d: 'qui']
    map['a'] = 'aa'
    assert map['a'] == 'aa'

    map.put('c', null)
    assert map['c'] == null

    map.putAt('a', null)
    assert map['a'] == null

    map.d = null
    assert map['d'] == null

    // This Fails
    map['b'] = null
    assert map['b'] == null  : "Short notation not working when assigning null"
  }
}

As pointed out by [~paulk] on the users list, a workaround is to cast e.g.

list[1] = (String)null
map['b'] = (String)null

But it would be groovier if assigning null using short bracket notation "just 
worked". Also note that property notation for maps works (map.d = null) but 
fails with brackets (map['d'] = null) which is surprising from a user 
perspective as they are seen as alternative but equivalent ways to do the same 
thing. 


> Assigning null to a List or Map using bracket notation does not work with 
> @CompileStatic
> ----------------------------------------------------------------------------------------
>
>                 Key: GROOVY-11621
>                 URL: https://issues.apache.org/jira/browse/GROOVY-11621
>             Project: Groovy
>          Issue Type: Bug
>          Components: Compiler
>    Affects Versions: 4.0.26
>            Reporter: Per Nyfelt
>            Assignee: Eric Milles
>            Priority: Minor
>
> I was recently experimenting with @CompileStatic for performance improvements 
> and noticed that when using the short notation of putAt to assign a null 
> value I get the following compilation error
> [Static type checking] - Cannot call <T> 
> org.codehaus.groovy.runtime.DefaultGroovyMethods#putAt(java.util.List<T>, 
> int, T) with arguments [java.util.List<java.lang.String>, int, 
> java.lang.Object]
>  
> Here is an example:
> {code:groovy}
> import groovy.transform.CompileStatic
> import org.junit.jupiter.api.Test
> @CompileStatic
> class PutAtTest {
>   @Test
>   void testList() {
>     // These all work
>     def list = ['a', 'b', 'c']
>     list[0] = 'aa'
>     assert list[0] == 'aa'
>     list.set(2, null)
>     assert list[2] == null
>     list.putAt(0, null)
>     assert list[0] == null
>     // This Fails
>     list[1] = null
>     assert list[1] == null : "Short notation not working when assigning null"
>   }
>   @Test
>   void testMap() {
>     // These all work
>     def map = [a: 'foo', b: 'bar', c: 'baz', d: 'qui']
>     map['a'] = 'aa'
>     assert map['a'] == 'aa'
>     map.put('c', null)
>     assert map['c'] == null
>     map.putAt('a', null)
>     assert map['a'] == null
>     map.d = null
>     assert map['d'] == null
>     // This Fails
>     map['b'] = null
>     assert map['b'] == null  : "Short notation not working when assigning 
> null"
>   }
> }
> {code}
> As pointed out by [~paulk] on the users list, a workaround is to cast e.g.
> {code:groovy}
> list[1] = (String)null
> map['b'] = (String)null
> {code}
> But it would be groovier if assigning null using short bracket notation "just 
> worked". Also note that property notation for maps works (map.d = null) but 
> fails with brackets (map['d'] = null) which is surprising from a user 
> perspective as they are seen as alternative but equivalent ways to do the 
> same thing. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to