I was trying to keep succinct because I’m great at going off for paragraphs, especially on this topics 
But I did mean to say that I wouldn’t see the harm in moving errors below warnings. I have no idea if there is a good reason that they can’t be. Only thing would be that it would be one more thing to implement and support that doesn’t necessarily have a very big reach.
sodapopcan
2
Onor.io
And, again, I don’t know your codebase but I wouldn’t be totally confident that problems aren’t present. In my experience people don’t always trace bugs back to their origin; they often figure out some patch to work around the issue and then move on.
And please don’t misunderstand me; I’m not trying to trivialize the issue of dealing with 7 years of careless code. As I said I used to work on C and C++ where there were literally thousands of warnings in the code. I had to convince the team to let me spend some time either fixing the code (if needed) or using the warning suppression stuff built into the compiler. That’s how I caught that if(x=1) error I mentioned earlier. Yes, it didn’t actually appear to be hurting anything (at least there were no bugs in our bug tracker that I could directly trace to that code) but again there were lots of hacks in the codebase and undoubtedly some of those hacks could have been dealing with the fact that the else codepath was effectively unreachable.
Even if there were no error from that particular code, leaving syntactically dicey code like that–code that works in spite of itself–is a recipe for future problems. What if some junior copies that dicey code somewhere else and now instead of one instance of poor code I’ve got two. Of course no developer ever copies code they don’t understand. ← sarcasm.
I mean unless you convince the core committers to change this you’ll have to come up with some sort of work around anyway. How much faster will it be to come up with a workaround than to just go ahead and deal with what the warning is telling you?
I’ll say also that the fact that Elixir is dynamically typed actually makes me far more inclined to avoid some sort of warning suppression mechanism. We already don’t have the safety backstop that typing gives us (although that’s coming). I don’t know about anyone else but I want every check I can get on my code.
3
Onor.io
You know actually that’d be something I’d like to see as well. I’m guessing they don’t do that now because they’re showing them in the order they’re found. They’d just need to figure out how to sort warnings to the top but that may be a pretty tough thing to do depending on how the compiler is built.
0
phewitt
Just a couple of versions ago it actually did! I probably wouldn’t feel as frustrated if my experience was always like this, but rather our UX suffered from upgrading. I thought before it would short circuit, but I guess it wasn’t actually short circuiting. The errors were at the bottom though.
Anyhow, thx for discussion. I’ll hope that a mystical core dev appears with answers 
.
1
Onor.io
FWIW, you might add to your message (on the Google Group) that they seem to have changed the order of the messages getting output. That may be an unintentional regression on the part of the compiler folks.
0
phewitt
matt-savvy
Honestly, I kinda used to want this as well, but I don’t really anymore.
For example, in Go, a build will straight up fail if you have a var declared and not used. This seems nice until you want to make a temporary change to get quick feedback while debugging.
Imagine you have some function like this:
func DoSomething(x int) int {
result := x + 1
y := someResult(x) + 1
result *= (y + x)
return result;
}
and you want to comment out result *= (y + x) and sanity check that result is what you think it is.
func DoSomething(x int) int {
result := x
y := someResult(x) + x
// result *= (y + x)
return result;
}
This now won’t even compile and instead will give you a build failed message with y declared and not used. This ends up being a little bit of annoying friction because you need to go back and edit the line that declares y as well.
So now, I think the ideal could be some combination of
- a better line drawn between warnings and errors - unused vars and functions would be warnings, trying to reference an undeclared var or funtion would be an error. maybe warnings should only be something that doesn’t affect the result of your program.
- some flag to outright silence warnings for cases like OP
- some difference between dev and prod builds / modes where it will compile with a warning in dev mode but refuse to compile on prod mode.
1
sodapopcan
Elixir has already got your back 
We can—and should—use the --warnings-as-errors flag for mix compile when building for release (docs here).
Note to the skeptical as this has come up before: This flag only affects to your code. It won’t fail if any of your deps are emitting warnings. This is because Elixir is awesome
1
D4no0
This is one of the dumbest thing I’ve seen being implemented in any compilers. You literally have to comment out lines when doing a refactor to be able to compile the project.
1
sodapopcan
Ya, I was thinking this as I read it but figured I wouldn’t say anything 
It may or may not have prompted my “Elixir is awesome” comment which is something I don’t usually throw in I’ve never used Go before but this seems very frustrating.
0