On Mon, Jul 11, 2011 at 2:10 PM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:

> On 2011-07-11 13:50, Nick Sabalausky wrote:
> > "Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.1539.1310416341.14074.digitalmars-d-announce@puremagic.com.
> ..
> >
> > > On 2011-07-11 13:09, Nick Sabalausky wrote:
> > >> Not that I feel strongly about it, but just like "scheduled for deprication", actual warnings are things that *are* valid code, too.
> Ie,
> > >> they're just messages, too. The whole point of a "warnings as errors" setting is that some people want that extra help to ensure their code
> is
> > >> perfectly pristine. (Although, personally, I've never seen
> particularly
> > >> strong reason for "warnings as errors" settings anyway.)
> > >>
> > >> To be clear, if we did have some "deprecated(scheduled)" feature and
> it
> > >> was
> > >> non-fatal even with -w, I wouldn't personally have a huge problem with
> > >> it (I never use -w anyway, just -wi). I just don't think it's so
> > >> clear-cut that "scheduled for deprication" doesn't essentially amount
> > >> to a warning.
> > >
> > > Hmm. The main problem with making the scheduled for deprecation
> messages
> > > being
> > > treated as errors with -w is that if you build with -w (as a lot of
> > > people do), it breaks your code. And the point of the message is to
> warn
> > > you that your code is _going_ to break and to _avoid_ causing immediate breakage.
> >
> > If someone doesn't want warning conditions to break their code, they
> should
> > be using -wi, not -w.
>
> Yes. But the problem is that the "scheduled for deprecation" messages are
> not
> supposed to _ever_ break code. And since warnings aren't normally added
> very
> often, compiling with -w shouldn't cause your code to suddenly break.
> Granted,
> dmd is still unstable enough that such changes do occur, but once it's
> fully
> stable, it wouldn't happen very often. But anyone can schedule something
> for
> deprecation in any library, and the whole point of _scheduling_ the
> deprecation instead of just deprecating it is to avoid breaking code. So,
> it's
> unacceptable for scheduling something for deprecation to be an error with
> -w.
> It's informational only. Warnings are _not_ only informational. They're
> telling you that there's actually something wrong with your code. It's just
> not wrong enough to be against the language spec and therefore always be an
> error. Scheduling something for deprecation is indicating that the symbol
> in
> question will be deprecated in the future and that you should change it
> before
> that happens. Your code is still fine, and it should still compile.
>
> Bottom line. Marking something as "scheduled for deprecation" should
> _never_
> break code no matter what flags you use to compile your code. Otherwise,
> there's no point to it, and we'd just be deprecating stuff immediately.


I would argue that when you compile with -w (and explicitly -w, not -wi), you're explicitly asking the compiler to break your code for warnings, and I believe that should include code scheduled for deprecation. By specifying -w, you're explicitly asking the compiler to check your code more strictly, and I see more aggressive deprecation as an acceptable part of that.

To paraphrase your description, there's something that's about to break in your code, but it's not broken yet, so if you drop -w (or switch to -wi), you can still build it. If we're taking the approach that warnings break code when -w is used, I see scheduled deprecations falling into a very similar category.

And no, this change doesn't obsolete code deprecation, it simply extends the higher standards that -w holds you to into the library space. If you don't want "scheduled for deprecation" to break your code, use -wi. You'll get all the same noise you got before, just without the breakage.

"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.1542.1310418661.14074.digitalmars-d-announce@puremagic.com...
>
> Yes. But the problem is that the "scheduled for deprecation" messages are
> not
> supposed to _ever_ break code. And since warnings aren't normally added
> very
> often, compiling with -w shouldn't cause your code to suddenly break.
> Granted,
> dmd is still unstable enough that such changes do occur, but once it's
> fully
> stable, it wouldn't happen very often. But anyone can schedule something
> for
> deprecation in any library, and the whole point of _scheduling_ the
> deprecation instead of just deprecating it is to avoid breaking code. So,
> it's
> unacceptable for scheduling something for deprecation to be an error
> with -w.
> It's informational only. Warnings are _not_ only informational. They're
> telling you that there's actually something wrong with your code.

Something *potentially* wrong. If it actually *knew* that it was wrong it would have been an error in the first place, not a warning.

And "scheduled for deprecation" is literally saying "your code *will* be wrong, and you *do* need to address it by X deadline". That's arguably even stronger than certain warnings, because some warnings (by the very nature of warnings) are false positives.

I don't really have a problem with the argument that scheduling something for deprecation shouldn't break code. But I think that's really more an argument against indiscriminate use of "warnings as errors" in general (which, again, isn't something I've ever felt a strong need for anyway - not that I'm advocating getting rid of it, that would probably annoy some people). In any case, the whole point of "warnings as errors" is that the user (for whatever possibly-questionable reason) *wants* the compiler to bail on anything that isn't guaranteed perfect (to the best of the compiler's ability).

> It's just
> not wrong enough to be against the language spec and therefore always be
> an
> error. Scheduling something for deprecation is indicating that the symbol
> in
> question will be deprecated in the future and that you should change it
> before
> that happens. Your code is still fine, and it should still compile.
>
> Bottom line. Marking something as "scheduled for deprecation" should
> _never_
> break code no matter what flags you use to compile your code. Otherwise,
> there's no point to it, and we'd just be deprecating stuff immediately.
>
> - Jonathan M Davis

On 2011-07-11 14:32, Nick Sabalausky wrote:
> "Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.1542.1310418661.14074.digitalmars-d-announce@puremagic.com...
> 
> > Yes. But the problem is that the "scheduled for deprecation" messages are
> > not
> > supposed to _ever_ break code. And since warnings aren't normally added
> > very
> > often, compiling with -w shouldn't cause your code to suddenly break.
> > Granted,
> > dmd is still unstable enough that such changes do occur, but once it's
> > fully
> > stable, it wouldn't happen very often. But anyone can schedule something
> > for
> > deprecation in any library, and the whole point of _scheduling_ the
> > deprecation instead of just deprecating it is to avoid breaking code. So,
> > it's
> > unacceptable for scheduling something for deprecation to be an error
> > with -w.
> > It's informational only. Warnings are _not_ only informational. They're
> > telling you that there's actually something wrong with your code.
> 
> Something *potentially* wrong. If it actually *knew* that it was wrong it would have been an error in the first place, not a warning.
> 
> And "scheduled for deprecation" is literally saying "your code *will* be wrong, and you *do* need to address it by X deadline". That's arguably even stronger than certain warnings, because some warnings (by the very nature of warnings) are false positives.
> 
> I don't really have a problem with the argument that scheduling something for deprecation shouldn't break code. But I think that's really more an argument against indiscriminate use of "warnings as errors" in general (which, again, isn't something I've ever felt a strong need for anyway - not that I'm advocating getting rid of it, that would probably annoy some people). In any case, the whole point of "warnings as errors" is that the user (for whatever possibly-questionable reason) *wants* the compiler to bail on anything that isn't guaranteed perfect (to the best of the compiler's ability).

Honestly, I would consider it bad practice to leave warnings in code. Leaving them in as you're messing with code is fine, because they're not immediately fatal, but they _are_ problems. If they weren't, then they shouldn't have been warnings in the first place. But I tend to mostly agree with Walter that something should either be an error or not. Warnings are for things which are definitely wrong but not illegal in the language. Certainly, that's how dmd treats them. I know that other compilers love to complain about other stuff that doesn't really matter but _could_ be a bug, but once you do that, people start letting warnings sit there, and _real_ problems get buried in the mess.

So, obviously, we have a very different view of warnings. But regardless, it's going to cause problems if scheduling something for deprecation causes code to break. The whole point is to inform programmers that they're going to need to change their code soon and to avoid immediate code breakage. Treating "scheduled for deprecation" as a warning doesn't do that.

- Jonathan M Davis

On 2011-07-11 14:32, Nick Sabalausky wrote:
> "Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.1542.1310418661.14074.digitalmars-d-announce@puremagic.com...
> 
> > Yes. But the problem is that the "scheduled for deprecation" messages are
> > not
> > supposed to _ever_ break code. And since warnings aren't normally added
> > very
> > often, compiling with -w shouldn't cause your code to suddenly break.
> > Granted,
> > dmd is still unstable enough that such changes do occur, but once it's
> > fully
> > stable, it wouldn't happen very often. But anyone can schedule something
> > for
> > deprecation in any library, and the whole point of _scheduling_ the
> > deprecation instead of just deprecating it is to avoid breaking code. So,
> > it's
> > unacceptable for scheduling something for deprecation to be an error
> > with -w.
> > It's informational only. Warnings are _not_ only informational. They're
> > telling you that there's actually something wrong with your code.
> 
> Something *potentially* wrong. If it actually *knew* that it was wrong it would have been an error in the first place, not a warning.
> 
> And "scheduled for deprecation" is literally saying "your code *will* be wrong, and you *do* need to address it by X deadline". That's arguably even stronger than certain warnings, because some warnings (by the very nature of warnings) are false positives.
> 
> I don't really have a problem with the argument that scheduling something for deprecation shouldn't break code. But I think that's really more an argument against indiscriminate use of "warnings as errors" in general (which, again, isn't something I've ever felt a strong need for anyway - not that I'm advocating getting rid of it, that would probably annoy some people). In any case, the whole point of "warnings as errors" is that the user (for whatever possibly-questionable reason) *wants* the compiler to bail on anything that isn't guaranteed perfect (to the best of the compiler's ability).

Honestly, I would consider it bad practice to leave warnings in code. Leaving them in as you're messing with code is fine, because they're not immediately fatal, but they _are_ problems. If they weren't, then they shouldn't have been warnings in the first place. But I tend to mostly agree with Walter that something should either be an error or not. Warnings are for things which are definitely wrong but not illegal in the language. Certainly, that's how dmd treats them. I know that other compilers love to complain about other stuff that doesn't really matter but _could_ be a bug, but once you do that, people start letting warnings sit there, and _real_ problems get buried in the mess.

So, obviously, we have a very different view of warnings. But regardless, it's going to cause problems if scheduling something for deprecation causes code to break. The whole point is to inform programmers that they're going to need to change their code soon and to avoid immediate code breakage. Treating "scheduled for deprecation" as a warning doesn't do that.

- Jonathan M Davis

Jonathan M Davis:
> If it gives you  stack trace though, I guess that it would help, though it would certainly be ugly.

It's not too ugly at all, since it's a template stack trace - so in a lot of cases, it isn't a very long list.

Regardless though, something is better than nothing.

> Fortunately, in the case of something like tolower, _every_ function called

Indeed, though another one was repeat() with replicate(), which isn't
as simple without the compiler's help.

While a proper warning is surely better than a filthy hack, if it's not coming, adding a versioned static assert is a low cost alternative we can do immediately.

On 2011-07-11 17:26:15 -0400, Andrew Wiley <wiley.andrew.j@gmail.com> said:

> To paraphrase your description, there's something that's about to break in
> your code, but it's not broken yet, so if you drop -w (or switch to -wi),
> you can still build it. If we're taking the approach that warnings break
> code when -w is used, I see scheduled deprecations falling into a very
> similar category.

To paraphrase your paraphrase, there's something that's about to break in your code, but it's not broken yet so if you add -d you can still build it... I'm simply side-stepping that discussion about implementation to illustrate that you just described the purpose of the 'deprecated' keyword.

Personally, I think adding warnings or even messages for each and every scheduled-for-deprecation function is too much. Just adding it to the documentation and adding a note in the changelog should be enough. Then, one day, it'll be deprecated for real and you'll get an error unless you use -d.

I think one deprecation level is enough. The scheduled for deprecation step is still useful so that early adopters can try the new way to do things and report problems. Once it's been stable and adopted by some people you can ask for mass adoption by adding a deprecation message. But nagging users when they're using something that is scheduled for deprecation is pretty much the same as having the feature deprecated immediately in my view.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On 2011-07-11 16:09, Michel Fortin wrote:
> On 2011-07-11 17:26:15 -0400, Andrew Wiley <wiley.andrew.j@gmail.com> said:
> > To paraphrase your description, there's something that's about to break in your code, but it's not broken yet, so if you drop -w (or switch to -wi), you can still build it. If we're taking the approach that warnings break code when -w is used, I see scheduled deprecations falling into a very similar category.
> 
> To paraphrase your paraphrase, there's something that's about to break in your code, but it's not broken yet so if you add -d you can still build it... I'm simply side-stepping that discussion about implementation to illustrate that you just described the purpose of the 'deprecated' keyword.
> 
> Personally, I think adding warnings or even messages for each and every scheduled-for-deprecation function is too much. Just adding it to the documentation and adding a note in the changelog should be enough. Then, one day, it'll be deprecated for real and you'll get an error unless you use -d.
> 
> I think one deprecation level is enough. The scheduled for deprecation step is still useful so that early adopters can try the new way to do things and report problems. Once it's been stable and adopted by some people you can ask for mass adoption by adding a deprecation message. But nagging users when they're using something that is scheduled for deprecation is pretty much the same as having the feature deprecated immediately in my view.

Well, we've been doing it with pragmas for a while (which was Andrei's idea IIRC). We just haven't been very organized about it, and I've been trying to better organize what we're doing with deprecation. And since it only works with full modules or with templated functions (since otherwise the pragma would bug everyone rather than just those using the symbol in question), it can't be used everywhere anyway.

The problem with not having a message is that people aren't likely to look at the documentation unless they aren't all that familiar with the function, so people will continue to happily use the function up to the point that it's actually deprecated, and then they'll be surpised when their code breaks (since suddenly needing -d for your code to compile _is_ breaking your code). Walter in particular doesn't like the idea of people suddenly having to go and change their build scripts to use -d or immediately fix their code without any warning, which is why we don't deprecate immediately. And just putting it in the documentation really isn't much better than deprecating it immediately, because the very people who most need to see the message are the least likely to read the documentation.

Now, if most people don't like the idea of messages about stuff being scheduled for deprecation being printed, then we'll likely stop having them. But it kind of defeats the purpose of scheduling it for deprecation rather than immediately deprecating it if we do that.

- Jonathan M Davis

On 2011-07-11 19:56:28 -0400, "Jonathan M Davis" <jmdavisProg@gmx.com> said:

> The problem with not having a message is that people aren't likely to look at
> the documentation unless they aren't all that familiar with the function, so
> people will continue to happily use the function up to the point that it's
> actually deprecated, and then they'll be surpised when their code breaks
> (since suddenly needing -d for your code to compile _is_ breaking your code).
> Walter in particular doesn't like the idea of people suddenly having to go and
> change their build scripts to use -d or immediately fix their code without any
> warning, which is why we don't deprecate immediately.

Very true. I take this as an indication that the current implementation of the `deprecated` keyword is too strict by default. If it's bad that using a deprecated function breaks the code by default, then make using a deprecated function non-fatal unless the user asks for it to be fatal.

To me, something scheduled for deprecation means that you know it'll be deprecated eventually, but that for now it's still okay using it. For instance, std.xml could be scheduled for deprecation, once we have a replacement we can deprecate it and nag people about using the new one. If you nag people immediately, then it's almost as good as deprecated already.

That said, there's also the problem that the implementation of the "scheduled for deprecation" messages isn't very good. It'll work for modules, it'll work for template functions, but you don't know who imported the module or called the function. Moreover, calling a deprecated function from within a deprecated function yields no error; calling a scheduled-for-deprecation function from a scheduled-for-deprecation one or even a deprecated one will show an annoying message. Does that makes sense?

Instead of working on fragile workarounds, better fix the problem, which is that `deprecated` is too strict by default.


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Jonathan M Davis, el 11 de julio a las 18:15 me escribiste:
> > Despite the confusing non-standard descriptions in --help, -w is the "Treat warnings as errors" setting, so it *should* stop compilation - that's the whole point of -w. The proper "Turn warnings on" setting is -wi, not -w.
> 
> True. But when we're dealing with messages for something which is scheduled for deprecation

What's the point of "scheduled for deprecation" anyway? Things are deprecated, or aren't, anything else should be in the documentation. You can always use deprecated features using a compiler, so again... what's the point of "scheduled for deprectation"? I can't really understand that concept.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
<mazzi> gmail is down?
 <Luca> waiting for mail.google.com....
<mazzi> ya vendí todas mis acciones de google en los mercados asiaticos
 <Luca> se viene la ecatombe
<mazzi> mal
<mazzi> es como que te corten el porno en una tarde al pedo en tu casa

On Tuesday 12 July 2011 01:28:11 Leandro Lucarella wrote:
> Jonathan M Davis, el 11 de julio a las 18:15 me escribiste:
> > > Despite the confusing non-standard descriptions in --help, -w is the "Treat warnings as errors" setting, so it *should* stop compilation - that's the whole point of -w. The proper "Turn warnings on" setting is -wi, not -w.
> > 
> > True. But when we're dealing with messages for something which is scheduled for deprecation
> 
> What's the point of "scheduled for deprecation" anyway? Things are deprecated, or aren't, anything else should be in the documentation. You can always use deprecated features using a compiler, so again... what's the point of "scheduled for deprectation"? I can't really understand that concept.

The idea is to have 3 stages while deprecating something.

1. Scheduled for Deprecation.
2. Deprecated.
3. Removed.

When a symbol has been deprecated, -d is required to compile any code using that symbol. So, deprecation breaks code. You either have to change your code so that it doesn't use the deprecated symbol, or you have to change your build scripts to use -d. In either case, deprecating a symbol without warning is going to cause problems for anyone maintaining code which uses that symbol.

So, in the "scheduled for deprecation" stage, programmers are warned that a symbol will be deprecated in the near future, but the symbol hasn't been deprecated yet, so no code is broken, and no build scripts need to b changed. Programmers then have time to rework their code to no longer use the soon-to- be deprecated symbol without having their code break or having to change their build scripts.

If a programmer has not done anything about the symbol before it's actually deprecated, then they will have to change their code or change their bulid scripts to use -d when the symbol is actually deprecated, but because there was the "scheduled for deprecation" phase, the programmer at least had fair warning about the impending code breakage and could have avoided it had they wanted to.

What it comes down to is that we don't want to suddenly break anyone's code. If breaking changes need to be made, we want to provide a smooth path, giving people time to rework their code rather than suddenly breaking their code. Needing to rework your code can be annoying enough without your code suddenly breaking due to a library update.

- Jonathan M Davis