Topic: API versioning: functions: overload; classes:


Author: "Mutz, Marc" <marc@kdab.com>
Date: Fri, 20 Apr 2018 09:40:20 +0200
Raw View
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

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2e63ae60069efc0fb81610ac2bd35491%40kdab.com.

.


Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 20 Apr 2018 10:44:44 +0300
Raw View
On 20 April 2018 at 10:40, Mutz, Marc <marc@kdab.com> wrote:
> 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?


See http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0945r0.html
We're going to review it in Rapperswil.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbmRs7E5wZ6xFKL7ehXc8pn3g9Hj-n8p%3DFcA1qU-QHeMw%40mail.gmail.com.

.


Author: "Mutz, Marc" <marc@kdab.com>
Date: Fri, 20 Apr 2018 10:15:17 +0200
Raw View
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

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/44377c4333ce2d9869efa4688b4aa107%40kdab.com.

.


Author: inkwizytoryankes@gmail.com
Date: Fri, 20 Apr 2018 05:25:26 -0700 (PDT)
Raw View
------=_Part_8494_1913778706.1524227126613
Content-Type: multipart/alternative;
 boundary="----=_Part_8495_159283060.1524227126613"

------=_Part_8495_159283060.1524227126613
Content-Type: text/plain; charset="UTF-8"



On Friday, April 20, 2018 at 9:44:46 AM UTC+2, Ville Voutilainen wrote:
>
> On 20 April 2018 at 10:40, Mutz, Marc <ma...@kdab.com <javascript:>>
> wrote:
> > 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?
>
>
> 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?


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2d519188-69b6-434d-9573-9875a7806f05%40isocpp.org.

------=_Part_8495_159283060.1524227126613
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, April 20, 2018 at 9:44:46 AM UTC+2, Vil=
le Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 20 Apr=
il 2018 at 10:40, Mutz, Marc &lt;<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"ziY2gy7bCwAJ" rel=3D"nofollow" onmousedown=3D"this=
..href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;">ma...@kdab.com</a>&gt; wrote:
<br>&gt; Hi,
<br>&gt;
<br>&gt; This is an idea about API migration. Assume you have a public API,=
 and you
<br>&gt; discover that you made a typo in an identifier (there are tons of =
other
<br>&gt; reasons to use the mechanisms that I&#39;ll show, but let&#39;s st=
ay with typo for
<br>&gt; the sake of argument). How to fix?
<br>&gt;
<br>&gt; For functions, we can add a new function and deprecated the old:
<br>&gt;
<br>&gt; =C2=A0 =C2=A0// v1
<br>&gt; =C2=A0 =C2=A0bar make_bra();
<br>&gt;
<br>&gt; =C2=A0 =C2=A0// v2
<br>&gt; =C2=A0 =C2=A0[[deprecated(&quot;use make_bar()&quot;)]] bar make_b=
ra() { return make_bar(); }
<br>&gt; =C2=A0 =C2=A0bar make_bar();
<br>&gt;
<br>&gt; For classes, we can use a typedef:
<br>&gt;
<br>&gt; =C2=A0 =C2=A0// v1
<br>&gt; =C2=A0 =C2=A0class bra { ~~~ };
<br>&gt;
<br>&gt; =C2=A0 =C2=A0// v2
<br>&gt; =C2=A0 =C2=A0class bar { ~~~ };
<br>&gt; =C2=A0 =C2=A0[[deprecated(&quot;use bar&quot;)]] using bra =3D bar=
;
<br>&gt;
<br>&gt; For variables, there&#39;s no way:
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 // v1
<br>&gt; =C2=A0 =C2=A0 static inline bar my_bra; // oops! no source migrati=
on path :(
<br>&gt;
<br>&gt; I have two questions:
<br>&gt;
<br>&gt; 1. Is there anything in the pipeline that would address migrating =
variable
<br>&gt; names?
<br>&gt; 2. Assuming there&#39;s nothing, what about overloading the using =
keyword for
<br>&gt; this?
<br>
<br>
<br>See <a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p094=
5r0.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#3=
9;http://www.google.com/url?q\x3dhttp%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2F=
WG21%2Fdocs%2Fpapers%2F2018%2Fp0945r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x=
3dAFQjCNGKet4Jeq6PeOJkiegK-AXVM3pwKA&#39;;return true;" onclick=3D"this.hre=
f=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fopen-std.org%2FJTC1%2F=
SC22%2FWG21%2Fdocs%2Fpapers%2F2018%2Fp0945r0.html\x26sa\x3dD\x26sntz\x3d1\x=
26usg\x3dAFQjCNGKet4Jeq6PeOJkiegK-AXVM3pwKA&#39;;return true;">http://open-=
std.org/JTC1/SC22/<wbr>WG21/docs/papers/2018/p0945r0.<wbr>html</a>
<br>We&#39;re going to review it in Rapperswil.
<br></blockquote><div><br>I have case:<br><div style=3D"background-color: r=
gb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; b=
order-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code c=
lass=3D"prettyprint"><div class=3D"subprettyprint"><div style=3D"color: #00=
0000;background-color: #fffffe;font-family: Consolas, "><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><div><span style=3D"color=
: #0000ff;"><span style=3D"color: #008;" class=3D"styled-by-prettify">class=
</span></span><span style=3D"color: #000000;"><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> F</span></span></div><div><span style=3D"colo=
r: #000000;"><span style=3D"color: #660;" class=3D"styled-by-prettify">{</s=
pan></span></div><div><span style=3D"color: #000000;"><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> =C2=A0 =C2=A0</span></span><span styl=
e=3D"color: #0000ff;"><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">using</span></span><span style=3D"color: #000000;"><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;"=
 class=3D"styled-by-prettify">ThisType</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> F</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">;</span></span></div><div><span style=3D"color: #000000;"><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0 =C2=A0</span><span s=
tyle=3D"color: #606;" class=3D"styled-by-prettify">ThisType</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">()</span></span></div><div=
><span style=3D"color: #000000;"><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> =C2=A0 =C2=A0</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">{</span></span></div><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><div><span style=3D"color: #000000;"><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">=C2=A0 =C2=A0</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">}</span></span></=
div><div><span style=3D"color: #000000;"><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> =C2=A0 =C2=A0</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">~</span><span style=3D"color: #606;" class=3D"s=
tyled-by-prettify">ThisType</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">()</span></span></div><div><span style=3D"color: #000000;"=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0 =C2=A0</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span></sp=
an></div><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></sp=
an><div><span style=3D"color: #000000;"><span style=3D"color: #000;" class=
=3D"styled-by-prettify">=C2=A0 =C2=A0</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">}</span></span></div><div><span style=3D"color: =
#000000;"><span style=3D"color: #660;" class=3D"styled-by-prettify">};</spa=
n></span></div></div></div></code></div>I will be allowed? Or it still spec=
ial case that can&#39;t be changed?<br>=C2=A0<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2d519188-69b6-434d-9573-9875a7806f05%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2d519188-69b6-434d-9573-9875a7806f05=
%40isocpp.org</a>.<br />

------=_Part_8495_159283060.1524227126613--

------=_Part_8494_1913778706.1524227126613--

.


Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 20 Apr 2018 15:59:49 +0300
Raw View
On 20 April 2018 at 15:25,  <inkwizytoryankes@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"

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUae1PpsbbQMhS%2BsQ24CjLtE%2BQUhjQtJk_wKCGJtHfZkEg%40mail.gmail.com.

.