--no-warnings flag for build, run, test

[EthanOlpin]

During development it would be useful to have a flag for suppressing warnings. I'm not sure that this is a universal experience, but for me warnings often feel like noise in situations where I just want to observe behavior or make incremental changes and test in a short loop. Warnings about todos, deprecations, and unused bindings are generally informing me about a loose end that I'm aware of but am not interesting in tying up right that second.

Happy to create an issue for this but I'm unsure if this is controversial. I wasn't able to find any formal decisions around this topic, though there has been a small amount of discussion: e.g.

[lpil]

Could you expand on the problem you're having with the warnings from your project being shown? Thanks!

[EthanOlpin]

Of course! I suggest this only as a QOL improvement, it's nothing major, and maybe just a skill-issue on my part.

The motivating example for this post was: When refactoring a module and running tests to make sure it still worked, I had a slew of unused imports and functions that I wasn't sure were needed, comparing the latest test output with that from previous iterations involved a lot of scrolling through warnings.

Another example: When working on Advent of Code problem I might import more than I need and run my code numerous times before I reach a stage where I have a clear picture of truly unnecessary imports. It would be nice if I could focus on the program's outputs or fatal flaws as I iterate, and worry about the "unused import" warnings only when the core ideas have been realized.

Similar flags in other tools (that suppress all warnings, there are many more examples of tools with ways to suppress specific warning categories/levels):

• GCC -w
• C# Compiler /property:WarningLevel=0
• Cargo --quiet
  • I think this is a bit more aggressive than the proposed --no-warnings option, though a similar flag in Gleam would fill the same void for me.

[lpil]

Ah I see, you would like to see the outputs from multiple runs at the same time.

Are other test failures also a challenge in this case?

[EthanOlpin]

To a lesser degree they can be, but I feel other test failures are more likely to present information about a "real" issue. Even so if the Gleam CLI had an option for running individual test cases I'd probably use it.

I'm hoping not to make this about my particular issue with comparing the output from multiple runs, there are conceivable solutions to that problem. I like to work on one thing at a time and keep a tidy terminal, tools with levers that control output verbosity (like cargo's --quiet) help with that, and I thought such a lever could be a nice addition to the Gleam CLI.

Is the risk of --no-warnings being misused causing some hesitation here?

[lpil]

Yes, we want to make warnings as hard to ignore as possible. We don't want to get into a situation as is common in other ecosystems where they are commonplace.

[EthanOlpin]

Thank you for the explanation. I understand your point; it would be problematic if misuse of --no-warnings led to warnings being commonplace. I don't see a great way to address that concern, so I'm happy to abandon this idea.

I do still feel that there is an inefficiency that's worth exploring here: I already ignore many of the warnings that the CLI prints, in the sense that I see them or scroll through them but often do not read them. Since my editor and the Gleam plugin already point out unused variables and similar issues, the CLI's warnings generally don't offer much additional information during development.

I'd be interested in exploring other ideas (perhaps in a future proposal or suggestion) but only if we agree that this isn't ideal. I'd like to get a better sense of where the line is: would we, for instance, consider options that condense the warning output, even slightly?

As a specific (unpolished) example, would we consider something like a --message-format flag with a short option (akin to cargo) that produces concise 1-3 line messages, dropping the hints, but without hiding any information? Reducing:

warning: Unused variable
   ┌─ /path/example.gleam:11:7
   │
11 │   let foo = 1
   │       ^^^ This variable is never used

Hint: You can ignore it with an underscore: `_foo`.

error: Type mismatch
   ┌─ /path/example.gleam:12:17
   │
12 │   let baz = 1 + 1.0
   │                 ^^^

The + operator expects arguments of this type:

    Int

But this argument has this type:

    Float

Hint: the +. operator can be used with Floats

into something like:

warning: Unused variable: example.gleam:11:7: 
  `foo` is never used
  
error: Type mismatch: example.gleam:12:17: 
  The + operator expects arguments of type Int but `1.0` has type Float

Or would this kind of idea be a non-starter?

Edit: here's a couple screenshots of my environment, just in case it adds clarity to my goal of saving vertical space😄

Existing	hypothetical --message-format short