Do you agree libraries should include warning IDs?

I apologize in advance if this has been suggested by others but here goes.

Just today I was compiling some code and once again I’m presented with scads of warnings generated by libraries. So I thought to myself, “Gosh I wish I had a pragma that I could use to silence warnings from libraries. Or even be able to silence a specific warning.” But then it occurred to me that the warnings I’m seeing don’t seem to have any sort of ID associated with them so I’ve got an all or nothing situation. I mean I could either silence all warnings regardless of source or I can’t silence any of them.

So, assuming there are no warning ids, could we start associating ID’s with warnings to allow for the later use of a pragma mechanism to silence specific warnings?

For example I get the following warning from absinthe (and I realize I may not be up to date on my version):

warning: using map.field notation (without parentheses) to invoke function Absinthe.Type.BuiltIns.DeprecatedDirectiveFields.absinthe_blueprint() is deprecated, you must add parentheses instead: remote.function()

Is there an id associated with this warning? I mean I don’t see any id in the text. Let’s say I wanted to silence this warning because I cannot upgrade Absinthe. There’s no way to silence the warning because I can’t specifically identify it. If it had some id (e. g. W001) then I might be able to do something like:

Code.pragma_silence_warning([“W001”])

or something along those lines.

I’m not sure that I am explaining my thinking very well here but I hope others will understand what I’m getting at. I mean I don’t think we can selectively silence warnings or do much of anything with them until they have ids or some identification mechanism associated with them.

I’d appreciate any thoughts from others if anyone cares to weigh in on this.

4 Likes