On Wed, 07 Nov 2012 15:26:20 -0600, Jonathan M Davis <[email protected]>
wrote:
On Wednesday, November 07, 2012 14:16:26 monarch_dodra wrote:
I'm not going to propose a solution in this post, but I think
this is a good starting point for more discussion. Thoughts?
There's a relatively easy solution to this - just add the concept of
soft and
hard deprecation. Then, in additon to deprecate taking a message (which
it
finally does now), it could take a value indicating the level of
deprecation.
e.g.
deprecated("use X instead", soft) void func();
or
deprecated("use X instead", hard) void func();
or
deprecated("use X instead", false) void func();
or
deprecated("use X instead", warning) void func();
or whatever we decided to use for the argument to indicate the level of
deprecation. But soft would mean that only a warning was given, whereas
hard
would mean that you'd get an error. Then you make either soft or hard the
default (hard would keep the current behavior) so that if it's not
provided,
that's what's used. You then have normal -> soft -> hard -> gone.
The problem is that when this was brought up before, Walter didn't want
to do
anything ilke this, because he thought that it complicated the feature
too
much. He liked deprecated being nice and simple. It probably doesn't
help that
he doesn't like the idea of anything being deprecated in Phobos, and
Phobos
was the main reason that such a feature change was being requested.
So, I don't know what the odds of being able to get something like this
are.
It's certainly what _I_ would like to see implemented though.
- Jonathan M Davis
Walter seems to like simplicity to the point that you have to work around
many of the 'simple' features.
It's not 'simple' if you need to hack around it to get the same effect
that it should have had in the first place.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
