Community

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/

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