tl;dr. GHC has a new set of warnings, -Wcompat, intended to give users
advance notice of coming library changes. We want to know whether
you think this set should be included in -Wall. See the Wiki [4]
and voice your opinion via the linked poll.
Hello everyone,
GHC 8.0.1 wil
2016-02-14 17:12 GMT+01:00 Ben Gamari :
> [...] This proposal is motivated by concern expressed by some that -Wcompat
> would see little usage unless it is placed in one of the warning sets
> typically used during development. One such set is -Wall, which enables
> a generous fraction of GHC's war
[Deliberately restricting my reply to one mailing list. Cross-posting
is usually not required.]
Hi,
Am Sonntag, den 14.02.2016, 19:51 +0100 schrieb Sven Panne:
> As stated on the Wiki, stuff in -Wcompat will often be non-
> actionable,
you omitted the important “if backwards compatibility is des
Just as one data point, the Swift compiler is by default showing warnings about
upcoming changes. Just like deprecation warnings, I do find that helpful. Based
on that experience, including -Wcompat in -Wall seems like a good plan to me.
Manuel
> Ben Gamari :
>
> tl;dr. GHC has a new set of wa
On Feb 14, 2016, at 1:51 PM, Sven Panne wrote:
>
> IMHO, the distinction between "during development" and "outside of it" is
> purely hypothetical.
I find this comment quite interesting, as I see quite a large difference
between these.* For example, I use -Werror during development, but not
On 2016-02-15 at 04:47:56 +0100, Richard Eisenberg wrote:
> On Feb 14, 2016, at 1:51 PM, Sven Panne wrote:
>>
>> IMHO, the distinction between "during development" and "outside of it" is
>> purely hypothetical.
>
> I find this comment quite interesting, as I see quite a large
> difference betwe
Hi Ben,
could we enlarge the options a bit? I feel that we're in a false
dichotomy currently. I think the issue isn't so much what warnings you
see from the compiler with common settings, so much as "what warnings
will cause my build to fail?". i.e. the issue isn't what's in -Wall,
it's what goes
On 2016-02-14 at 19:51:19 +0100, Sven Panne wrote:
[...]
> As stated on the Wiki, stuff in -Wcompat will often be non-actionable,
> so the only option I see if -Wcompat is included in -Wall will be
> -Wno-compat for all my projects.
This depends on what we mean by "actionable". I'm not sure I'd
On 2016-02-15 at 11:33:09 +0100, Boespflug, Mathieu wrote:
[...]
> * include -Wcompat and -Wall, but make it "magic" so that -Wcompat
> never causes a build to fail even when users set -Wall -Werror.
Tbh, I don't like the "magic" part at all. In fact, I currently rely on
`-Wcompat -Werror` trigg
Joachim Breitner writes:
> [Deliberately restricting my reply to one mailing list. Cross-posting
> is usually not required.]
>
> Hi,
>
> Am Sonntag, den 14.02.2016, 19:51 +0100 schrieb Sven Panne:
>> As stated on the Wiki, stuff in -Wcompat will often be non-
>> actionable,
>
> you omitted the im
>> * include -Wcompat and -Wall, but make it "magic" so that -Wcompat
>> never causes a build to fail even when users set -Wall -Werror.
>
> Tbh, I don't like the "magic" part at all. In fact, I currently rely on
> `-Wcompat -Werror` triggering an error in my builds.
Point is - if -Wall implies -W
"Boespflug, Mathieu" writes:
> Hi Ben,
>
> could we enlarge the options a bit? I feel that we're in a false
> dichotomy currently. I think the issue isn't so much what warnings you
> see from the compiler with common settings, so much as "what warnings
> will cause my build to fail?". i.e. the is
12 matches
Mail list logo
