I have to confess that (as a beginner) I’m finding the numbering system for turning on compiler warnings more than a bit awkward. Has the use of names in addition to numbers ever been considered?
(I imagine removing the numbers would be impossible for backwards compatibility reasons, but it would seem like providing names in addition would be relatively feasible?)
IIRC @gasche had a design for a better system to control warnings but I can’t find the reference again.
My advice to you is to simply not tweak warnings and go on with the defaults.
The idea that the user should be able to tweak warnings is misguided in my opinion. If each of us tweaks warnings to its own desire then we all live with a different language. I think that a well designed programming language should be confident in the warning it emits and simply provide, as far as tweaking is concerned, a way to silence all of them or treat them all as errors (except maybe for deprecation warnings).
The way I see the warning system of OCaml is a place where the philosophical disputes of the language designers can find a resolution that satisfies all parties without having to make a strong decision about the design of the language.
Just for context, I’m a rank beginner.
I doubt I would ever want to reduce the number of warnings. I’m the sort who prefers to have my compiler complain about as much as possible.
Real World OCaml, which is the book I’ve used for learning, seems to indicate that if I want to get a warning about missing fields in a record pattern, I need to actively turn on warning 9, and that nothing will warn about it by default.
As I’d like more help in avoiding errors, not less (this is, after all, one reason strong typing is so nice!), it seems like there are some warnings like this I should want to turn on. Remembering the numbers seems rather error prone, since if I get the number of the warning I’ve decided to turn on wrong I won’t get an error that I picked incorrectly but the system will silently fail to tell me of my mistakes.
BTW, @dbuenzli, this is not to say that your point is wrong. I’d prefer it if everything reasonable was on as a matter of course and I didn’t have to think about this, but I’m dealing with the language system as others have built it, rather than as I might (perhaps) have designed it myself.
I don’t have a proper design, as I never found time to work on it, but yes, I would personally like to see warning names happen. I think this is especially important now that we can control warnings using annotations in code – using numbers is much less clear than using names.
For example, for a project I was using on recently I decided to enable by default Warning 4, which warns about fragile pattern matching (in a set of clauses distinguish certain constructors of a type, a pattern is fragile if it would still match any new constructor added to the datatype). I think that the exhaustivity checking provided by the pattern-matching compiler is one of the surprisingly powerful programming techniques of ML-family languages, and being very careful, self-conscious about fragile patterns is necessary to take full advantage of it. But sometimes you really want to use a fragile pattern, and thus to locally disable warning 4.
In this case, I use the warning as a simplified static analysis to tell me about a certain sort of code defect, and I use the warning-disabling annotation as a way to sllence false alarms – locally, in the code, at the point the alarm is raised.
@dbuenzli : I think that sometimes, giving designers a cop-out to not make a decision can be a valid way to get the language to move forward. For example, the question of scoping of type-disambiguated labels (which is controlled by warning 40) had us extremely divided when the feature was proposed, and adding a warning was a way to move forward and agree on the feature. It is possible, if the warning way had not existed, that the feature would not have been accepted. But we need usage experience and user feedback to guide the choice of whether we think warning 40 should actually be enabled or disabled by default – and we couldn’t have collected any of that experience without the feature in the language.
I see the point but from a language perspective I see using warnings for this as a hack.
These matching “modes” should be expressible in the language itself, not on the cli or via attributes (which formally are not part of the language).
So you would want some sort of annotation syntax that was a standardized part of the language to indicate (for example) that a fragile pattern was permitted?
Yes. If you recognize that doing so is useful from a programming perspective you should be able to express this in the language itself (e.g. you could have both match and fragile match constructs).
Reviving this thread, has there been any more consideration given to adding warning names? I do find that the numbers are rather opaque. This doesn’t help when you wish to remember them, whether that’s reading existing code with warnings disabled/enabled, or temporarily adding warnings to get code to compile. I know that I sometimes model out a problem by writing the types before I write the actual functions, but then I need to disable the unused type warnings to get the code to compile.
This feature was implemented in OCaml 4.12. Example:
1 | let x = 0
^
Error (warning 32 [unused-value-declaration]): unused value x.
Here, unused-value-declaration is the warning name.
[@@@warning "-unused-value-declaration"]
let x = 0
(* No error. *)
Oh awesome! Is this documented anywhere? When I search OCaml warnings I don’t get much other than random forum posts.
As far as I know, the most authoritative documentation for this (although perhaps not the most searchable) is in the manual for the -w compilation flag. OCaml - Batch compilation (ocamlc).
Alternatively, warning-list can specify a single warning using its mnemonic name (see below), as follows:
+name Enable warning name. -name Disable warning name. @name Enable and mark as fatal warning name.
The warning attribute payload (i.e. [@warning "..."]) is the same as the -w CLI option.
Also worth noting is that values prefixed with _ (i.e. _ignore_this) never trigger unused warnings, which IMO is better practice than disabling the warning entirely.
A comment on your answer : in your first answer you wrote [@@@warning “…”] that disable the warning for the whole reminder of the file (the CLI option -… is whole file, so not exactly the same) and it may shadow true mistake in the reminder.
If you want to suppress one warning on one expression you can use
let [@warning "-..."] x = 0