Make deprecations as warnings the default #1287

Merged
merged 1 commit into from Dec 23, 2012

Conversation

Projects
None yet
7 participants

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.

Make deprecations as warnings the default
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.
Member

jmdavis commented Nov 14, 2012

-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.

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

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: D-Programming-Language#1292

Owner

WalterBright commented Nov 18, 2012

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.

Member

alexrp commented Nov 18, 2012

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

Member

jmdavis commented Nov 18, 2012

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?

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.

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

Member

DmitryOlshansky commented Nov 25, 2012

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.

Member

jmdavis commented Dec 22, 2012

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.

WalterBright added a commit that referenced this pull request Dec 23, 2012

Merge pull request #1287 from leandro-lucarella-sociomantic/deprecati…
…on-warnings-as-default

Make deprecations as warnings the default

@WalterBright WalterBright merged commit 6211887 into dlang:master Dec 23, 2012

1 check failed

default Fail: 10
Details

9rnsr added a commit that referenced this pull request Dec 23, 2012

fix up for pull #1287 - Make deprecations as warnings the default
Add -de switch for some deprecation tests in fail_compilation
@ghost

ghost commented Dec 23, 2012

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.

Contributor

llucax commented Dec 23, 2012

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").

Contributor

llucax commented Dec 23, 2012

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).

Member

9rnsr commented Jan 10, 2013

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.

Member

9rnsr commented Jan 10, 2013

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!!)
Owner

WalterBright commented Jan 10, 2013

Kenji, please file a regression.

Owner

WalterBright commented Jan 10, 2013

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.

Member

9rnsr commented Jan 10, 2013

@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.

Member

9rnsr commented Jan 10, 2013

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

timotheecour pushed a commit to timotheecour/dlang.org that referenced this pull request Dec 4, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment