Date: Tue, 12 Nov 2024 13:40:00 +0100
Hello everyone,
I'd like to know if there's interest in introducing a way to selectively
ignore the effects of the [[deprecated]] attribute. Such a thing could
be useful in at least two scenarios:
1. You have an old API that is being replaced by a new API, but the new
API is written in terms of the old one (either temporarily or
because you plan to make the old API private in a future release,
without completely removing it)
2. You have both a “safe” and an “unsafe” API and you want to encourage
the naïve user to use the safe one, while giving the possibility to
an experienced user to choose the unsafe API by declaring such
intent explicitly
This is an example of case b, with *placeholder* syntax:
// this is the old API, that still works but is deemed unsafe
[[deprecated_ignorable("unsafe", "This overload is unsafe, please use
strlen_s")]]
size_t strlen( const char* str );
// this is the new "safe" API
size_t strnlen_s( const char* str, size_t strsz );
void f(const char* str, size_t str)
{
// this use of strlen is flagged as deprecated by the compiler,
possibly raising a warning
auto len1 = strlen(str);
// this line should not emit diagnostics
auto len2 = strlen_s(str, MAX_SIZE);
// we know what we're doing and really want to suppress the warning
[[ignore_deprecation("unsafe")]]
{
// in this scope all ignorable deprecations with the tag
"unsafe" are ignored
auto len3 = strlen(str); // no diagnostic here
}
}
Details of the precise syntax are open to discussion. A few, certainly
not all, questions to address are:
1) Are attributes the right tool?
2) Should we use a different attribute (as "deprecated_ignorable" above)
or can/should we overload the existing [[deprecated]]?
3) The example above uses a string literal to tag the deprecation, so
that it can be referenced in [[ignore_deprecation]]. Alternatives and
variations could be considered, including, but not limited to,
identifiers instead of strings, multiple tags, etc.
4) Should [[ignore_deprecation]] be applied only to compount statements
(as in the example above) or other statements/entities? Are there scopes
that could use the attribute that we would be missing (for example
function default arguments)?
In case there's interest, I am going to write a more detailed paper with
a formal proposal.
Thanks for your feedback,
ab
I'd like to know if there's interest in introducing a way to selectively
ignore the effects of the [[deprecated]] attribute. Such a thing could
be useful in at least two scenarios:
1. You have an old API that is being replaced by a new API, but the new
API is written in terms of the old one (either temporarily or
because you plan to make the old API private in a future release,
without completely removing it)
2. You have both a “safe” and an “unsafe” API and you want to encourage
the naïve user to use the safe one, while giving the possibility to
an experienced user to choose the unsafe API by declaring such
intent explicitly
This is an example of case b, with *placeholder* syntax:
// this is the old API, that still works but is deemed unsafe
[[deprecated_ignorable("unsafe", "This overload is unsafe, please use
strlen_s")]]
size_t strlen( const char* str );
// this is the new "safe" API
size_t strnlen_s( const char* str, size_t strsz );
void f(const char* str, size_t str)
{
// this use of strlen is flagged as deprecated by the compiler,
possibly raising a warning
auto len1 = strlen(str);
// this line should not emit diagnostics
auto len2 = strlen_s(str, MAX_SIZE);
// we know what we're doing and really want to suppress the warning
[[ignore_deprecation("unsafe")]]
{
// in this scope all ignorable deprecations with the tag
"unsafe" are ignored
auto len3 = strlen(str); // no diagnostic here
}
}
Details of the precise syntax are open to discussion. A few, certainly
not all, questions to address are:
1) Are attributes the right tool?
2) Should we use a different attribute (as "deprecated_ignorable" above)
or can/should we overload the existing [[deprecated]]?
3) The example above uses a string literal to tag the deprecation, so
that it can be referenced in [[ignore_deprecation]]. Alternatives and
variations could be considered, including, but not limited to,
identifiers instead of strings, multiple tags, etc.
4) Should [[ignore_deprecation]] be applied only to compount statements
(as in the example above) or other statements/entities? Are there scopes
that could use the attribute that we would be missing (for example
function default arguments)?
In case there's interest, I am going to write a more detailed paper with
a formal proposal.
Thanks for your feedback,
ab
Received on 2024-11-12 12:40:09