Make deprecations as warnings the default

[leandro-lucarella-sociomantic]

Since wanting to have deprecations as warnings is probably what most
people wants, make it the default. Also rename -di to -dw and introduce
-de to get the old default behaviour of having deprecations as errors.
-d stays untouched for backwards compatibility and those crazy people
that doesn't even want to know about deprecated features.

[jmdavis]

-dw would probably be bad, because -w makes warnings into errors. -di is a much better name in that regard. But since -di is new (and unreleased) and this pull request makes it unnecessary, I'd suggest just getting rid of it. I see no reason to keep it.

[leandro-lucarella-sociomantic]

On Wed, Nov 14, 2012 at 10:45:09AM -0800, Jonathan M Davis wrote:

-dw would probably be bad, because -w makes warnings into errors. -di
is a much better name in that regard. But since -di is new (and
unreleased) and this pull request makes it unnecessary, I'd suggest
just getting rid of it. I see no reason to keep it.

I kept it to be able to override a potential -de that people wanting the
old default might put into theirs dmd.conf.

About the name change, other people suggested -dw in the past and since
-de is associated to Deprecation as Errors, I thought it was a good idea
to make it consistent and call it -dw (as Deprecation as Errors).

That being said, I'll happy change it to whatever you want IIF someone
with push access willing to merge this asks for it.

Leandro Lucarella

Senior R&D Developer

sociomantic labs GmbH
Münzstraße 19
10178 BERLIN

DEUTSCHLAND

http://www.sociomantic.com

Fon: +49 (0) 30 3087 4615
Fax: +49 (0) 30 3087 4619
Mobile: +49 (0)157 3636 7373
Skype: llucarella
Twitter: http://www.twitter.com/sociomantic

Facebook: http://bit.ly/labsfacebook

sociomantic labs GmbH, Location: Berlin
Commercial Register - AG Charlottenburg: HRB 121302 B
VAT No. - USt-ID: DE 266262100
Managing Directors: Thomas Nicolai, Thomas Brandhoff

[leandro-lucarella-sociomantic]

This pull request if failing because there is a "false deprecation" (a feature emits a deprecation but the backend always reject it, so it should be really an error). Here is a pull request to fix that: #1292

[WalterBright]

Breaking peoples' makefiles is as bad as breaking their code, or even worse as far too many people regard makefiles like they regard perl scripts - black magic - and don't dare touch anything in it.

[alexrp]

This pull request doesn't break anything, though. -d still has the old behavior.

[jmdavis]

If I understand correctly, what this pull request does is

1. Make it so that deprecated generates a warning rather than an error by default. This will break nothing.
2. Add the -de flag to make it so that anyone who wants deprecated to generate errors rather than warnings can do so (so -de restores the current behavior for deprecated).
3. Renames the new -di to -dw and leaves it in so that -de can be overridden if need be.
4. Leaves -d alone entirely, and anyone using it will be completely unaffected by these changes.

I really think that -di shouldn't be renamed to -dw, because it doesn't following the current naming scheme for flags (in particular with regards to -w and -wi), but other than that, I don't see any problems with these changes. It should break nothing (though it will make some code start compiling which didn't compile before because of deprecated), and it will make it so that using deprecated will generally not break people's code but instead just bug them to update it (and if they don't want to be bugged, they can still use -d). Makefiles should be completely unaffected.

So, if anything, this reduces breakage rather than adding any. Or are we missing something here?

[leandro-lucarella-sociomantic]

I really think that -di shouldn't be renamed to -dw, because it doesn't following the current naming scheme for flags (in particular with regards to -w and -wi)

And as I said, I'll be happy to change it if there is consensus to merge this patch after that change.

[leandro-lucarella-sociomantic]

And I just wanted to add that without this, all it will happen is people adding -di to their dmd.conf. I know I will :D

[DmitryOlshansky]

And I just wanted to add that without this, all it will happen is people adding -di to their dmd.conf. I know I will :D

Very true.

[jmdavis]

It looks like this isn't compiling anymore, and this really should be resolved (preferably merged) prior to 2.061, or we're going to be introducing a flag that we're just going to turn around and deprecate. So, this needs to be updated so that it can compile, and Walter really should make a decision on this very soon. According to a post by Andrei in D.Announce, the deadline for pulls for 2.061 is supposed to be Sunday, and we really need this sorted out for 2.061.

[ghost]

Hey now that we have these nice new flags maybe we should consider introducing a warning for this:

struct S
{
    const int[] foo()
    {
    }
}

E.g.: Warning: const applied to method, not the return type. Put const after 'foo' if intended, or use const(int[]) to apply to the return type.

[llucax]

Hey now that we have these nice new flags maybe we should consider introducing a warning for this

I think this is really off-topic for this pull request. If this should be added, it should be enabled with -w(i), this has nothing to do with deprectations (AFAIK this syntax is not deprecated, just "dangerous").

[llucax]

This got finally merged without further discussion about -di/-dw. I really don't care which one stay, but just wanted to mention that unless something gets done, -dw will be used to explicitly tell the compiler to emit deprecations as warnings (to override any other option).

[9rnsr]

I found a big breaking introduced by this, in 2.061.

In current, all deprecated language features until 2.060 are accepted in default. For example:

void main() {
    typedef int X = 10;   // !!
    X x;
    assert(x == 10);
}

typedef was deprecated from 2.058, then we couldn't compile the code in default.
But, from 2.061, we can compile the code and run in default again.

More than worse, all deprecations which reported in semantic phase or later will break code meaning silently.

import std.stdio;
void main() {
    int[] arr;
    static if (is(typeof({ auto ptr = *arr; })))
        writeln("*arr is not deprecated");
    else
        writeln("*arr is deprecated, instead use arr.ptr");
}

The meaning of is(typeof({ auto ptr = *arr; })) is changed in default.

Therefore this is a huge breaking against the language improvement process in the past few years.

[9rnsr]

To fix the problem, we need to split deprecated language features into the two.

1. Truly deprecated features
   This group contains all language features which already deprecated in 2.060 and earlier.
   • Each of them prints deprecated message without -d switch.
   • Each of them raises an error without -d switch. (Important!!)
2. Softly deprecated features
   This group will print deprecation message for the using but not make an error in default, and may contain newly deprecated features from 2.061.
   • Each of them prints deprecated message without -d switch.
   • Each of them raises an error without -de switch. (Important!!)

[WalterBright]

Kenji, please file a regression.

[WalterBright]

Deprecation is supposed to be a simple feature. Something has gone seriously wrong with it that there is all these "levels" of deprecation, regressions, all kinds of argument about it, etc.

[9rnsr]

@WalterBright Deprecation feature/symbol has just a binary state, it is deprecated or not. But, in the reporting for the using of deprecation, two factors affect: 1. it makes an error (==aborting compilation) or not. 2. it reports a message or not. As far as I see, this regression has been caused by confusing the two factors.

[9rnsr]

OK, filed as issue 9289 - [Regression 2.061] Had been deprecated language features are enabled again in default