dmd 1.069 and 2.054 release

[Jonathan M Davis]

On 2011-07-11 16:09, Michel Fortin wrote:
> On 2011-07-11 17:26:15 -0400, Andrew Wiley <wiley.andrew.j at 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