Topic: explicit underlying type conversion used in integral


Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 26 Apr 2017 21:58:51 +0200
Raw View
This is a multi-part message in MIME format.
--------------C60521CCEAD9E2E0BE88ACC1
Content-Type: text/plain; charset=UTF-8; format=flowed

Hi,


we have that instances of types with an explicit conversion to bool can
be used in if statements, with logical operators &&, ||, and ! and with
the ?: operator.


When we have strong type wrapping integers, we need to provide access to
the underlying type and very often it is provided using an explicit
conversion.

However when we use a strong type in a switch we must use the access
function or cast it to the integer, as in

     switch (st.value()) {

     ...

or

     switch (int(st)) {

     ...

or

     switch (underlying(st)) {

     ...

where underlying is a function that do the cast to the underlying type.

I was wondering if we can not extend the switch statement. It could
accept any type convertible to an integral type (a type that can be in a
switch condition). If more than one of these conversion is possible then
the program will not be well formed.

switch (st) {

....


This could be useful where you have some generic code expecting an
Integral type.

template <class Integral>
void f(Integral i)
{

     switch (i) {

     ...
}

This code will not compile if we pass it a strong integer type wrapping
an int. We would need to define a underlying function that works for
enums, int and strong integer types e.g.

template <class Integral>
void f(Integral i)
{

     switch (underlying(i)) {

     ...
}

I'm expecting that we will have more and more strong types, as e.g. day,
month, weekday, and other existing types as duration. We are now forced
to call to a function in this context which seams redundant.

What do you think about calling to the explicit conversion in this context?
Is it worth changing the C++ standard language for this specific case?

If not do we want to have the possibility to specialize the
underlying_type trait and add the underlying function?

Would the future pattern matching help on this concern? and how?

Vicente


--
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/9af62eeb-49d5-9a96-d48d-e7ba761b9e75%40wanadoo.fr.

--------------C60521CCEAD9E2E0BE88ACC1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>

    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <p><font size=3D"+1">Hi,</font></p>
    <p><font size=3D"+1"><br>
      </font></p>
    <p><font size=3D"+1">we have that instances of types with an explicit
        conversion to bool can b</font>e used in if statements, with
      logical operators &amp;&amp;, ||, and ! and with the ?: operator.</p>
    <p><br>
    </p>
    <p>When we have strong type wrapping integers, we need to provide
      access to the underlying type and very often it is provided using
      an explicit conversion.</p>
    <p>However when we use a strong type in a switch we must use the
      access function or cast it to the integer, as in</p>
    <p>=C2=A0=C2=A0=C2=A0 switch (st.value()) {<br>
    </p>
    =C2=A0=C2=A0=C2=A0 ...<br>
    <p>or</p>
    <p>=C2=A0=C2=A0=C2=A0 switch (int(st)) {<br>
    </p>
    =C2=A0=C2=A0=C2=A0 ...<br>
    <p>or</p>
    <p>=C2=A0=C2=A0=C2=A0 switch (underlying(st)) { <br>
    </p>
    =C2=A0=C2=A0=C2=A0 ...<br>
    <p>where underlying is a function that do the cast to the underlying
      type.<br>
    </p>
    <p>I was wondering if we can not extend the switch statement. It
      could accept any type convertible to an integral type (a type that
      can be in a switch condition). If more than one of these
      conversion is possible then the program will not be well formed.</p>
    <p>switch (st) {</p>
    ...<br>
    <br>
    <br>
    This could be useful where you have some generic code expecting an
    Integral type. <br>
    <br>
    template &lt;class Integral&gt;<br>
    void f(Integral i)<br>
    {<br>
    <p>=C2=A0=C2=A0=C2=A0 switch (i) {<br>
    </p>
    =C2=A0=C2=A0=C2=A0 ...<br>
    }<br>
    <br>
    This code will not compile if we pass it a strong integer type
    wrapping an int. We would need to define a underlying function that
    works for enums, int and strong integer types e.g.<br>
    <br>
    template &lt;class Integral&gt;<br>
    void f(Integral i)<br>
    {<br>
    <p>=C2=A0=C2=A0=C2=A0 switch (underlying(i)) { <br>
    </p>
    =C2=A0=C2=A0=C2=A0 ...<br>
    }<br>
    <br>
    I'm expecting that we will have more and more strong types, as e.g.
    day, month, weekday, and other existing types as duration. We are
    now forced to call to a function in this context which seams
    redundant.<br>
    <br>
    What do you think about calling to the explicit conversion in this
    context?<br>
    Is it worth changing the C++ standard language for this specific
    case?<br>
    <br>
    If not do we want to have the possibility to specialize the
    underlying_type trait and add the underlying function?<br>
    <p>Would the future pattern matching help on this concern? and how?<br>
    </p>
    <p>Vicente<br>
    </p>
    <p><br>
    </p>
  </body>
</html>

<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/9af62eeb-49d5-9a96-d48d-e7ba761b9e75%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9af62eeb-49d5-9a96-d48d-e7ba761b9e75=
%40wanadoo.fr</a>.<br />

--------------C60521CCEAD9E2E0BE88ACC1--

.