www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 9289] New: [Regression 2.061] Had been deprecated language features are enabled again in default

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9289

           Summary: [Regression 2.061] Had been deprecated language
                    features are enabled again in default
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: regression
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: k.hara.pg gmail.com


--- Comment #0 from Kenji Hara <k.hara.pg gmail.com> 2013-01-09 21:32:29 PST ---
This regression is introduced by the "Make deprecations as warnings the
default.
From my comment:
https://github.com/D-Programming-Language/dmd/pull/1287#issuecomment-12080557

---

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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 09 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9289


Leandro Lucarella <leandro.lucarella sociomantic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |leandro.lucarella sociomant
                   |                            |ic.com


--- Comment #1 from Leandro Lucarella <leandro.lucarella sociomantic.com>
2013-01-10 02:19:27 PST ---
(In reply to comment #0)
 This regression is introduced by the "Make deprecations as warnings the
 default.
 From my comment:
 https://github.com/D-Programming-Language/dmd/pull/1287#issuecomment-12080557

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

How the default deprecation handling is changed compared to using -d in 2.060? I'm not entirely convinced is really a regression if is the same. I understand there is a problem, but I wonder if your suggested solution is really needed:
 To fix the problem, we need to split deprecated language features into the two.

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

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

Shouldn't be just plain errors the things that you don't want to allow them at all? Or are you suggesting just a migration path to the new way of presenting deprecations? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 10 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9289


Kenji Hara <k.hara.pg gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull


--- Comment #2 from Kenji Hara <k.hara.pg gmail.com> 2013-01-10 02:32:35 PST ---
(In reply to comment #1)
I brushed up my idea: The -dw/-de switches affect to the use of deprecated
"symbols", but doesn't to the use of deprecated language features.

You can see my implementation.
https://github.com/D-Programming-Language/dmd/pull/1459

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 10 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9289


Jonathan M Davis <jmdavisProg gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg gmx.com


--- Comment #3 from Jonathan M Davis <jmdavisProg gmx.com> 2013-01-10 02:37:57
PST ---
 I brushed up my idea: The -dw/-de switches affect to the use of deprecated
 "symbols", but doesn't to the use of deprecated language features.

That's probably the right way to handle it. Deprecated language features already effectively have the separation between soft and hard deprecation, because they generally get normal warnings before being deprecated, whereas deprecated symbols aren't part of that, since they aren't hard-coded into the compiler. We can just go back to treating deprecated language features the way that we have and take advantage of the recent changes to deprecated for deprecated symbols. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 10 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9289



--- Comment #4 from Leandro Lucarella <leandro.lucarella sociomantic.com>
2013-01-10 06:56:59 PST ---
I still don't understand why is it a good idea to treat deprecated language
features differently from deprecated symbols. Deprecated language features get
a warning but you only get a warning if you use -w, which implies having
warnings for lots of other stuff that have nothing to do with deprecations.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 10 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9289



--- Comment #5 from Leandro Lucarella <leandro.lucarella sociomantic.com>
2013-01-10 07:03:04 PST ---
Well I see the second example from Kenji doesn't print any warnings, that's
certainly a problem. But the first example works just fine, it compiles issuing
a warning. That is what it's supposed to do, that was the original idea. Is not
a bug, is a feature :)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 10 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9289


David Nadlinger <code klickverbot.at> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code klickverbot.at


--- Comment #6 from David Nadlinger <code klickverbot.at> 2013-01-11 16:09:52
PST ---
I'm not sold on the idea of adding additional complexity to the behavior of the
deprecation-related switches.

If you feel that some language features should be more than just deprecated by
now, why don't chose the obvious option of just turning them into an error?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 11 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9289


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla digitalmars.com


--- Comment #7 from Walter Bright <bugzilla digitalmars.com> 2013-01-11
17:30:22 PST ---
(In reply to comment #6)
 I'm not sold on the idea of adding additional complexity to the behavior of the
 deprecation-related switches.
 
 If you feel that some language features should be more than just deprecated by
 now, why don't chose the obvious option of just turning them into an error?

I agree, I think we are overengineering this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 11 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9289



--- Comment #8 from Jonathan M Davis <jmdavisProg gmx.com> 2013-01-11 19:12:02
PST ---
Honestly, I think that it would be great in general to be able to distinguish
between soft deprecation (warn about it) and hard deprecation (make it an
error), but I can also understand not wanting to add that sort of complication
to the feature, especially since it's a feature that should be needed
relatively rarely. And if you only get one of the two, soft deprecations are
far less disruptive, and I think that we were right to make deprecated warn by
default, but it does pose a bit of a problem for the language features.

For that, I think that there are two basic approaches which make sense:

1. Make deprecated work as it has been for language features and use normal
warnings when we want to "soft" deprecate a language feature, which is exactly
what we have been doing. But we keep the new behavior (warn by default) for the
deprecated keyword.

2. Make at least some of the currently deprecated language features into errors
rather than have them be deprecated. Then have deprecation for language
features be exactly the same as it is for the deprecated keyword, so some
features end up being errors which can't be disabled, and some become warnings
rather than errors by default. If we go that route, we should probably also
think about making some of the current warnings into deprecation warnings (e.g.
when skipping the use of override).

The second approach would probably be the cleaner of the two, but it does mean
that we lose the ability to give an error for language deprecation by default
and still allow for the feature to be used. On the other hand, using
deprecation warnings instead of normal warnings for deprecating features would
be great, because then people don't have to use -w or -wi to see them. And that
would make doing stuff like deprecating delete much smoother, since it would
ensure that anyone using it got bugged about it rather than just those folks
who compile with warnings enabled. It also keeps its behavior in line with the
deprecated keyword, which would probably be a good idea if we can reasonably do
so.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 11 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9289



--- Comment #9 from Leandro Lucarella <leandro.lucarella sociomantic.com>
2013-01-21 03:32:36 PST ---
I don't see why language features should be treated differently. The only
problem I see right now is deprecated features are not being warn when gagging
(I think that's the term for when errors are silent to evaluate something at
compile time that is OK to fail, like tratis(compile) or static if's). I think
usage of deprecated features there should trigger a warning too. If the idea
behind some of this construct is just to test if an old feature is still
working, maybe that should be fixed and "calculated" through the compiler's
version or something like that.

If we keep deprecated language features as errors by default, we will end up
with the exact same problem we had before making deprecations as warnings the
default. Why would we want to do that?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 21 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9289


Kenji Hara <k.hara.pg gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|pull                        |
           Severity|regression                  |major


--- Comment #10 from Kenji Hara <k.hara.pg gmail.com> 2013-01-28 20:04:48 PST
---
(In reply to comment #9)
 I don't see why language features should be treated differently. The only
 problem I see right now is deprecated features are not being warn when gagging
 (I think that's the term for when errors are silent to evaluate something at
 compile time that is OK to fail, like tratis(compile) or static if's). I think
 usage of deprecated features there should trigger a warning too. If the idea
 behind some of this construct is just to test if an old feature is still
 working, maybe that should be fixed and "calculated" through the compiler's
 version or something like that.
 
 If we keep deprecated language features as errors by default, we will end up
 with the exact same problem we had before making deprecations as warnings the
 default. Why would we want to do that?

OK. I was convinced that it is the right thing to some extent. To make things keep simple, deprecations between language feature and user-defined symbols should be treated by a same way. I withdraw this regression, by lowering priority to "major".
 The only problem I see right now is deprecated features are not being warn
when gagging

I'd try to implement it in experiment. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 28 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9289



--- Comment #11 from Leandro Lucarella <leandro.lucarella sociomantic.com>
2013-01-29 03:04:02 PST ---
(In reply to comment #10)
 (In reply to comment #9)
 If we keep deprecated language features as errors by default, we will end up
 with the exact same problem we had before making deprecations as warnings the
 default. Why would we want to do that?

OK. I was convinced that it is the right thing to some extent. To make things keep simple, deprecations between language feature and user-defined symbols should be treated by a same way. I withdraw this regression, by lowering priority to "major".

I changed the title too, feel free to edit if you think is not entirely correct.
 The only problem I see right now is deprecated features are not being warn
when gagging

I'd try to implement it in experiment.

Great! Thanks. Unless I'm missing something (I probably am :), this should be enough: --- diff --git a/src/mars.c b/src/mars.c index 612b205..588ca40 100644 --- a/src/mars.c +++ b/src/mars.c -269,7 +269,7 void vdeprecation(Loc loc, const char *format, va_list ap, static const char *header = "Deprecation: "; if (global.params.useDeprecated == 0) verror(loc, format, ap, p1, p2, header); - else if (global.params.useDeprecated == 2 && !global.gag) + else if (global.params.useDeprecated == 2) verrorPrint(loc, header, format, ap, p1, p2); } --- I don't have time now to make testcases and verify this would work though. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 29 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9289



--- Comment #12 from Leandro Lucarella <leandro.lucarella sociomantic.com>
2013-01-29 10:30:13 PST ---
https://github.com/D-Programming-Language/dmd/pull/1581

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 29 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9289



--- Comment #13 from Leandro Lucarella <leandro.lucarella sociomantic.com>
2013-01-29 10:31:17 PST ---
(In reply to comment #11)
 I don't have time now to make testcases and verify this would work though.

Woops! I made some time :D -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 29 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9289



--- Comment #14 from Leandro Lucarella <leandro.lucarella sociomantic.com>
2013-01-30 02:32:17 PST ---
Comment from don to the pull request:
 Although this idea is appealing in some circumstances (specifically,
 when you have just upgraded from one compiler version to another), in
 others it is NOT what you want, and it breaks existing code.  Using
 your test case, suppose you have the code:
 
 ---
 auto  foo(P)(P p){
     static if ( is(typeof( *p)) {
       return *p;
     } else static if (is(typeof(p[0])) {
        return p[0];
     } else static assert(0, "unsupported");
 }
 ---
 
 Currently, if -d is not specified, passing an array to this will work
 correctly: the second return will be used. If -d is specified, it will
 also work correctly: the first return will be used. With your patch,
 the code will not work at all.  If I have a codebase where I never
 even use -d, this pull request is suddenly making that obscure,
 stupid, long-deprecated feature have an impact on my code!
 
 I think we just have to accept that having deprecated features still
 accepted in the language is a major annoyance. I'm not sure that there
 is a perfect solution. We should really try to get rid of them.

The first one will work correctly *BUT* you'll get the warning, so you can inspect the code and fix it. I think this solution is not worse than the current situation where what previously had fail, now passes silently. If you are using deprecated features in your code, your code is broken (or at least outdated) and you should fix it (or update it). Now those obscure changes on behaviour are there, and you'll never find out. This pull request gives visibility to this issues and allows you to update your code. I really don't see the problem with this solution. I don't think is a big annoyance. The default behaviour is to warn you when you are using something that's deprecated so you can update it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 30 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9289



--- Comment #15 from Jonathan M Davis <jmdavisProg gmx.com> 2013-01-30 09:13:55
PST ---
We should probably seriously consider making some of the currently deprecated
features an outright error rather than leaving them as deprecated (especially
if they've been deprecated for quite a while). That would reduce any problems
caused by deprecated features suddenly compiling with warning messages by
default.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 30 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9289



--- Comment #16 from Don <clugdbug yahoo.com.au> 2013-02-01 02:05:41 PST ---
(In reply to comment #14)
 If you are using deprecated features in your code, your code is broken (or at
 least outdated) and you should fix it (or update it). 

Yes, but this change would affect code which is NOT using deprecated features. You have completely misunderstood my point.
 Now those obscure changes
 on behaviour are there, and you'll never find out. This pull request gives
 visibility to this issues and allows you to update your code.

No, it has the reverse behaviour. You would need to update your code to specifically recognize deprecated features! The existing behaviour is that, if you are not using -d, deprecated language features act as if they do not exist. This change would make deprecated features have an effect on ALL code. Even when not compiling with -d. I am completely opposed to this change. It creates a special case which introduces new problems that are at least as bad as the old ones. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 01 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9289



--- Comment #17 from David Nadlinger <code klickverbot.at> 2013-02-01 06:17:38
PST ---
(In reply to comment #16)
 This change would make deprecated features have an effect on ALL code. Even
 when not compiling with -d.

That change is already in Git master. I'm pretty convinced that the best way of fixing any related issues is just to finally remove any deprecated language features.
 I am completely opposed to this change. It creates a special case which
 introduces new problems that are at least as bad as the old ones.

What exactly do you regard as the special case here? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 01 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9289



--- Comment #18 from Leandro Lucarella <leandro.lucarella sociomantic.com>
2013-02-04 02:29:01 PST ---
(In reply to comment #17)
 (In reply to comment #16)
 This change would make deprecated features have an effect on ALL code. Even
 when not compiling with -d.

That change is already in Git master. I'm pretty convinced that the best way of fixing any related issues is just to finally remove any deprecated language features.

Not only master, is in the last release.
 I am completely opposed to this change. It creates a special case which
 introduces new problems that are at least as bad as the old ones.

What exactly do you regard as the special case here?

Yeah, I think it was pretty clear that making deprecated features as warnings was, at some point, a breaking change, unless you use -de to achieve the old behaviour. I still have to review Don's example, because evidently I missed his point. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 04 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9289



--- Comment #19 from Don <clugdbug yahoo.com.au> 2013-02-04 02:57:16 PST ---
Currently, 

is(typeof(  xxxx )) NEVER, EVER produces an error message, no matter what xxxx
is.

You can put any kind of nonsense operation in there, and it will still compile,
and return false.


This change would create a horrific special case:

is(typeof(  xxxx )) never produces an error message, no matter what xxxx is,
unless xxxx happened to be legal in an ancient version of DMD but is not legal
in current DMD.

This is a killer for generic code.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 04 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9289



--- Comment #20 from Jonathan M Davis <jmdavisProg gmx.com> 2013-02-04 03:05:04
PST ---
I agree with David on this one. If there's stuff here that really shouldn't be
compiling, then lets finally remove it. Code shouldn't need to be checking
whether deprecated features work or not. It shouldn't be trying to use them in
the first place. And many of the currently deprecated language features have
been deprecated for some time ande really should be outright removed. In
general, warning for deprecations just works a lot better, so I'd hate to lose
that.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 04 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9289



--- Comment #21 from Leandro Lucarella <leandro.lucarella sociomantic.com>
2013-02-04 08:34:16 PST ---
BTW, Don, I see what you mean now, but that problem existed before making
deprecations emit warnings by default (if you used -d). The default was only
changed.

I know that introduces some kind of regression in a sense because code will
behave differently unless you use -de, but I think this is only a transitional
problem, as again, only the default changed.

If some deprecated feature gets too problematic, I agree with David that the
best solution might be to just remove them, specially if they have been
deprecated long ago...

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 04 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9289



--- Comment #22 from Don <clugdbug yahoo.com.au> 2013-02-26 00:51:42 PST ---
(In reply to comment #21)
 BTW, Don, I see what you mean now, but that problem existed before making
 deprecations emit warnings by default (if you used -d). The default was only
 changed.

It is true that there's always been a difference in is(typeof()) between when compiled with -d, and when not. However, historically that hasn't mattered so much -- it has been crazy to compile with -d. This bug report gives the -d behaviour a higher priority than the no-flags behaviour. You're assuming that when a deprecated feature appears while errors are gagged, it's because it used to compile. That assumption is false. Such code might, or might not be a use of a deprecated feature. There is no way to tell. The patch moves it from "assume it's never a deprecated feature" to "assume it's always a deprecated feature". Effectively, you're changing an accepts-invalid bug to a rejects-valid bug. It's not an improvement. Here's what I think should happen: -dXX should give a warning (not an error, not silence), whenever a deprecated feature is used when errors are gagged. In other cases, the existing behaviour (silence) should be preserved. Basically I think that with any form of -d option, deprecated features should never compile without generating a warning (even when errors are gagged). When -d is not used, it should be as if those features don't exist -- there should be no difference between something that is deprecated, vs any other sort of error. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 26 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9289


Leandro Lucarella <leandro.lucarella sociomantic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Deprecated language         |[Regression 2.061] Had been
                   |features should be warn too |deprecated language
                   |when errors are normally    |features are enabled again
                   |silented                    |in default


--- Comment #23 from Leandro Lucarella <leandro.lucarella sociomantic.com>
2013-02-26 03:26:54 PST ---
(In reply to comment #22)
 (In reply to comment #21)
 BTW, Don, I see what you mean now, but that problem existed before making
 deprecations emit warnings by default (if you used -d). The default was only
 changed.

It is true that there's always been a difference in is(typeof()) between when compiled with -d, and when not. However, historically that hasn't mattered so much -- it has been crazy to compile with -d.

Agreed.
 This bug report gives the -d behaviour a higher priority than 
 the no-flags behaviour. You're assuming that when a deprecated feature appears
 while errors are gagged, it's because it used to compile. That assumption is
 false. 

Yes, as I said I understand what you mean and agree too. I'll roll back the title to the original one to avoid spreading this confusion.
 Such code might, or might not be a use of a deprecated feature. There is no way
 to tell. The patch moves it from "assume it's never a deprecated feature" to
 "assume it's always a deprecated feature".
 Effectively, you're changing an accepts-invalid bug to a rejects-valid bug.
 It's not an improvement.
 
 Here's what I think should happen:
 
 -dXX should give a warning (not an error, not silence), whenever a deprecated
 feature is used when errors are gagged.
 In other cases, the existing behaviour (silence) should be preserved.
 
 Basically I think that with any form of -d option, deprecated features should
 never compile without generating a warning (even when errors are gagged). When
 -d is not used, it should be as if those features don't exist -- there should
 be no difference between something that is deprecated, vs any other sort of
 error.

-- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 26 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9289



--- Comment #24 from Leandro Lucarella <leandro.lucarella sociomantic.com>
2013-02-26 03:38:50 PST ---
Woops! I wanted to commit only the title change...

(In reply to comment #22)
 Such code might, or might not be a use of a deprecated feature. There is no way
 to tell. The patch moves it from "assume it's never a deprecated feature" to
 "assume it's always a deprecated feature".
 Effectively, you're changing an accepts-invalid bug to a rejects-valid bug.
 It's not an improvement.

Again, agreed.
 Here's what I think should happen:
 
 -dXX should give a warning (not an error, not silence), whenever a deprecated
 feature is used when errors are gagged.

You're talking about a new flag I guess...
 In other cases, the existing behaviour (silence) should be preserved.

Only when gagged I assume.
 Basically I think that with any form of -d option, deprecated features should
 never compile without generating a warning (even when errors are gagged).

Except for plain -d I guess. That's the original meaning of -d, silence everything.
 When -d is not used, it should be as if those features don't exist -- there
should
 be no difference between something that is deprecated, vs any other sort of
 error.

Only when errors are gagged I guess. Otherwise is going back to where we started. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 26 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9289



--- Comment #25 from Don <clugdbug yahoo.com.au> 2013-02-26 04:37:10 PST ---
(In reply to comment #24)
 Woops! I wanted to commit only the title change...
 
 (In reply to comment #22)
 Such code might, or might not be a use of a deprecated feature. There is no way
 to tell. The patch moves it from "assume it's never a deprecated feature" to
 "assume it's always a deprecated feature".
 Effectively, you're changing an accepts-invalid bug to a rejects-valid bug.
 It's not an improvement.

Again, agreed.
 Here's what I think should happen:
 
 -dXX should give a warning (not an error, not silence), whenever a deprecated
 feature is used when errors are gagged.

You're talking about a new flag I guess...

Not necessarily. It could be done with -dw for example.
 In other cases, the existing behaviour (silence) should be preserved.

Only when gagged I assume.

Yes, otherwise it's an error.
 
 Basically I think that with any form of -d option, deprecated features should
 never compile without generating a warning (even when errors are gagged).

Except for plain -d I guess. That's the original meaning of -d, silence everything.

Possibly. We should just kill that, it's ridiculous.
 When -d is not used, it should be as if those features don't exist -- there
should
 be no difference between something that is deprecated, vs any other sort of
 error.

Only when errors are gagged I guess. Otherwise is going back to where we started.

When errors aren't gagged, using a deprecated feature is just an error. (The wording may mention that it's deprecated, but otherwise it's a normal error). When errors are gagged, it's again just an error, but nothing is printed. When compiled with -dw, whenever anything deprecated is encountered, display a warning message. Display this even if errors are gagged. ie, anything deprecated is either a normal error, or noisy accepted, and this is not affected by gagging. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 26 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9289



--- Comment #26 from Leandro Lucarella <leandro.lucarella sociomantic.com>
2013-02-27 09:24:34 PST ---
(In reply to comment #25)
 -dXX should give a warning (not an error, not silence), whenever a deprecated
 feature is used when errors are gagged.

You're talking about a new flag I guess...

Not necessarily. It could be done with -dw for example.

But then make -dw mean something different than <no flag at all>, right? Just trying to understand your suggestion.
 In other cases, the existing behaviour (silence) should be preserved.

Only when gagged I assume.

Yes, otherwise it's an error.

Mmm, an error? Using -de I guess, if that's the default this is like reverting the "make deprecations issue warnings by default".
 Basically I think that with any form of -d option, deprecated features should
 never compile without generating a warning (even when errors are gagged).

Except for plain -d I guess. That's the original meaning of -d, silence everything.

Possibly. We should just kill that, it's ridiculous.

Maybe.
 Only when errors are gagged I guess. Otherwise is going back to where we
 started.

When errors aren't gagged, using a deprecated feature is just an error. (The wording may mention that it's deprecated, but otherwise it's a normal error). When errors are gagged, it's again just an error, but nothing is printed.

Why should it be an error to use a deprecated feature? I still don't understand why is this desirable when it was the whole point of making "deprecation as warnings by default". With this, you upgrade to a new DMD version and your code gets broken if you happened to be using a recently deprecated feature instead of just getting a deprecation message. Deprecating something means "it will be removed in the future" not "it already have been removed". And if you used some deprecated feature where errors are gagged, you're application will change its behaviour without any warnings.
 When compiled with -dw, whenever anything deprecated is encountered, display a
 warning message. Display this even if errors are gagged.
 
 ie, anything deprecated is either a normal error, or noisy accepted, and this
 is not affected by gagging.

I think this really makes the feature useless. If you don't use -dw, your code won't compile. If you use it, you'll potentially get a lot of spurious warnings about gagged code that is using some feature that used to have a different meaning a while ago. I think that's far from ideal... If we leave things are they are now, the only problem I see is you don't know if some piece of error-gagged code uses a deprecated feature or not, and you'll only find out when the feature is completely removed, if you are lucky enough to notice the program changed its behaviour (if we keep deprecated features as errors, this will happen as soon as the feature gets deprecated instead of removed). Maybe we can add a flag (-dv for verbose maybe?) to print warnings for deprecated errors even when errors are gagged. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 27 2013