Perhaps this is already implemented.
Since I'm not working with any "old code" I haven't even looked...
but nonetheless, I thought it was worth mentioning,
just in case.

As I understand it from the documentation, deprication is an all or nothing situation as it stands.
By this, I mean that one can swith the allowance of pedricated features on or off, but nowhere in-between.

I would like to propose that the concept of deprication levels be entertained.
A lower level would be less important to phase out,
and a higher level would be more important to phase out.

When a feature is initially depricated, it would be given a low deprication level such as 1, or perhaps 2 or 3 if it's something that everyone agrees needs to go.

As more features are depricated and older depricated features are phased out, occasionally,
all depricated features would increase in level by 1,
or perhaps just those that are known to be reletively well phased out.

This would allow asynchronous phasing out of depricated features,
while giving the software developer more control as well as some built-in guidance,
when it comes to choosing what needs phased out next.

For example, while the "-d" compiler switch allows all depricated features,
perhaps "-d3" could allow only those depricated features with a level of 3 or lower,
allowing newly depricated features to be put on a back burner, so to speak,
while "-d300" would only disallow features with a deprication level above 300,
allowing them to concentrate on phasing out the most extreme cases first,
before reducing down to something like "-d250" and starting on the next batch.

This would be of absolutely no use to me personally, at this time,
but in the discussion about adding ":=" as a value assignment operator,
when I mentioned the possibility of depricating the use of "=" in cases where it also
functions as a value assignment operator,
and it occurred to me that some day I may have code that needs something like that phased out.
That made me think about what it must be like to have several things needing to be phased out at once,
such as is likely the case for people using a lot of "C-like" code,
possibly adapted from older C code that they wanted to migrate into the D language.

I would guess that in such cases, the ability to allow "some" deprecated features would be handy.

One further note:

I would suggest avoiding having gaps in the deprecation levels.
For example, if there is only one feature with a deprecation level of exactly 97,
and that feature is phased out while there are still other features with higher deprecation levels,
then those with higher deprecation levels should have their level reduced accordingly,
to close the gap.

TZ

TechnoZeus wrote:

> 
> As I understand it from the documentation, deprication is an all or nothing situation as it stands.
> By this, I mean that one can swith the allowance of pedricated features on or off, but nowhere in-between.

In my mind, this just sounds too complicated to maintain for very little benefit. The set of deprecated features at any given time is generally small, and the compiler lets you know when you are using any deprecated features. So, telling it to allow specific features and disallow others makes no sense, when you can actively choose to use some and not use others. If you use any by mistake, the compiler tells you and you remove it.

"Mike Parker" <aldacron71@yahoo.com> wrote in message news:d47sgr$2m09$1@digitaldaemon.com...
> TechnoZeus wrote:
>
> >
> > As I understand it from the documentation, deprication is an all or nothing situation as it stands.
> > By this, I mean that one can swith the allowance of pedricated features on or off, but nowhere in-between.
>
> In my mind, this just sounds too complicated to maintain for very little benefit. The set of deprecated features at any given time is generally small, and the compiler lets you know when you are using any deprecated features. So, telling it to allow specific features and disallow others makes no sense, when you can actively choose to use some and not use others. If you use any by mistake, the compiler tells you and you remove it.

Okay... thanks.
Like I said... no experience with it.
Just thought I would pass along my thoughts on the subject anyway.

I thought D had a lot of old C features in it,
just from things I've heard people say,
and D code examples that I've seen so far.

Still seems to me that it would be better,
but if there are very few depricated features,
then you're probably right about it being more effort to maintain than it's worth.

TZ