We have been using the definition that dead code is code that cannot be executed. As given, the code being marked as dead in all these examples meets that criteria.

It isn't clear to me what definition you are requesting.

Added this to the 1.4 milestone.
Removed Type-Defect, Priority-Unassigned labels.
Added Type-Enhancement, Priority-Medium, NeedsInfo labels.

I'm not giving you a criteria, I'm giving you a concrete example where I feel the analysis is wrong.

Added Triaged label.

I'm not giving you a criteria, I'm giving you a concrete example where I feel the analysis is wrong.

Yes, but why do you think it's wrong? I need to understand the criteria before I can implement it. (There is no "read Peter's mind" instruction :-)

Note that we have already added an escape hatch of ignoring the value of compile-time constants, so you can write, for example,

const bool DEBUG = false;

f() {
  if (DEBUG) {
    // not dead code
  }
}

If the "false" is there to turn off debugging code until you want to execute it, you can do that with a symbolic constant.

This is because you not take into account the reasons why the code not executed.

You're right, we're not. And perhaps we should be taking it into account. Our assumption was that users would want to know when code like

if (value == null) {
  // Handle the error case.
}

could never be reached because we can prove that the condition is never true. I still think that's useful to know, but perhaps reporting the code in the block as being dead is not the best way to provide that information.

Added Analyzer-Hint label.

Removed this from the 1.4 milestone.
Added this to the 1.5 milestone.

Removed this from the 1.5 milestone.
Added this to the Later milestone.

This comment was originally written by collinsn@google.com

Why is the dead-code hint not expected here?

cc @peter-ahe-google.
Added NeedsInfo label.

Using something like:

if (false) {
...
}

is a common way to comment out code temporarily.

Added Triaged label.

Removed this from the Later milestone.
Added Oldschool-Milestone-Later label.

This comment was originally written by collinsn@google.com

So, your point is that no one would accidentally write [if (false) { ... }], so it must have been on purpose, and so a dead-code hint is not helpful? Sounds reasonable. Note that Dart supports nested range comments ([/* ... */]), which is as easy as the [if (false)] trick, but no analysis would be performed on code in a range comment.

So, a question: do you expect hints, warnings, and errors for "temporarily commented" code in [if (false) { ... }]?

Removed Oldschool-Milestone-Later label.

2 year mark since the last comment.

Where do we want to land on this one? Complain about if (false) or not?

Personally, I think its fine if your IDE notifies you about if (false) being DEAD, whether you meant it as an intentional "commenting out" or not. It's still something you don't super duper want to check in, and your IDE can remind you of that.

You can also just use if (1 == 0) in Dart to avoid the warning.

You can also just use if (1 == 0) in Dart to avoid the warning.

Until we get smarter and start recognizing and evaluating constant expressions. :-)

Something else to note is that when this issue was opened we didn't have a way to disable hints, which we now have. It might be fine to produce hints like this when users can explicitly opt out.

Given the limited number of people complaining about this feature, I'm going to close this issue. Someone can re-open it if there's a reason to keep it open.