How about allowing the deprecated keyword to be applied to a statement, which causes it to not require -d compiler switch nor complain if it uses a deprecated feature?

Scenario: say I want to deprecate the function onEvent() that the library calls when an event occurs. To fully support the deprecated function the library still has to call it. So now it means the library always has to have the -d switch even if the library user doesn't use onEvent().

Hi,

>How about allowing the deprecated keyword to be applied to a statement, which causes it to not require -d compiler switch nor complain if it uses a deprecated feature?

This sounds like a pretty good idea. Specially given the changing nature of D.

Cheers,
--AJG.

Vathix wrote:
> How about allowing the deprecated keyword to be applied to a statement,  which causes it to not require -d compiler switch nor complain if it uses  a deprecated feature?
> 
> Scenario: say I want to deprecate the function onEvent() that the library  calls when an event occurs. To fully support the deprecated function the  library still has to call it. So now it means the library always has to  have the -d switch even if the library user doesn't use onEvent().

The problem is that deprecating a function doesn't stop someone from overriding it.

And even if it did, allowing deprecated to be applied to statements in this way can easily be abused.  Someone using your library will decide that the replacement API is "too much trouble" to learn, and just wrap the call in a deprecated statement, and then it would come as a nasty surprise when the deprecated feature is finally removed.

OTOH if we didn't have this, then anyone finding that learning the replacement API is "too much trouble" will have to use the -d switch, which would encourage mere postponement of taking this trouble rather than forgetting alogether.

Perhaps better would be:

(a) provide some "deprecatedly public" notation - the function is deprecated from the API, but kept for internal use

(b) provide a way to deprecate overriding of a function

(c) if we are going to have deprecated statements, make them conditional compilation blocks switched on by the -d switch.

Stewart.

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

> (a) provide some "deprecatedly public" notation - the function is deprecated from the API, but kept for internal use

That's kind of possible to do right now. Rename the function, add a protection attribute to it, and put in a deprecated function that calls the renamed one. Internally use the renamed one.

>
> (b) provide a way to deprecate overriding of a function

I'd say it should work like other deprecated features: require -d to allow it. If the compiler doesn't do this now, it probably should.

>
> (c) if we are going to have deprecated statements, make them conditional compilation blocks switched on by the -d switch.

I was thinking of that too.. it seems to be a good solution. I could compile a lib with -d to support a deprecated feature that calls a deprecated event function, and users of the lib wouldn't need -d unless they used the deprecated event function.

Vathix wrote:
>> (a) provide some "deprecatedly public" notation - the function is  deprecated from the API, but kept for internal use
> 
> That's kind of possible to do right now. Rename the function, add a  protection attribute to it, and put in a deprecated function that calls  the renamed one. Internally use the renamed one.

True.  So the deprecatedly public notation would syntactic sugar for this idea.

Maybe something like "private deprecated public" and similarly for protected and package.  Of course this would require a change to how attributes are parsed....

>> (b) provide a way to deprecate overriding of a function
> 
> I'd say it should work like other deprecated features: require -d to allow  it. If the compiler doesn't do this now, it probably should.
<snip>

Unless want to deprecate a function from a base class while keeping it as part of the API of one or two derived classes.

The idea suggested above would *partly* achieve this, if we enforce that (except for protected deprecated public) such a function may not be overridden unless compiling with -d or the override is itself deprecated.

Stewart.

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