This discussion has been held before. From my perspective, safe indexing was/is an incubating feature. I think that "x.?getAt(y)" is readily available in place of "x?[y]" shorthand.
And with significant chance for interpreting existing code in a different way, I think it needs to be disabled until the ambiguity can be sorted out. I think it is a reasonable expectation for any developer to take existing Groovy 2 code and move it to Groovy 3 with no change in parsing or semantics. At the very least, an option to disable parsing of '?' followed by '[' as safe indexing to they can get back to prior semantics should be provided. Before enabling safe indexing again, I would expect quite a large test suite that includes map and list literals as well as ternary operators. Safe indexing and elvis assignment fall into the group of new features that I requested to be discussed before inclusion in the final release [1]. They have the feeling of "because we can" and don't appear to have been put through rigorous testing and critical review. Such a discussion was promised but never held (see "New syntax explosion" thread on the mailing list -- link below). [1] http://mail-archives.apache.org/mod_mbox/groovy-dev/201710.mbox/%3C2BA8478A2FBAFF4FBFDF1724FAD8C09E8C817AFE%40C111BKGPMBX48.ERF.thomson.com%3E -----Original Message----- From: Daniel.Sun <sun...@apache.org> Sent: Thursday, May 7, 2020 6:43 PM To: d...@groovy.incubator.apache.org Subject: About eliminating ambiguities safe indexing and ternary expression Hi all, Safe indexing has been introduced since Groovy 3.0.0, it is useful but confuses both parser and users sometimes because it is not a real operator in order to not breaking existing code as possible as we could. For example, ``` // https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGROOVY-9522&data=02%7C01%7Ceric.milles%40thomsonreuters.com%7C9a98288c04454277352808d7f2e06e45%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637244918047726423&sdata=5AvALvtyOtYXRW4O81TSPoBdQcbq7RoO6veqrPwG3gU%3D&reserved=0 def a() { null } def b() { '' } a()?[b(), a()].join(','):b() // statement with ambiguities ``` The above statement with ambiguities can be parsed into: 1) safe indexing expression, `a()?[[b(), a()]].join([',': b()])` 2) ternary expression, `a() ? ([b(), a()].join(',')) : b()` As safe indexing(i.e. `?[`) has same precedence with safe reference(i.e. `?.`), safe indexing has higher precedence than ternary expression. When ambiguities appear, the expression with ambiguities will be parsed into safe indexing. As a result, the potential issue is hard for user to find early and is ususally found when code has been executed... So I propose to make safe indexing operator `?[` become a real operator, i.e. it will be defined in the groovy lexer. * pros: 1) No ambiguities 2) Better parsing performance * cons: 1) Breaking some existing ternary expressions without spaces between`?` and `[`, e.g. `true?[0] : [1]` will be broken, so it has to be rewritten to `true? [0] : [1]` As Groovy 3 has been released, I proposed to apply the change to Groovy 4. Any thoughts? Cheers, Daniel Sun ----- Apache Groovy committer & PMC member Blog: https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblog.sunlan.me%2F&data=02%7C01%7Ceric.milles%40thomsonreuters.com%7C9a98288c04454277352808d7f2e06e45%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637244918047726423&sdata=Kcoqh2FbJNmu3jfGURK3fEN4986JLqFPWbYGe539x%2Fw%3D&reserved=0 Twitter: @daniel_sun -- Sent from: https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgroovy.329449.n5.nabble.com%2FGroovy-Dev-f372993.html&data=02%7C01%7Ceric.milles%40thomsonreuters.com%7C9a98288c04454277352808d7f2e06e45%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637244918047736421&sdata=zo0O%2FtdotT6e9kYvckMm2iwwndUORke2MBnkWYh34dE%3D&reserved=0
