API versioning: functions: overload; classes: typedef; variables: <meep>

64 views
Skip to first unread message

Mutz, Marc

unread,
Apr 20, 2018, 3:40:33 AM4/20/18
to ISO C++ Standard - Future Proposals
Hi,

This is an idea about API migration. Assume you have a public API, and
you discover that you made a typo in an identifier (there are tons of
other reasons to use the mechanisms that I'll show, but let's stay with
typo for the sake of argument). How to fix?

For functions, we can add a new function and deprecated the old:

// v1
bar make_bra();

// v2
[[deprecated("use make_bar()")]] bar make_bra() { return make_bar();
}
bar make_bar();

For classes, we can use a typedef:

// v1
class bra { ~~~ };

// v2
class bar { ~~~ };
[[deprecated("use bar")]] using bra = bar;

For variables, there's no way:

// v1
static inline bar my_bra; // oops! no source migration path :(

I have two questions:

1. Is there anything in the pipeline that would address migrating
variable names?
2. Assuming there's nothing, what about overloading the using keyword
for this?

// v2
static inline bar my_bar;
[[deprecated("use my_bar")]] using my_bra = my_bar; // variable
'using'

Don't get hooked on the use of a global here, my main use-case would be
replacing pairs with more targeted structs:

template <typename T>
struct minmax_result {
T min, max;
[[deprecated("use 'minmax_result'")]]
operator std::pair<T, T>() const { return {min, max}; }
[[deprecated("use 'min'")]]
using first = min;
[[deprecated("use 'max')]]
using second = max;
};

template <typename T>
minmax_result<const &T> minmax(const T& lhs, const T& rhs) { ~~~ }

auto r = std::minmax(v, u);
use(r.min);
use(r.second); // WARNING: 'minmax_result<T>::second' is deprecated:
use 'max'

Thanks,
Marc

Ville Voutilainen

unread,
Apr 20, 2018, 3:44:46 AM4/20/18
to ISO C++ Standard - Future Proposals
See http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0945r0.html
We're going to review it in Rapperswil.

Mutz, Marc

unread,
Apr 20, 2018, 4:15:21 AM4/20/18
to std-pr...@isocpp.org
On 2018-04-20 09:44, Ville Voutilainen wrote:
[...]
> See http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0945r0.html
> We're going to review it in Rapperswil.

Excellent.

I guess some ideas are just too obvious...

Thanks,
Marc

inkwizyt...@gmail.com

unread,
Apr 20, 2018, 8:25:26 AM4/20/18
to ISO C++ Standard - Future Proposals

I have case:

class F
{
   using ThisType = F;
   ThisType()
   {

   }
   ~ThisType()
   {

   }
};
I will be allowed? Or it still special case that can't be changed?
 

Ville Voutilainen

unread,
Apr 20, 2018, 8:59:52 AM4/20/18
to ISO C++ Standard - Future Proposals
On 20 April 2018 at 15:25, <inkwizyt...@gmail.com> wrote:
>> See http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0945r0.html
>> We're going to review it in Rapperswil.
>
>
> I have case:
>
> class F
> {
> using ThisType = F;
> ThisType()
> {
>
> }
> ~ThisType()
> {
>
> }
> };
> I will be allowed? Or it still special case that can't be changed?


Yes, the proposal allows it. Quoth:

"As with the existing alias-declaration, this new form is permitted at
namespace scope, block scope, and within class definitions. An
alias-declaration that names a non-static data member or non-static
member function may only appear as a member-declaration of the same
class or one of its derived classes. An alias-declaration that names a
namespace may not appear at class scope. No other restrictions are
proposed on the kind of entity that may be named by the id-expression.

For consistency, we propose removing those restrictions from
using-declarations that are not present for this form of
alias-declaration:

A class-scope using-declaration may name a non-class member"
Reply all
Reply to author
Forward
0 new messages