View mode: basic / threaded / horizontal-split · Log in · Help
January 10, 2013
[Issue 9289] New: [Regression 2.061] Had been deprecated language features are enabled again in default
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: -------
January 10, 2013
[Issue 9289] [Regression 2.061] Had been deprecated language features are enabled again in default
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: -------
January 10, 2013
[Issue 9289] [Regression 2.061] Had been deprecated language features are enabled again in default
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: -------
January 10, 2013
[Issue 9289] [Regression 2.061] Had been deprecated language features are enabled again in default
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: -------
January 10, 2013
[Issue 9289] [Regression 2.061] Had been deprecated language features are enabled again in default
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: -------
January 10, 2013
[Issue 9289] [Regression 2.061] Had been deprecated language features are enabled again in default
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: -------
January 12, 2013
[Issue 9289] [Regression 2.061] Had been deprecated language features are enabled again in default
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: -------
January 12, 2013
[Issue 9289] [Regression 2.061] Had been deprecated language features are enabled again in default
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: -------
January 12, 2013
[Issue 9289] [Regression 2.061] Had been deprecated language features are enabled again in default
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: -------
January 21, 2013
[Issue 9289] [Regression 2.061] Had been deprecated language features are enabled again in default
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: -------
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home