View mode: basic / threaded / horizontal-split · Log in · Help
July 11, 2011
Re: dmd 1.069 and 2.054 release
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.
July 11, 2011
Re: dmd 1.069 and 2.054 release
"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
July 11, 2011
Re: dmd 1.069 and 2.054 release
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
July 11, 2011
Re: dmd 1.069 and 2.054 release
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
July 11, 2011
Re: dmd 1.069 and 2.054 release
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.
July 11, 2011
Re: dmd 1.069 and 2.054 release
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/
July 12, 2011
Re: dmd 1.069 and 2.054 release
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
July 12, 2011
Re: dmd 1.069 and 2.054 release
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/
July 12, 2011
Re: dmd 1.069 and 2.054 release
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
July 12, 2011
Re: dmd 1.069 and 2.054 release
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
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home