[
https://issues.apache.org/jira/browse/GROOVY-11263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17802269#comment-17802269
]
ASF GitHub Bot commented on GROOVY-11263:
-----------------------------------------
eric-milles commented on PR #2023:
URL: https://github.com/apache/groovy/pull/2023#issuecomment-1875712756
> source code is meant for developers to read, and the less redundant code
there is, the more developer-friendly it becomes.
So now you have a benefit statement that you can put in the ticket. It
would be nice to have a period of review on the problem statement and
cost-benefit analysis before being forced to review code in hand.
If a user does not care about the extra code to read and the extra bytecode
generated, is there a way to turn this off?
Have you still left it as a compiler error or did you soften it to a
warning? If analysis mis-identifies some code as dead code and fails
compilation, what can a user do to get their previously-working code to compile?
If you do not address such concerns, then why not leave this out as a global
transform that you apply to your own code? Why must it be core code from the
very start?
It's a -1 from me unless you can more carefully spell out the problem
definition and the solution ramifications.
> Analyze dead code
> -----------------
>
> Key: GROOVY-11263
> URL: https://issues.apache.org/jira/browse/GROOVY-11263
> Project: Groovy
> Issue Type: Improvement
> Reporter: Daniel Sun
> Priority: Major
> Labels: breaking_change
> Fix For: 5.x
>
>
> As we all know, source code is meant for developers to read, and the less
> redundant code there is, the more developer-friendly it becomes, but Groovy
> allows dead code after {{throw}}, {{return}}, {{break}} and {{continue}}, e.g.
> {code:java}
> def m() {
> return
> def a = 1
> }
> {code}
> It's better to avoid such dead code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
