I doubt the vote for release really included detailed consideration for each individual change in a release that was years in the making. I am restating concern for specific features and the fact that discussion was not held. My concern is that we got away from Groovy 2.6 which provided a step forward with the availability of the Antlr4 parser with no new syntax additions.
I am not saying disable the Parrot Parser; I am saying disable safe indexing until such time that fixes for known breaking changes are made or there is sufficient consensus that the new behaviors are acceptable vs compatibility/predictability. I am also not saying halt innovation. I am saying that new innovations like syntax changes need a little more time to incubate and be reviewed. Like java offers preview features. If you don't want 'em you do not need to enable them. I don't think the uptake in the community of nightly builds, betas, and release candidates is that great. So you need a full production release to gain exposure. Now you have that with the Parrot Parser and there some issues to work out. But for the user, it's either Parrot Parser on or Parrot Parser off. There isn't a middle ground -- a way to disable any of the new syntax additions in case they conflict with existing source code. -----Original Message----- From: Daniel.Sun <sun...@apache.org> Sent: Saturday, May 9, 2020 3:14 PM To: d...@groovy.incubator.apache.org Subject: RE: About eliminating ambiguities safe indexing and ternary expression The vote for releasing Groovy 3 has passed with at least three +1 from PMC members. In other words, all of changes of Groovy 3 have been reviewed and not incubating any more. As to safe indexing, we have to admit we missed some scenarios to check, so the ambiguities are introduced by accident. But we can tweak it as I proposed and not just disable the feature because of some glitch. Further more, though the new Parrot parser can keep compatible with the old parser at most cases and passes tons of tests, but no one can assure 100% compatibility, so in order to avoid potential issue, we should disable or remove Parrot parser in Groovy 3? No, we will try our best to weak it. Same logic to safe indexing. Also, I think we all understand Groovy is not a toy. At last but not least, I really worry about the future of Groovy programming. If it just chases the steps of Java, it will just be another Java with some existing its own features inherited from Groovy elders, e.g. Guillaume, Jochen, Cedric, Paul, etc. (My 2 cents) 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%7Cb1f729ec40494a557eb708d7f45585a6%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637246520462053907&sdata=7PAmqGQJZhDhemJ58oI2mFh%2Fgwnz3uaz8qpN3SH80HY%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%7Cb1f729ec40494a557eb708d7f45585a6%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637246520462053907&sdata=mCT%2FNfzj6hPhQTny3UIWYVL1LB2Qt%2BG15xq0U7K4pf8%3D&reserved=0
