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

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

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

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

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

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

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

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

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

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