Fwd: doing something sensible with "unchecked"

Replied by accident to Paul only. Here's the mail. - Martin

---------- Forwarded message ----------
From: martin odersky <martin.odersky <at> epfl.ch>
Date: Sat, Jul 28, 2012 at 6:04 PM
Subject: Re: doing something sensible with "unchecked"
To: Paul Phillips <paulp <at> improving.org>

On Sat, Jul 28, 2012 at 5:28 PM, Paul Phillips <paulp <at> improving.org> wrote:
> [I'm assuming the now-quoted reply is really in response to the first
> message in this thread so I'm moving it here to reply to it.]
>
> On Sat, Jul 28, 2012 at 8:18 AM, martin odersky <martin.odersky <at> epfl.ch>
> wrote:
>>
>> I don't see the advantage yet. Unchecked, deprecation, and feature
>> warnings behave the same way. You get a summary line that there were
>> warnings and you can turn them on selectively if you wish. It seems
>> this is a good way to go about things. Rather than dropping it for
>> unchecked, I would prefer to see other categories of warnings behave
>> the same way.
>
>
> If your only choices for something are wholesale suppression or no
> suppression whatsoever, you are forced to turn it off as soon as it
> contributes any amount of noise.  It is great for something like
> deprecation, which you don't need to hear about on every build, but do want
> to investigate from time to time.  It is a lot less great for -unchecked,
> which is absolutely a "this code is wrong" warning - that is the point - you
> should hear it immediately or it is borderline useless.