Warning suppression pragmas
edzhavoronkov at gmail.com
Mon Oct 26 18:59:24 UTC 2015
Thanks for your feedback
I thought a little and fixed some in wiki page
In my opinion SUPPRESS_WARNINGS is not a real long name for pragma, but i
can't come up with whort name that clearly describes purpose of such pragma
Your suggestions are really welcome)
Edgar A. Zhavoronkov
2015-10-26 19:45 GMT+03:00 Ben Gamari <ben at well-typed.com>:
> Эдгар Жаворонков <edzhavoronkov at gmail.com> writes:
> > Hello Richard!
> > Can you take a look at some sort of specification i wrote week ago?
> > I placed it here:
> > https://ghc.haskell.org/trac/ghc/wiki/Design/LocalWarningPragmas
> > I can imagine only two use cases, and i'm not sure about correcteness of
> Thanks for writing this up!
> The specification is a good start but it really needs more detail. For
> instance, what syntactic elements do you want this pragma to apply to?
> Bindings? Expressions? Top-level definitions like classes, types, and
> instances? Any lexical scope?
> It would be nice if the use-cases you mention were a bit more concrete.
> It wouldn't hurt to mention particular warnings that you might imagine
> that this would be useful for.
> It would likely be useful to draw inspiration from some of the schemes
> used by other languages listed on the ticket (Rust and C# IIRC). It
> wouldn't hurt to draw attention to the similarities and differences to
> these other schemes in the proposal text.
> On a more bike-shed-y note, `SUPPRESS_WARNINGS` is arguably a bit on the
> long side.
> Personally I would prefer not to see the pragma be bracketed as you
> propose in your last example as its effect then becomes quite
> "non-local". This pragma should, in my opinion, be a tool of precision,
> used sparingly for well-understood reasons. Allowing bracketed regions
> makes it too easy for definitions to "sneak in" to the supressed region,
> hiding legitimate warnings. In the interest of keeping the proposal
> concrete and concise I would either remove this alternative or move it
> to a dedicated "Alternatives" section.
> I'm looking forward to seeing what becomes of this. You might consider
> submitting the next iteration of the proposal to the Haskell subreddit
> to get a few more eyes on it. Onwards!
> - Ben
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs