Using DMD 0.81, Windows 98SE.

Take this code sample:

----------
deprecated class Qwert {
        int yuiop;

        this(int y) { yuiop = y; }

        int twiceYuiop() {
                return 2 * yuiop;
        }

        invariant {
                assert (yuiop < 100);
        }
}
----------

The constructor, method and invariant each give me the error "variable yuiop is deprecated".  (Obviously only one at a time with the current DMD limitation, but after commenting out the ones above.)

There are a few issues here:

1. yuiop isn't deprecated.  The whole class is deprecated.

2. Who can dream of a class going out of its way not to touch itself at all?  IINM, this bug makes the token sequence 'deprecated class' useless.

3. Furthermore, one deprecated entity should be perfectly allowed to make use of another.  Here's another example that fails:

----------
deprecated int tri(int x) {
        return x*(x+1)/2;
}

deprecated int pent(int x) {
        return x*x + tri(x) - x;
}
----------

After deprecating something, one shouldn't have to maintain it any more.  It shouldn't be necessary to rewrite pent, which is deprecated, so that it doesn't use tri, which is also deprecated (maybe long after pent was).

It makes no difference if I enclose both functions in deprecated { ... } rather than deprecating them separately.

4. If compiling without the deprecation switch, is it really necessary to semantically analyse deprecated stuff at all?  (Except in the case when a deprecated method is called by an undeprecated method of the same class/struct/union, which oddly seems to work, and indeed has its advantages.)

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:

[...]
> 3. Furthermore, one deprecated entity should be perfectly allowed to make use of another.
[...]

You are right. The current spec, that "any" code, that referes to a deprecated feature is considered an error, is erroneous itself.

So long!

Stewart Gordon wrote:

<snip>
> (Except in the case when a deprecated method is called by an undeprecated method of the same class/struct/union, which oddly  seems
> to work, and indeed has its advantages.)

Oops, just found that this was a misdiagnosis.  There are actually two further problems:

5. Deprecation is working only at the global level.  Members are never deprecated at all as far as DMD is concerned.

6. If a function name is overloaded, the compiler doesn't distinguish whether each version is deprecated.  It just takes them all to be as deprecated as the first version given in the code.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the
unfortunate victim of intensive mail-bombing at the moment.  Please keep
replies on the 'group where everyone may benefit.

Stewart Gordon wrote:

> Stewart Gordon wrote:
> 
> <snip>
> 
>> (Except in the case when a deprecated method is called by an undeprecated method of the same class/struct/union, which oddly seems
>> to work, and indeed has its advantages.)
> 
> Oops, just found that this was a misdiagnosis.  There are actually two further problems:
> 
> 5. Deprecation is working only at the global level.  Members are never deprecated at all as far as DMD is concerned.

I've since discovered that deprecation is working within a class, but not into it.  I.e. while it'll let me call a deprecated method from outside the class, it won't let me call a deprecated method from within the class.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on on the 'group where everyone may benefit.