------=_Part_1582_706627607.1449998264168
Content-Type: multipart/alternative;
 boundary="----=_Part_1583_17488911.1449998264169"

------=_Part_1583_17488911.1449998264169
Content-Type: text/plain; charset=UTF-8

On Sunday, December 13, 2015 at 1:54:07 AM UTC-5, Vicente J. Botet Escriba
wrote:
>
> Hi,
>
> If we remove the field names in POD structs and unions
>
> union S {
>      struct left {int a;}  c1;
>      struct right{string a;}  c2;
> };
>
> as in
>
> union S {
>      struct left {int;}  ;
>      struct right{string;}  ;
> };
>
> The result is syntactically quite close to sum types in functional
> languages like Haskhell
>
> data S = Left int | Right string
>
> However we need to add something else to mean that we want a variant (a
> discriminated union)
>
> P0095 proposes to extend unions so that the field name is used as
> constructor and case selector.
>
> enum union command {
>    std::size_t set_score; // Set the score to the specified value
>    std::monotype fire_missile; // Fire a missile
>    unsigned fire_laser; // Fire a laser with the specified intensity
>    double rotate; // Rotate the ship by the specified degrees.
> };
>
> //construction
> command cmd = command::set_score( 10 );
>
> // modifier
> cmd = command::fire_missile( );
>
> // access
> switch( cmd ) {
>    case set_score value:
>      score = value;
>    default:
> }
>
> I believe that the structs themselves are a better type constructors
> than the field names. My proposal is to use struct as type constructor
> for each variant case. This ensures that we would not have repeated types.
>
> enum union command
> {
>    struct set_score {std::size_t };
>    struct fire_missile { } ;
>    struct fire_laser { unsigned } ;
>    struct rotate { double } ;
> };
>
> or
>
> union command
> {
>    case struct set_score {std::size_t };
>    case struct fire_missile {} ;
>    case struct fire_laser{unsigned} ;
>    case struct rotate{double} ;
> };
>
> There will be an implicit conversion from set_score, fire_missile,
> fire_laser and rotate to command
>
> command cmd = command::set_score { 10 }; // Note the use of {}
>
> cmd = command::fire_missile{};
>
>
> I suggest to take the syntax proposed by BS in order to inspect the
> contents
>
> inspect( cmd )
> {
>    when set_score{value}:  // the syntax is close to the p0144
> structured bindings
>      score = value;
>    default:
> }
>
> Using struct as cases of a variant give us sum of product types directly
> as the struct can contain several types. Next follow the usual Tree
> example.
>
> template <class T>
> union Tree {
>      case struct Empty{};
>      case struct Leaf{T;};
>      case struct Node{unique_ptr<Tree>; unique_ptr<Tree>;};
> };
>
> Tree t = Node{ unique_ptr { Leaf { 1 } }, unique_ptr { Leaf { 2 } } };
> // This will be valid after adoption of p0091r0
>

That doesn't work. Not even with P0091. The broken part being the
declaration of `Node`.

`unique_ptr<Tree>` is not a typename; it isn't even a template. P0091 can't
make that one work, because P0091 is about determining the template
arguments of variables based on how they're initialized. And those
variables aren't being initialized yet. Therefore, there is no way for the
compiler to know what those types actually are. And therefore, the compiler
cannot give them a size and so forth.

`struct Node{unique_ptr<Tree>;}; is no more valid than `struct
Node{auto;};`.

Also, I don't see how you could be creating a `unique_ptr` without an
actual `new` expression. Not unless you're expecting `unique_ptr` to be
extended with the facilities of `make_unique`.

The previous statement will need the qualification of Tree::
>
> Tree t = Tree::Node{ unique_ptr { Tree::Leaf { 1 } }, unique_ptr {
> Tree::Leaf { 2 } } };
>
>
> Using struct instead of a field name has the advantage (or the
> liability) to be able to define the struct outside the variant.
>
> We could define
>
> template <class T>
> struct Left { T;};
>
> template <class T>
> struct Right { T;};
>
> template <class T, class U>
> union Either {
>      case Left<T>;
>      case Right<U>;
> }
>
> Either<int, string> = Left { 10 }; // This will be valid after adoption
> of p0091r0.
>
> I said or the liability because when the structure is defined outside
> the variant, the alternative, Left or Right in this case, can be also an
> alternative to another variant and be subject to ambiguity.
>

>
> As the compiler knows the alternatives, it can generate  whatever is
> needed for reflection purposes, as variant_alternatives<S> : tuple of
> the alternatives.
>
> Comments welcome.
>

That looks hideously ugly, syntactically speaking. Just look at all of the
syntactic noise in the declaration. You have to prefix the `union`. You
declare a bunch of `struct`s with anonymous members, for some unknown
reason.

And then there's your "inspect" syntax, which again is needlessly
cumbersome (as well as creating keywords for no reason). P0095 made things
simple: you access named fields just like a union or struct currently, but
you can also switch on the various possibilities. The switch statement
looked and acted as much like a regular switch as reasonable. Your way
invents entirely new syntax, while making simple access more cumbersome.

The overall result is far more cumbersome than the P0095 method. Who cares
if you have "sum of product types" if the result is ugly, hard-to-use code?

I don't understand what genuine problem with variants as a library type
that this actually solves. Granted, I don't really buy the motivational
argument put forth by P0095 either. Variants are important, yes. But unless
implementing them in the language can actually resolve issues raised by
library implementations, they're really not important enough to need to be
a first-class language feature. And P0095 basically punted on the most
important implementation question (exceptions).

--

---
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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Sunday, December 13, 2015 at 1:54:07 AM UTC-5, Vicente J. Botet Escriba =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi,
<br>
<br>If we remove the field names in POD structs and unions
<br>
<br>union S {
<br>=C2=A0 =C2=A0 =C2=A0struct left {int a;} =C2=A0c1;
<br>=C2=A0 =C2=A0 =C2=A0struct right{string a;} =C2=A0c2;
<br>};
<br>
<br>as in
<br>
<br>union S {
<br>=C2=A0 =C2=A0 =C2=A0struct left {int;} =C2=A0;
<br>=C2=A0 =C2=A0 =C2=A0struct right{string;} =C2=A0;
<br>};
<br>
<br>The result is syntactically quite close to sum types in functional=20
<br>languages like Haskhell
<br>
<br>data S =3D Left int | Right string
<br>
<br>However we need to add something else to mean that we want a variant (a=
=20
<br>discriminated union)
<br>
<br>P0095 proposes to extend unions so that the field name is used as=20
<br>constructor and case selector.
<br>
<br>enum union command {
<br>=C2=A0 =C2=A0std::size_t set_score; // Set the score to the specified v=
alue
<br>=C2=A0 =C2=A0std::monotype fire_missile; // Fire a missile
<br>=C2=A0 =C2=A0unsigned fire_laser; // Fire a laser with the specified in=
tensity
<br>=C2=A0 =C2=A0double rotate; // Rotate the ship by the specified degrees=
..
<br>};
<br>
<br>//construction
<br>command cmd =3D command::set_score( 10 );
<br>
<br>// modifier
<br>cmd =3D command::fire_missile( );
<br>
<br>// access
<br>switch( cmd ) {
<br>=C2=A0 =C2=A0case set_score value:
<br>=C2=A0 =C2=A0 =C2=A0score =3D value;
<br>=C2=A0 =C2=A0default:
<br>}
<br>
<br>I believe that the structs themselves are a better type constructors=20
<br>than the field names. My proposal is to use struct as type constructor=
=20
<br>for each variant case. This ensures that we would not have repeated typ=
es.
<br>
<br>enum union command
<br>{
<br>=C2=A0 =C2=A0struct set_score {std::size_t };
<br>=C2=A0 =C2=A0struct fire_missile { } ;
<br>=C2=A0 =C2=A0struct fire_laser { unsigned } ;
<br>=C2=A0 =C2=A0struct rotate { double } ;
<br>};
<br>
<br>or
<br>
<br>union command
<br>{
<br>=C2=A0 =C2=A0case struct set_score {std::size_t };
<br>=C2=A0 =C2=A0case struct fire_missile {} ;
<br>=C2=A0 =C2=A0case struct fire_laser{unsigned} ;
<br>=C2=A0 =C2=A0case struct rotate{double} ;
<br>};
<br>
<br>There will be an implicit conversion from set_score, fire_missile,=20
<br>fire_laser and rotate to command
<br>
<br>command cmd =3D command::set_score { 10 }; // Note the use of {}
<br>
<br>cmd =3D command::fire_missile{};
<br>
<br>
<br>I suggest to take the syntax proposed by BS in order to inspect the con=
tents
<br>
<br>inspect( cmd )
<br>{
<br>=C2=A0 =C2=A0when set_score{value}: =C2=A0// the syntax is close to the=
 p0144=20
<br>structured bindings
<br>=C2=A0 =C2=A0 =C2=A0score =3D value;
<br>=C2=A0 =C2=A0default:
<br>}
<br>
<br>Using struct as cases of a variant give us sum of product types directl=
y=20
<br>as the struct can contain several types. Next follow the usual Tree exa=
mple.
<br>
<br>template &lt;class T&gt;
<br>union Tree {
<br>=C2=A0 =C2=A0 =C2=A0case struct Empty{};
<br>=C2=A0 =C2=A0 =C2=A0case struct Leaf{T;};
<br>=C2=A0 =C2=A0 =C2=A0case struct Node{unique_ptr&lt;Tree&gt;; unique_ptr=
&lt;Tree&gt;;};
<br>};
<br>
<br>Tree t =3D Node{ unique_ptr { Leaf { 1 } }, unique_ptr { Leaf { 2 } } }=
;=20
<br>// This will be valid after adoption of p0091r0
<br></blockquote><div><br>That doesn&#39;t work. Not even with P0091. The b=
roken part being the declaration of `Node`.<br><br>`unique_ptr&lt;Tree&gt;`=
 is not a typename; it isn&#39;t even a template. P0091 can&#39;t make that=
 one work, because P0091 is about determining the template arguments of var=
iables based on how they&#39;re initialized. And those variables aren&#39;t=
 being initialized yet. Therefore, there is no way for the compiler to know=
 what those types actually are. And therefore, the compiler cannot give the=
m a size and so forth.<br><br>`struct Node{unique_ptr&lt;Tree&gt;;}; is no =
more valid than `struct Node{auto;};`.<br><br>Also, I don&#39;t see how you=
 could be creating a `unique_ptr` without an actual `new` expression. Not u=
nless you&#39;re expecting `unique_ptr` to be extended with the facilities =
of `make_unique`.<br><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>
The previous statement will need the qualification of Tree::
<br>
<br>Tree t =3D Tree::Node{ unique_ptr { Tree::Leaf { 1 } }, unique_ptr {=20
<br>Tree::Leaf { 2 } } };
<br>
<br>
<br>Using struct instead of a field name has the advantage (or the=20
<br>liability) to be able to define the struct outside the variant.
<br>
<br>We could define
<br>
<br>template &lt;class T&gt;
<br>struct Left { T;};
<br>
<br>template &lt;class T&gt;
<br>struct Right { T;};
<br>
<br>template &lt;class T, class U&gt;
<br>union Either {
<br>=C2=A0 =C2=A0 =C2=A0case Left&lt;T&gt;;
<br>=C2=A0 =C2=A0 =C2=A0case Right&lt;U&gt;;
<br>}
<br>
<br>Either&lt;int, string&gt; =3D Left { 10 }; // This will be valid after =
adoption=20
<br>of p0091r0.
<br>
<br>I said or the liability because when the structure is defined outside=
=20
<br>the variant, the alternative, Left or Right in this case, can be also a=
n=20
<br>alternative to another variant and be subject to ambiguity.=C2=A0<br></=
blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>
<br>As the compiler knows the alternatives, it can generate =C2=A0whatever =
is=20
<br>needed for reflection purposes, as variant_alternatives&lt;S&gt; : tupl=
e of=20
<br>the alternatives.
<br>
<br>Comments welcome.
<br></blockquote><div><br>That looks hideously ugly, syntactically speaking=
.. Just look at all of the syntactic noise in the declaration. You have to p=
refix the `union`. You declare a bunch of `struct`s with anonymous members,=
 for some unknown reason.<br><br>And then there&#39;s your &quot;inspect&qu=
ot; syntax, which again is needlessly cumbersome (as well as creating keywo=
rds for no reason). P0095 made things simple: you access named fields just =
like a union or struct currently, but you can also switch on the various po=
ssibilities. The switch statement looked and acted as much like a regular s=
witch as reasonable. Your way invents entirely new syntax, while making sim=
ple access more cumbersome.<br><br>The overall result is far more cumbersom=
e than the P0095 method. Who cares if you have &quot;sum of product types&q=
uot; if the result is ugly, hard-to-use code?<br><br>I don&#39;t understand=
 what genuine problem with variants as a library type that this actually so=
lves. Granted, I don&#39;t really buy the motivational argument put forth b=
y P0095 either. Variants are important, yes. But unless implementing them i=
n the language can actually resolve issues raised by library implementation=
s, they&#39;re really not important enough to need to be a first-class lang=
uage feature. And P0095 basically punted on the most important implementati=
on question (exceptions).<br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_1583_17488911.1449998264169--
------=_Part_1582_706627607.1449998264168--

.

This is a multi-part message in MIME format.
--------------010302030006000507070507
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 13/12/2015 10:17, Nicol Bolas a =C3=A9crit :
> On Sunday, December 13, 2015 at 1:54:07 AM UTC-5, Vicente J. Botet=20
> Escriba wrote:
>
>     Hi,
>
>     If we remove the field names in POD structs and unions
>
>     union S {
>          struct left {int a;}  c1;
>          struct right{string a;}  c2;
>     };
>
>     as in
>
>     union S {
>          struct left {int;}  ;
>          struct right{string;}  ;
>     };
>
>     The result is syntactically quite close to sum types in functional
>     languages like Haskhell
>
>     data S =3D Left int | Right string
>
>     However we need to add something else to mean that we want a
>     variant (a
>     discriminated union)
>
>     P0095 proposes to extend unions so that the field name is used as
>     constructor and case selector.
>
>     enum union command {
>        std::size_t set_score; // Set the score to the specified value
>        std::monotype fire_missile; // Fire a missile
>        unsigned fire_laser; // Fire a laser with the specified intensity
>        double rotate; // Rotate the ship by the specified degrees.
>     };
>
>     //construction
>     command cmd =3D command::set_score( 10 );
>
>     // modifier
>     cmd =3D command::fire_missile( );
>
>     // access
>     switch( cmd ) {
>        case set_score value:
>          score =3D value;
>        default:
>     }
>
>     I believe that the structs themselves are a better type constructors
>     than the field names. My proposal is to use struct as type
>     constructor
>     for each variant case. This ensures that we would not have
>     repeated types.
>
>     enum union command
>     {
>        struct set_score {std::size_t };
>        struct fire_missile { } ;
>        struct fire_laser { unsigned } ;
>        struct rotate { double } ;
>     };
>
>     or
>
>     union command
>     {
>        case struct set_score {std::size_t };
>        case struct fire_missile {} ;
>        case struct fire_laser{unsigned} ;
>        case struct rotate{double} ;
>     };
>
>     There will be an implicit conversion from set_score, fire_missile,
>     fire_laser and rotate to command
>
>     command cmd =3D command::set_score { 10 }; // Note the use of {}
>
>     cmd =3D command::fire_missile{};
>
>
>     I suggest to take the syntax proposed by BS in order to inspect
>     the contents
>
>     inspect( cmd )
>     {
>        when set_score{value}:  // the syntax is close to the p0144
>     structured bindings
>          score =3D value;
>        default:
>     }
>
>     Using struct as cases of a variant give us sum of product types
>     directly
>     as the struct can contain several types. Next follow the usual
>     Tree example.
>
>     template <class T>
>     union Tree {
>          case struct Empty{};
>          case struct Leaf{T;};
>          case struct Node{unique_ptr<Tree>; unique_ptr<Tree>;};
>     };
>
>     Tree t =3D Node{ unique_ptr { Leaf { 1 } }, unique_ptr { Leaf { 2 }
>     } };
>     // This will be valid after adoption of p0091r0
>
>
> That doesn't work. Not even with P0091. The broken part being the=20
> declaration of `Node`.
>
> `unique_ptr<Tree>` is not a typename; it isn't even a template. P0091=20
> can't make that one work, because P0091 is about determining the=20
> template arguments of variables based on how they're initialized. And=20
> those variables aren't being initialized yet. Therefore, there is no=20
> way for the compiler to know what those types actually are. And=20
> therefore, the compiler cannot give them a size and so forth.
>
> `struct Node{unique_ptr<Tree>;}; is no more valid than `struct=20
> Node{auto;};`.
>
> Also, I don't see how you could be creating a `unique_ptr` without an=20
> actual `new` expression. Not unless you're expecting `unique_ptr` to=20
> be extended with the facilities of `make_unique`.
>
>     The previous statement will need the qualification of Tree::
>
>     Tree t =3D Tree::Node{ unique_ptr { Tree::Leaf { 1 } }, unique_ptr {
>     Tree::Leaf { 2 } } };
>
>
>     Using struct instead of a field name has the advantage (or the
>     liability) to be able to define the struct outside the variant.
>
>     We could define
>
>     template <class T>
>     struct Left { T;};
>
>     template <class T>
>     struct Right { T;};
>
>     template <class T, class U>
>     union Either {
>          case Left<T>;
>          case Right<U>;
>     }
>
>     Either<int, string> =3D Left { 10 }; // This will be valid after
>     adoption
>     of p0091r0.
>
>     I said or the liability because when the structure is defined outside
>     the variant, the alternative, Left or Right in this case, can be
>     also an
>     alternative to another variant and be subject to ambiguity.
>
>
>
>     As the compiler knows the alternatives, it can generate  whatever is
>     needed for reflection purposes, as variant_alternatives<S> : tuple of
>     the alternatives.
>
>     Comments welcome.
>
>
> That looks hideously ugly, syntactically speaking. Just look at all of=20
> the syntactic noise in the declaration. You have to prefix the=20
> `union`. You declare a bunch of `struct`s with anonymous members, for=20
> some unknown reason.
I have my reasons. What do you find hideously ugly in

template <class T, class U>
union Either {
      case Left<T>;
      case Right<U>;
};

Clearly we don't have the same taste.
>
> And then there's your "inspect" syntax,
As I said this is the draft proposal from Bjarne. Is in not mine at all.=20
BTW, this is something that I'm all for.
> which again is needlessly cumbersome (as well as creating keywords for=20
> no reason).
I will not discuss at this level of keywords.
> P0095 made things simple: you access named fields just like a union or=20
> struct currently, but you can also switch on the various=20
> possibilities. The switch statement looked and acted as much like a=20
> regular switch as reasonable. Your way invents entirely new syntax,=20
> while making simple access more cumbersome.
No, I don't use to invent such hideously ugly things.
>
> The overall result is far more cumbersome than the P0095 method.
What do you find is cumbersome?  The use of a field name to be used as a=20
type constructor and as a type matching don't seems to me the best=20
thing. We have that that types have type constructors already, so why=20
don't use them?
And why not use these type constructors as pattern matchers?


> Who cares if you have "sum of product types" if the result is ugly,=20
> hard-to-use code?
But I don't think this is ugly but elegant. How wins?
>
> I don't understand what genuine problem with variants as a library=20
> type that this actually solves. Granted, I don't really buy the=20
> motivational argument put forth by P0095 either. Variants are=20
> important, yes. But unless implementing them in the language can=20
> actually resolve issues raised by library implementations, they're=20
> really not important enough to need to be a first-class language=20
> feature. And P0095 basically punted on the most important=20
> implementation question (exceptions).
>
Hmm, If you don't want variant in the language, I will not try to shell=20
them to you.

Thanks as always for your constructive comments,
Vicente

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 13/12/2015 10:17, Nicol Bolas a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:1923e9f8-756c-4920-9431-d724ec645437@isocpp.org"
      type=3D"cite">On Sunday, December 13, 2015 at 1:54:07 AM UTC-5,
      Vicente J. Botet Escriba wrote:
      <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
        0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi,
        <br>
        <br>
        If we remove the field names in POD structs and unions
        <br>
        <br>
        union S {
        <br>
        =C2=A0 =C2=A0 =C2=A0struct left {int a;} =C2=A0c1;
        <br>
        =C2=A0 =C2=A0 =C2=A0struct right{string a;} =C2=A0c2;
        <br>
        };
        <br>
        <br>
        as in
        <br>
        <br>
        union S {
        <br>
        =C2=A0 =C2=A0 =C2=A0struct left {int;} =C2=A0;
        <br>
        =C2=A0 =C2=A0 =C2=A0struct right{string;} =C2=A0;
        <br>
        };
        <br>
        <br>
        The result is syntactically quite close to sum types in
        functional <br>
        languages like Haskhell
        <br>
        <br>
        data S =3D Left int | Right string
        <br>
        <br>
        However we need to add something else to mean that we want a
        variant (a <br>
        discriminated union)
        <br>
        <br>
        P0095 proposes to extend unions so that the field name is used
        as <br>
        constructor and case selector.
        <br>
        <br>
        enum union command {
        <br>
        =C2=A0 =C2=A0std::size_t set_score; // Set the score to the specifi=
ed
        value
        <br>
        =C2=A0 =C2=A0std::monotype fire_missile; // Fire a missile
        <br>
        =C2=A0 =C2=A0unsigned fire_laser; // Fire a laser with the specifie=
d
        intensity
        <br>
        =C2=A0 =C2=A0double rotate; // Rotate the ship by the specified deg=
rees.
        <br>
        };
        <br>
        <br>
        //construction
        <br>
        command cmd =3D command::set_score( 10 );
        <br>
        <br>
        // modifier
        <br>
        cmd =3D command::fire_missile( );
        <br>
        <br>
        // access
        <br>
        switch( cmd ) {
        <br>
        =C2=A0 =C2=A0case set_score value:
        <br>
        =C2=A0 =C2=A0 =C2=A0score =3D value;
        <br>
        =C2=A0 =C2=A0default:
        <br>
        }
        <br>
        <br>
        I believe that the structs themselves are a better type
        constructors <br>
        than the field names. My proposal is to use struct as type
        constructor <br>
        for each variant case. This ensures that we would not have
        repeated types.
        <br>
        <br>
        enum union command
        <br>
        {
        <br>
        =C2=A0 =C2=A0struct set_score {std::size_t };
        <br>
        =C2=A0 =C2=A0struct fire_missile { } ;
        <br>
        =C2=A0 =C2=A0struct fire_laser { unsigned } ;
        <br>
        =C2=A0 =C2=A0struct rotate { double } ;
        <br>
        };
        <br>
        <br>
        or
        <br>
        <br>
        union command
        <br>
        {
        <br>
        =C2=A0 =C2=A0case struct set_score {std::size_t };
        <br>
        =C2=A0 =C2=A0case struct fire_missile {} ;
        <br>
        =C2=A0 =C2=A0case struct fire_laser{unsigned} ;
        <br>
        =C2=A0 =C2=A0case struct rotate{double} ;
        <br>
        };
        <br>
        <br>
        There will be an implicit conversion from set_score,
        fire_missile, <br>
        fire_laser and rotate to command
        <br>
        <br>
        command cmd =3D command::set_score { 10 }; // Note the use of {}
        <br>
        <br>
        cmd =3D command::fire_missile{};
        <br>
        <br>
        <br>
        I suggest to take the syntax proposed by BS in order to inspect
        the contents
        <br>
        <br>
        inspect( cmd )
        <br>
        {
        <br>
        =C2=A0 =C2=A0when set_score{value}: =C2=A0// the syntax is close to=
 the p0144 <br>
        structured bindings
        <br>
        =C2=A0 =C2=A0 =C2=A0score =3D value;
        <br>
        =C2=A0 =C2=A0default:
        <br>
        }
        <br>
        <br>
        Using struct as cases of a variant give us sum of product types
        directly <br>
        as the struct can contain several types. Next follow the usual
        Tree example.
        <br>
        <br>
        template &lt;class T&gt;
        <br>
        union Tree {
        <br>
        =C2=A0 =C2=A0 =C2=A0case struct Empty{};
        <br>
        =C2=A0 =C2=A0 =C2=A0case struct Leaf{T;};
        <br>
        =C2=A0 =C2=A0 =C2=A0case struct Node{unique_ptr&lt;Tree&gt;;
        unique_ptr&lt;Tree&gt;;};
        <br>
        };
        <br>
        <br>
        Tree t =3D Node{ unique_ptr { Leaf { 1 } }, unique_ptr { Leaf { 2
        } } }; <br>
        // This will be valid after adoption of p0091r0
        <br>
      </blockquote>
      <div><br>
        That doesn't work. Not even with P0091. The broken part being
        the declaration of `Node`.<br>
        <br>
        `unique_ptr&lt;Tree&gt;` is not a typename; it isn't even a
        template. P0091 can't make that one work, because P0091 is about
        determining the template arguments of variables based on how
        they're initialized. And those variables aren't being
        initialized yet. Therefore, there is no way for the compiler to
        know what those types actually are. And therefore, the compiler
        cannot give them a size and so forth.<br>
        <br>
        `struct Node{unique_ptr&lt;Tree&gt;;}; is no more valid than
        `struct Node{auto;};`.<br>
        <br>
        Also, I don't see how you could be creating a `unique_ptr`
        without an actual `new` expression. Not unless you're expecting
        `unique_ptr` to be extended with the facilities of
        `make_unique`.<br>
        <br>
      </div>
      <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
        0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
        The previous statement will need the qualification of Tree::
        <br>
        <br>
        Tree t =3D Tree::Node{ unique_ptr { Tree::Leaf { 1 } }, unique_ptr
        { <br>
        Tree::Leaf { 2 } } };
        <br>
        <br>
        <br>
        Using struct instead of a field name has the advantage (or the <br>
        liability) to be able to define the struct outside the variant.
        <br>
        <br>
        We could define
        <br>
        <br>
        template &lt;class T&gt;
        <br>
        struct Left { T;};
        <br>
        <br>
        template &lt;class T&gt;
        <br>
        struct Right { T;};
        <br>
        <br>
        template &lt;class T, class U&gt;
        <br>
        union Either {
        <br>
        =C2=A0 =C2=A0 =C2=A0case Left&lt;T&gt;;
        <br>
        =C2=A0 =C2=A0 =C2=A0case Right&lt;U&gt;;
        <br>
        }
        <br>
        <br>
        Either&lt;int, string&gt; =3D Left { 10 }; // This will be valid
        after adoption <br>
        of p0091r0.
        <br>
        <br>
        I said or the liability because when the structure is defined
        outside <br>
        the variant, the alternative, Left or Right in this case, can be
        also an <br>
        alternative to another variant and be subject to ambiguity.=C2=A0<b=
r>
      </blockquote>
      <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
        0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
        <br>
        <br>
        As the compiler knows the alternatives, it can generate
        =C2=A0whatever is <br>
        needed for reflection purposes, as variant_alternatives&lt;S&gt;
        : tuple of <br>
        the alternatives.
        <br>
        <br>
        Comments welcome.
        <br>
      </blockquote>
      <div><br>
        That looks hideously ugly, syntactically speaking. Just look at
        all of the syntactic noise in the declaration. You have to
        prefix the `union`. You declare a bunch of `struct`s with
        anonymous members, for some unknown reason.<br>
      </div>
    </blockquote>
    I have my reasons. What do you find hideously ugly in<br>
    <br>
    template &lt;class T, class U&gt;
    <br>
    union Either {
    <br>
    =C2=A0 =C2=A0 =C2=A0case Left&lt;T&gt;;
    <br>
    =C2=A0 =C2=A0 =C2=A0case Right&lt;U&gt;;
    <br>
    };
    <br>
    <br>
    Clearly we don't have the same taste.<br>
    <blockquote
      cite=3D"mid:1923e9f8-756c-4920-9431-d724ec645437@isocpp.org"
      type=3D"cite">
      <div><br>
        And then there's your "inspect" syntax, </div>
    </blockquote>
    As I said this is the draft proposal from Bjarne. Is in not mine at
    all. BTW, this is something that I'm all for.<br>
    <blockquote
      cite=3D"mid:1923e9f8-756c-4920-9431-d724ec645437@isocpp.org"
      type=3D"cite">
      <div>which again is needlessly cumbersome (as well as creating
        keywords for no reason). </div>
    </blockquote>
    I will not discuss at this level of keywords.<br>
    <blockquote
      cite=3D"mid:1923e9f8-756c-4920-9431-d724ec645437@isocpp.org"
      type=3D"cite">
      <div>P0095 made things simple: you access named fields just like a
        union or struct currently, but you can also switch on the
        various possibilities. The switch statement looked and acted as
        much like a regular switch as reasonable. Your way invents
        entirely new syntax, while making simple access more cumbersome.<br=
>
      </div>
    </blockquote>
    No, I don't use to invent such hideously ugly things.<br>
    <blockquote
      cite=3D"mid:1923e9f8-756c-4920-9431-d724ec645437@isocpp.org"
      type=3D"cite">
      <div><br>
        The overall result is far more cumbersome than the P0095 method.
      </div>
    </blockquote>
    What do you find is cumbersome?=C2=A0 The use of a field name to be use=
d
    as a type constructor and as a type matching don't seems to me the
    best thing. We have that that types have type constructors already,
    so why don't use them?<br>
    And why not use these type constructors as pattern matchers?<br>
    <br>
    =C2=A0<br>
    <blockquote
      cite=3D"mid:1923e9f8-756c-4920-9431-d724ec645437@isocpp.org"
      type=3D"cite">
      <div>Who cares if you have "sum of product types" if the result is
        ugly, hard-to-use code?<br>
      </div>
    </blockquote>
    But I don't think this is ugly but elegant. How wins?<br>
    <blockquote
      cite=3D"mid:1923e9f8-756c-4920-9431-d724ec645437@isocpp.org"
      type=3D"cite">
      <div><br>
        I don't understand what genuine problem with variants as a
        library type that this actually solves. Granted, I don't really
        buy the motivational argument put forth by P0095 either.
        Variants are important, yes. But unless implementing them in the
        language can actually resolve issues raised by library
        implementations, they're really not important enough to need to
        be a first-class language feature. And P0095 basically punted on
        the most important implementation question (exceptions).<br>
      </div>
      <br>
    </blockquote>
    Hmm, If you don't want variant in the language, I will not try to
    shell them to you.<br>
    <br>
    Thanks as always for your constructive comments,<br>
    Vicente<br>
  </body>
</html>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--------------010302030006000507070507--

.

------=_Part_316_1737855370.1450030880638
Content-Type: multipart/alternative;
 boundary="----=_Part_317_1838380556.1450030880640"

------=_Part_317_1838380556.1450030880640
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sunday, December 13, 2015 at 6:15:15 AM UTC-5, Vicente J. Botet Escriba=
=20
wrote:
>
> Le 13/12/2015 10:17, Nicol Bolas a =C3=A9crit :
>
> On Sunday, December 13, 2015 at 1:54:07 AM UTC-5, Vicente J. Botet Escrib=
a=20
> wrote:
>
>> Comments welcome.=20
>>
>
> That looks hideously ugly, syntactically speaking. Just look at all of th=
e=20
> syntactic noise in the declaration. You have to prefix the `union`. You=
=20
> declare a bunch of `struct`s with anonymous members, for some unknown=20
> reason.
>
> I have my reasons. What do you find hideously ugly in
>
> template <class T, class U>=20
> union Either {=20
>      case Left<T>;=20
>      case Right<U>;=20
> };=20
>
> Clearly we don't have the same taste.
>

Well, that was only one of your examples. But here, I see a gross mis-use=
=20
of the `case` keyword for something that doesn't involve `switch`ing. Also,=
=20
it's not clear what "Left" and "Right" mean in this context.

I fail to see how that's an improvement over the P0095 version:

template<typename T, typename U>
enum union Either
{
  T left;
  U right;
};

But we'll discuss that more later.

> And then there's your "inspect" syntax,=20
>
> As I said this is the draft proposal from Bjarne.
>

Is that what you meant when you referred to "the syntax proposed by BS"?=20
Because that particular acronym typically stands for something else in=20
English ;) I didn't really understand what you were talking about.

Also, what "draft proposal" are you talking about?

> The overall result is far more cumbersome than the P0095 method.=20
>
> What do you find is cumbersome?  The use of a field name to be used as a=
=20
> type constructor and as a type matching don't seems to me the best thing.
>

Using a variable name as what appears to be the typename in a variable=20
declaration is odd. Your way is far more odd, in that it requires a whole=
=20
new bit of syntax, with its own keywords and everything. Not to mention=20
needing to be able to create variables that have no names. That's *far*=20
more odd than anything P0095 proposes.


> Who cares if you have "sum of product types" if the result is ugly,=20
> hard-to-use code?
>
> But I don't think this is ugly but elegant. How wins?
>

By looking at the reasons for our two positions.

My claims of it being "ugly" are based on the excessive syntax needed for=
=20
something that P0095 was able to do very simply. It's also based on the=20
fact that your proposed code looks very foreign in C++, relative to P0095=
=20
which more or less works like you would expect.

P0095 is basically "unions that work in C++", while your suggestion is=20
something altogether different.

This is a P0095 language-variant:

enum union Typename
{
  Type1 name1;
  Type2 name2;
};

Now let's analyze this syntax. You need some keyword to declare that you're=
=20
making one of these types. You need a Typename, since you're declaring a=20
type. You need a list of types, so you provide those types. And half the=20
point of P0095 is that the individual elements are named, so you need a=20
name for each one.

With the exception of the use of `enum` rather than having its own keyword,=
=20
there is no superfluous syntax present. So this is the minimum possible=20
syntax for communicating the idea that this type is trying to communicate.

Furthermore, it follows the traditional rules of C++ with regard to syntax,=
=20
member variable declarations, and so forth. It looks like normal C++ code.=
=20
Indeed, you could easily understand what this would mean:

enum union Typename
{
  Type1 name1;
  Type2 name2 =3D {...};
};

With this definition, it would make sense to believe that a=20
default-initialized `Typename` would be in the `Type2` state.

That would be a good example of elegant syntax: strong points of=20
familiarity and a lack of surplus syntax.

Now, compare that to what you want:

enum union Typename
{
   struct name1 {Type1; };
   struct name2 {Type2; };
};

Here, it takes more syntax to say the exact same thing. We have a=20
repetition of the keyword `struct`. We have some internal braces that don't=
=20
really need to be there for what we're doing.

Also, it lacks familiarity with C++ rules. You're declaring a nested=20
struct, but the members of that struct have no names. Not only that, you're=
=20
declaring a nested struct, but never declaring variables of that struct's=
=20
type, yet a variable is being created anyway. These are very new things for=
=20
C++, so it lacks familiarity.

In your `inspect` syntax, you refer to members, not by variable names, but=
=20
by *typenames*. Which means that the conceptual name of the state comes=20
before the *useful* type of that state. That is, `name1` happens before=20
`Type1`. That's also very un-C++-ish.

If we were to apply that default initialization thing, what would that look=
=20
like?

enum union Typename
{
   struct name1 {Type1; };
   struct name2 {Type2; } =3D {...};
};

That looks even fishier, since you're supposed to use an initializer on a=
=20
variable, not a type. Variables have *names* in C++, and your feature=20
revolves entirely around unnamed variables. That's a *very* new thing for=
=20
C++, so again, it lacks familiarity.

What is your reason for claiming that your proposal, which involves unnamed=
=20
variables and various other things, is more elegant?

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

On Sunday, December 13, 2015 at 6:15:15 AM UTC-5, Vicente J. Botet Escriba =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div>Le 13/12/2015 10:17, Nicol Bolas a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite">On Sunday, December 13, 2015 at 1:54:07 AM UT=
C-5,
      Vicente J. Botet Escriba wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left=
:1ex">Comments welcome.
        <br>
      </blockquote>
      <div><br>
        That looks hideously ugly, syntactically speaking. Just look at
        all of the syntactic noise in the declaration. You have to
        prefix the `union`. You declare a bunch of `struct`s with
        anonymous members, for some unknown reason.<br>
      </div>
    </blockquote>
    I have my reasons. What do you find hideously ugly in<br>
    <br>
    template &lt;class T, class U&gt;
    <br>
    union Either {
    <br>
    =C2=A0 =C2=A0 =C2=A0case Left&lt;T&gt;;
    <br>
    =C2=A0 =C2=A0 =C2=A0case Right&lt;U&gt;;
    <br>
    };
    <br>
    <br>
    Clearly we don&#39;t have the same taste.<br></div></blockquote><div><b=
r>Well, that was only one of your examples. But here, I see a gross mis-use=
 of the `case` keyword for something that doesn&#39;t involve `switch`ing. =
Also, it&#39;s not clear what &quot;Left&quot; and &quot;Right&quot; mean i=
n this context.<br><br>I fail to see how that&#39;s an improvement over the=
 P0095 version:<br><br><div class=3D"prettyprint" style=3D"background-color=
: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid=
; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><d=
iv class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by=
-prettify">template</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">typename</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> U</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">enum</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">union</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify"=
>Either</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 T left<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 U right</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">};</span></div></code></div=
><br>But we&#39;ll discuss that more later.<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div text=3D"#000000" bgcolor=3D"#FFFFFF">
    <blockquote type=3D"cite">
      <div>
        And then there&#39;s your &quot;inspect&quot; syntax, </div>
    </blockquote>
    As I said this is the draft proposal from Bjarne.</div></blockquote><di=
v><br>Is that what you meant when you referred to &quot;the syntax proposed=
 by BS&quot;? Because that particular acronym typically stands for somethin=
g else in English ;) I didn&#39;t really understand what you were talking a=
bout.<br><br>Also, what &quot;draft proposal&quot; are you talking about?</=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div text=3D"#000000" bgco=
lor=3D"#FFFFFF">
    <blockquote type=3D"cite">The overall result is far more cumbersome tha=
n the P0095 method.
     =20
    </blockquote>
    What do you find is cumbersome?=C2=A0 The use of a field name to be use=
d
    as a type constructor and as a type matching don&#39;t seems to me the
    best thing.</div></blockquote><div><br>Using a variable name as what ap=
pears to be the typename in a variable declaration is odd. Your way is far =
more odd, in that it requires a whole new bit of syntax, with its own keywo=
rds and everything. Not to mention needing to be able to create variables t=
hat have no names. That&#39;s <i>far</i> more odd than anything P0095 propo=
ses.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div text=3D=
"#000000" bgcolor=3D"#FFFFFF"><br>
    <blockquote type=3D"cite">
      <div>Who cares if you have &quot;sum of product types&quot; if the re=
sult is
        ugly, hard-to-use code?<br>
      </div>
    </blockquote>
    But I don&#39;t think this is ugly but elegant. How wins?<br></div></bl=
ockquote><div><br>By looking at the reasons for our two positions.<br><br>M=
y claims of it being &quot;ugly&quot; are based on the excessive syntax nee=
ded for something that P0095 was able to do very simply. It&#39;s also base=
d on the fact that your proposed code looks very foreign in C++, relative t=
o P0095 which more or less works like you would expect.<br><br>P0095 is bas=
ically &quot;unions that work in C++&quot;, while your suggestion is someth=
ing altogether different.<br><br>This is a P0095 language-variant:<br><br><=
div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bo=
rder-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; wor=
d-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettypri=
nt"><span style=3D"color: #008;" class=3D"styled-by-prettify">enum</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">union</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #60=
6;" class=3D"styled-by-prettify">Typename</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>=C2=A0 </span><span style=3D"color: #606;" class=3D"sty=
led-by-prettify">Type1</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> name1</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>=C2=A0 </span><span style=3D"color: #606;" class=3D"styled-by-prettify">=
Type2</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> name=
2</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">};</span></div></code></=
div><br>Now let&#39;s analyze this syntax. You need some keyword to declare=
 that you&#39;re making one of these types. You need a Typename, since you&=
#39;re declaring a type. You need a list of types, so you provide those typ=
es. And half the point of P0095 is that the individual elements are named, =
so you need a name for each one.<br><br>With the exception of the use of `e=
num` rather than having its own keyword, there is no superfluous syntax pre=
sent. So this is the minimum possible syntax for communicating the idea tha=
t this type is trying to communicate.<br><br>Furthermore, it follows the tr=
aditional rules of C++ with regard to syntax, member variable declarations,=
 and so forth. It looks like normal C++ code. Indeed, you could easily unde=
rstand what this would mean:<br><br><div class=3D"prettyprint" style=3D"bac=
kground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border=
-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pr=
ettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">enum</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">union</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Typen=
ame</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><spa=
n style=3D"color: #606;" class=3D"styled-by-prettify">Type1</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> name1</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"colo=
r: #606;" class=3D"styled-by-prettify">Type2</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> name2 </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{...};</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">};</span></div></code></div><br>With this definition, it would make se=
nse to believe that a default-initialized `Typename` would be in the `Type2=
` state.<br><br>That would be a good example of elegant syntax: strong poin=
ts of familiarity and a lack of surplus syntax.<br><br>Now, compare that to=
 what you want:<br><br><div class=3D"prettyprint" style=3D"background-color=
: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid=
; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><d=
iv class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by=
-prettify">enum</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">unio=
n</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #606;" class=3D"styled-by-prettify">Typename</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> name1 </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #606;=
" class=3D"styled-by-prettify">Type1</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>=C2=A0 =C2=A0</span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">struct</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> name2 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
{</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Type2</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">};</span></div></code></div><br>Here, it takes=
 more syntax to say the exact same thing. We have a repetition of the keywo=
rd `struct`. We have some internal braces that don&#39;t really need to be =
there for what we&#39;re doing.<br><br>Also, it lacks familiarity with C++ =
rules. You&#39;re declaring a nested struct, but the members of that struct=
 have no names. Not only that, you&#39;re declaring a nested struct, but ne=
ver declaring variables of that struct&#39;s type, yet a variable is being =
created anyway. These are very new things for C++, so it lacks familiarity.=
<br><br>In your `inspect` syntax, you refer to members, not by variable nam=
es, but by <i>typenames</i>. Which means that the conceptual name of the st=
ate comes before the <i>useful</i> type of that state. That is, `name1` hap=
pens before `Type1`. That&#39;s also very un-C++-ish.<br><br>If we were to =
apply that default initialization thing, what would that look like?<br><br>=
<div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); b=
order-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; wo=
rd-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettypr=
int"><span style=3D"color: #008;" class=3D"styled-by-prettify">enum</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">union</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
06;" class=3D"styled-by-prettify">Typename</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>=C2=A0 =C2=A0</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> name1 </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">{</span><span style=3D"color: #606;" class=3D"styled-by-pr=
ettify">Type1</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0</span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> name2 </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"=
color: #606;" class=3D"styled-by-prettify">Type2</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">{...};</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">};</span></div></code></=
div><br>That looks even fishier, since you&#39;re supposed to use an initia=
lizer on a variable, not a type. Variables have <i>names</i> in C++, and yo=
ur feature revolves entirely around unnamed variables. That&#39;s a *very* =
new thing for C++, so again, it lacks familiarity.<br><br>What is your reas=
on for claiming that your proposal, which involves unnamed variables and va=
rious other things, is more elegant?<br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_317_1838380556.1450030880640--
------=_Part_316_1737855370.1450030880638--

.

This is a multi-part message in MIME format.
--------------000902030103060403090003
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 13/12/2015 19:21, Nicol Bolas a =C3=A9crit :
> On Sunday, December 13, 2015 at 6:15:15 AM UTC-5, Vicente J. Botet=20
> Escriba wrote:
>
>     Le 13/12/2015 10:17, Nicol Bolas a =C3=A9crit :
>>     On Sunday, December 13, 2015 at 1:54:07 AM UTC-5, Vicente J.
>>     Botet Escriba wrote:
>>
>>         Comments welcome.
>>
>>
>>     That looks hideously ugly, syntactically speaking. Just look at
>>     all of the syntactic noise in the declaration. You have to prefix
>>     the `union`. You declare a bunch of `struct`s with anonymous
>>     members, for some unknown reason.
>     I have my reasons. What do you find hideously ugly in
>
>     template <class T, class U>
>     union Either {
>          case Left<T>;
>          case Right<U>;
>     };
>
>     Clearly we don't have the same taste.
>
>
> Well, that was only one of your examples. But here, I see a gross=20
> mis-use of the `case` keyword for something that doesn't involve=20
> `switch`ing. Also, it's not clear what "Left" and "Right" mean in this=20
> context.
This is because you don't know the grammar ;-)
>
> I fail to see how that's an improvement over the P0095 version:
>
> |
> template<typenameT,typenameU>
> enumunionEither
> {
>   T left;
>   U right;
> };
> |
>
> But we'll discuss that more later.
Yes, we will discus later.
>
>>     And then there's your "inspect" syntax,
>     As I said this is the draft proposal from Bjarne.
>
>
> Is that what you meant when you referred to "the syntax proposed by=20
> BS"? Because that particular acronym typically stands for something=20
> else in English ;) I didn't really understand what you were talking about=
..
>
> Also, what "draft proposal" are you talking about?
It is a presentation Bjarne did in Rapperswill IIRC. You can request him=20
if you want. You could find some elements at [1] Open Pattern Matching=20
for C++

[1]=20
https://www.google.fr/url?sa=3Dt&rct=3Dj&q=3D&esrc=3Ds&source=3Dweb&cd=3D1&=
cad=3Drja&uact=3D8&ved=3D0ahUKEwjPzPqi2trJAhVM2xoKHYxxC8cQFggjMAA&url=3Dhtt=
p%3A%2F%2Fwww.stroustrup.com%2FOpenPatternMatching.pdf&usg=3DAFQjCNEGrAYsjL=
SlJKL8Ty2JWtkMk9MeOg&sig2=3DCzc7J-5QIKvglx_PbSNSNA

>>     The overall result is far more cumbersome than the P0095 method.=20
>     What do you find is cumbersome?  The use of a field name to be
>     used as a type constructor and as a type matching don't seems to
>     me the best thing.
>
>
> Using a variable name as what appears to be the typename in a variable=20
> declaration is odd. Your way is far more odd, in that it requires a=20
> whole new bit of syntax, with its own keywords and everything. Not to=20
> mention needing to be able to create variables that have no names.=20
> That's /far/ more odd than anything P0095 proposes.
You can have parameters that have no name because you don't use them.=20
Here is the same. We don't use the field name, we have just a field=20
type, so why to give them a name?
>
>
>>     Who cares if you have "sum of product types" if the result is
>>     ugly, hard-to-use code?
>     But I don't think this is ugly but elegant. How wins?
>
>
> By looking at the reasons for our two positions.
>
> My claims of it being "ugly" are based on the excessive syntax needed=20
> for something that P0095 was able to do very simply. It's also based=20
> on the fact that your proposed code looks very foreign in C++,=20
> relative to P0095 which more or less works like you would expect.
>
> P0095 is basically "unions that work in C++", while your suggestion is=20
> something altogether different.
>
> This is a P0095 language-variant:
>
> |
> enumunionTypename
> {
> Type1name1;
> Type2name2;
> };
> |
>
> Now let's analyze this syntax. You need some keyword to declare that=20
> you're making one of these types. You need a Typename, since you're=20
> declaring a type. You need a list of types, so you provide those=20
> types. And half the point of P0095 is that the individual elements are=20
> named, so you need a name for each one.
Why do you need to name the fields if you never used them as fields This=20
is what I find weird in p0095.
The syntax Typename::name1(v1) is not too c++, or is it?

>
> With the exception of the use of `enum` rather than having its own=20
> keyword, there is no superfluous syntax present. So this is the=20
> minimum possible syntax for communicating the idea that this type is=20
> trying to communicate.
>
> Furthermore, it follows the traditional rules of C++ with regard to=20
> syntax, member variable declarations, and so forth. It looks like=20
> normal C++ code. Indeed, you could easily understand what this would mean=
:
>
> |
> enumunionTypename
> {
> Type1name1;
> Type2name2 =3D{...};
> };
> |
>
I don't buy that. This could means the default value for name2, not the=20
default for Typename.

But what does mean the following

Typename v;
v.name1 =3D1,
f(v.name2);

This is what we usually have when we have fields names, we use them to=20
set a value and to obtain it.
I don't want a union, I want a variant.

> With this definition, it would make sense to believe that a=20
> default-initialized `Typename` would be in the `Type2` state.
>
> That would be a good example of elegant syntax: strong points of=20
> familiarity and a lack of surplus syntax.
>
> Now, compare that to what you want:
>
> |
> enumunionTypename
> {
> structname1 {Type1;};
> structname2 {Type2;};
> };
> |
>
In reality what I want is either to extend the enums having enumerations=20
that have parameters

|
variantKeywordTypename{name1 (Type1),name2 (Type2) }; // enum like extensio=
n
|

This is the minimum I can have. What I was proposing was using existing=20
facilities that allow to us name1(v1). An the single one I find was a=20
Type itself as the type constructor uses this syntax name1(v1) and we=20
are really creating a new type that depends on name1.

In order you see that the field names as used in P0095 are part of the=20
type, lets see the case where we have the same type twice, but with=20
different field names

|
enumunionA
{
   Bc1;
Bc2;
};
|

You can then have

B b;
A a =3D A::c1(b);
a =3D A::c2(b);

Here we have always the same B value, but we have changed the selector.=20
So the selector is part of the type. This is not the same that a field=20
name of a struct or a union.

switch (a) {
     case A::c1 x:
     case A::c2 x:
};

Having

|
variantKeywordA{  c1(B), c2(B) };
|

switch (a) {
     case A::c1(x):
     case A::c2(x):
};

Is this better for you? If yes, choose you keyword.

Or

|
variantKeeyword Type =3D name1(Type1) | name2(Type2);


inspect (a) {
     when A::c1(x):
|when| A::c2(x):
};
|

> Here, it takes more syntax to say the exact same thing. We have a=20
> repetition of the keyword `struct`. We have some internal braces that=20
> don't really need to be there for what we're doing.
>
> Also, it lacks familiarity with C++ rules. You're declaring a nested=20
> struct, but the members of that struct have no names. Not only that,=20
> you're declaring a nested struct, but never declaring variables of=20
> that struct's type, yet a variable is being created anyway.
No, we don't create a variable of each one of the alternatives.
> These are very new things for C++, so it lacks familiarity.
>
> In your `inspect` syntax, you refer to members, not by variable names,=20
> but by /typenames/. Which means that the conceptual name of the state=20
> comes before the /useful/ type of that state. That is, `name1` happens=20
> before `Type1`. That's also very un-C++-ish.
I don't want them to be members, as they aren't. I want the type to be A=20
or B.
>
> If we were to apply that default initialization thing, what would that=20
> look like?
>
> |
> enumunionTypename
> {
> structname1 {Type1;};
> structname2 {Type2;}=3D{...};
> };
> |
>

But you could name the fields if you wanted, but their access would not=20
be safe?

|
enumunionTypename
{
structname1 {Type1;} x;
structname2 {Type2;}y=3D{...};
};
|

This is not what I'm proposing, so I don't need to justify anything here.
> That looks even fishier, since you're supposed to use an initializer=20
> on a variable, not a type. Variables have /names/ in C++, and your=20
> feature revolves entirely around unnamed variables. That's a *very*=20
> new thing for C++, so again, it lacks familiarity.
>
> What is your reason for claiming that your proposal, which involves=20
> unnamed variables and various other things, is more elegant?
Resuming: P00095 make use of field names as been part of the alternative=20
types. This is wrong IMO.
A variant needs selector to mean one type or another if we want to do=20
pattern matching.

E.g. in Pascal you have fist a selector and then depending on the=20
selector you have something more specific.

type paytype =3D (salaried,hourly);
var employee : record
id : integer;
dept: integer;
age : integer;
case payclass: paytype of                   { selector }
salaried: (monthlyrate : real; startdate : integer);
hourly: (rateperhour : real; reghours : integer; overtime : integer);
end;

employee.payclass:=3Dsalaried;
employee.monthlyrate:=3D575.0;
employee.startdate:=3D13085;
{this should bomb as there are no rateperhour, etc. because=20
payclass=3Dsalaried}


Note that the fields that have a name are the fields that have a sens=20
once we have the selector initialized.
In order to ensure that we don't have bombs, the better is to don't give=20
access via the names.


Vicente

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 13/12/2015 19:21, Nicol Bolas a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:99f7f42b-a051-46f0-9246-d2928ffb8d23@isocpp.org"
      type=3D"cite">On Sunday, December 13, 2015 at 6:15:15 AM UTC-5,
      Vicente J. Botet Escriba wrote:
      <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
        0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
        <div text=3D"#000000" bgcolor=3D"#FFFFFF">
          <div>Le 13/12/2015 10:17, Nicol Bolas a =C3=A9crit=C2=A0:<br>
          </div>
          <blockquote type=3D"cite">On Sunday, December 13, 2015 at
            1:54:07 AM UTC-5, Vicente J. Botet Escriba wrote:<br>
            <blockquote class=3D"gmail_quote"
              style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
              solid;padding-left:1ex">Comments welcome. <br>
            </blockquote>
            <div><br>
              That looks hideously ugly, syntactically speaking. Just
              look at all of the syntactic noise in the declaration. You
              have to prefix the `union`. You declare a bunch of
              `struct`s with anonymous members, for some unknown reason.<br=
>
            </div>
          </blockquote>
          I have my reasons. What do you find hideously ugly in<br>
          <br>
          template &lt;class T, class U&gt; <br>
          union Either { <br>
          =C2=A0 =C2=A0 =C2=A0case Left&lt;T&gt;; <br>
          =C2=A0 =C2=A0 =C2=A0case Right&lt;U&gt;; <br>
          }; <br>
          <br>
          Clearly we don't have the same taste.<br>
        </div>
      </blockquote>
      <div><br>
        Well, that was only one of your examples. But here, I see a
        gross mis-use of the `case` keyword for something that doesn't
        involve `switch`ing. Also, it's not clear what "Left" and
        "Right" mean in this context.<br>
      </div>
    </blockquote>
    This is because you don't know the grammar ;-) <br>
    <blockquote
      cite=3D"mid:99f7f42b-a051-46f0-9246-d2928ffb8d23@isocpp.org"
      type=3D"cite">
      <div><br>
        I fail to see how that's an improvement over the P0095 version:<br>
        <br>
        <div class=3D"prettyprint" style=3D"background-color: rgb(250, 250,
          250); border-color: rgb(187, 187, 187); border-style: solid;
          border-width: 1px; word-wrap: break-word;"><code
            class=3D"prettyprint">
            <div class=3D"subprettyprint"><span style=3D"color: #008;"
                class=3D"styled-by-prettify">template</span><span
                style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</s=
pan><span
                style=3D"color: #008;" class=3D"styled-by-prettify">typenam=
e</span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> T</spa=
n><span
                style=3D"color: #660;" class=3D"styled-by-prettify">,</span=
><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span
                style=3D"color: #008;" class=3D"styled-by-prettify">typenam=
e</span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> U</spa=
n><span
                style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</s=
pan><span
                style=3D"color: #000;" class=3D"styled-by-prettify"><br>
              </span><span style=3D"color: #008;"
                class=3D"styled-by-prettify">enum</span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span
                style=3D"color: #008;" class=3D"styled-by-prettify">union</=
span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span
                style=3D"color: #606;" class=3D"styled-by-prettify">Either<=
/span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"><br>
              </span><span style=3D"color: #660;"
                class=3D"styled-by-prettify">{</span><span style=3D"color:
                #000;" class=3D"styled-by-prettify"><br>
                =C2=A0 T left</span><span style=3D"color: #660;"
                class=3D"styled-by-prettify">;</span><span style=3D"color:
                #000;" class=3D"styled-by-prettify"><br>
                =C2=A0 U right</span><span style=3D"color: #660;"
                class=3D"styled-by-prettify">;</span><span style=3D"color:
                #000;" class=3D"styled-by-prettify"><br>
              </span><span style=3D"color: #660;"
                class=3D"styled-by-prettify">};</span></div>
          </code></div>
        <br>
        But we'll discuss that more later.<br>
      </div>
    </blockquote>
    Yes, we will discus later.<br>
    <blockquote
      cite=3D"mid:99f7f42b-a051-46f0-9246-d2928ffb8d23@isocpp.org"
      type=3D"cite">
      <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
        0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
        <div text=3D"#000000" bgcolor=3D"#FFFFFF">
          <blockquote type=3D"cite">
            <div> And then there's your "inspect" syntax, </div>
          </blockquote>
          As I said this is the draft proposal from Bjarne.</div>
      </blockquote>
      <div><br>
        Is that what you meant when you referred to "the syntax proposed
        by BS"? Because that particular acronym typically stands for
        something else in English ;) I didn't really understand what you
        were talking about.<br>
        <br>
        Also, what "draft proposal" are you talking about?</div>
    </blockquote>
    It is a presentation Bjarne did in Rapperswill IIRC. You can request
    him if you want. You could find some elements at [1]
    <meta charset=3D"utf-8">
    Open Pattern Matching for C++<br>
    <br>
    [1]
<a class=3D"moz-txt-link-freetext" href=3D"https://www.google.fr/url?sa=3Dt=
&amp;rct=3Dj&amp;q=3D&amp;esrc=3Ds&amp;source=3Dweb&amp;cd=3D1&amp;cad=3Drj=
a&amp;uact=3D8&amp;ved=3D0ahUKEwjPzPqi2trJAhVM2xoKHYxxC8cQFggjMAA&amp;url=
=3Dhttp%3A%2F%2Fwww.stroustrup.com%2FOpenPatternMatching.pdf&amp;usg=3DAFQj=
CNEGrAYsjLSlJKL8Ty2JWtkMk9MeOg&amp;sig2=3DCzc7J-5QIKvglx_PbSNSNA">https://w=
ww.google.fr/url?sa=3Dt&amp;rct=3Dj&amp;q=3D&amp;esrc=3Ds&amp;source=3Dweb&=
amp;cd=3D1&amp;cad=3Drja&amp;uact=3D8&amp;ved=3D0ahUKEwjPzPqi2trJAhVM2xoKHY=
xxC8cQFggjMAA&amp;url=3Dhttp%3A%2F%2Fwww.stroustrup.com%2FOpenPatternMatchi=
ng.pdf&amp;usg=3DAFQjCNEGrAYsjLSlJKL8Ty2JWtkMk9MeOg&amp;sig2=3DCzc7J-5QIKvg=
lx_PbSNSNA</a><br>
    <br>
    <blockquote
      cite=3D"mid:99f7f42b-a051-46f0-9246-d2928ffb8d23@isocpp.org"
      type=3D"cite">
      <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
        0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
        <div text=3D"#000000" bgcolor=3D"#FFFFFF">
          <blockquote type=3D"cite">The overall result is far more
            cumbersome than the P0095 method. </blockquote>
          What do you find is cumbersome?=C2=A0 The use of a field name to =
be
          used as a type constructor and as a type matching don't seems
          to me the best thing.</div>
      </blockquote>
      <div><br>
        Using a variable name as what appears to be the typename in a
        variable declaration is odd. Your way is far more odd, in that
        it requires a whole new bit of syntax, with its own keywords and
        everything. Not to mention needing to be able to create
        variables that have no names. That's <i>far</i> more odd than
        anything P0095 proposes.<br>
      </div>
    </blockquote>
    You can have parameters that have no name because you don't use
    them. Here is the same. We don't use the field name, we have just a
    field type, so why to give them a name?<br>
    <blockquote
      cite=3D"mid:99f7f42b-a051-46f0-9246-d2928ffb8d23@isocpp.org"
      type=3D"cite">
      <div><br>
      </div>
      <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
        0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
        <div text=3D"#000000" bgcolor=3D"#FFFFFF"><br>
          <blockquote type=3D"cite">
            <div>Who cares if you have "sum of product types" if the
              result is ugly, hard-to-use code?<br>
            </div>
          </blockquote>
          But I don't think this is ugly but elegant. How wins?<br>
        </div>
      </blockquote>
      <div><br>
        By looking at the reasons for our two positions.<br>
        <br>
        My claims of it being "ugly" are based on the excessive syntax
        needed for something that P0095 was able to do very simply. It's
        also based on the fact that your proposed code looks very
        foreign in C++, relative to P0095 which more or less works like
        you would expect.<br>
        <br>
        P0095 is basically "unions that work in C++", while your
        suggestion is something altogether different.<br>
        <br>
        This is a P0095 language-variant:<br>
        <br>
        <div class=3D"prettyprint" style=3D"background-color: rgb(250, 250,
          250); border-color: rgb(187, 187, 187); border-style: solid;
          border-width: 1px; word-wrap: break-word;"><code
            class=3D"prettyprint">
            <div class=3D"subprettyprint"><span style=3D"color: #008;"
                class=3D"styled-by-prettify">enum</span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span
                style=3D"color: #008;" class=3D"styled-by-prettify">union</=
span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span
                style=3D"color: #606;" class=3D"styled-by-prettify">Typenam=
e</span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"><br>
              </span><span style=3D"color: #660;"
                class=3D"styled-by-prettify">{</span><span style=3D"color:
                #000;" class=3D"styled-by-prettify"><br>
                =C2=A0 </span><span style=3D"color: #606;"
                class=3D"styled-by-prettify">Type1</span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> name1<=
/span><span
                style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
><span
                style=3D"color: #000;" class=3D"styled-by-prettify"><br>
                =C2=A0 </span><span style=3D"color: #606;"
                class=3D"styled-by-prettify">Type2</span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> name2<=
/span><span
                style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
><span
                style=3D"color: #000;" class=3D"styled-by-prettify"><br>
              </span><span style=3D"color: #660;"
                class=3D"styled-by-prettify">};</span></div>
          </code></div>
        <br>
        Now let's analyze this syntax. You need some keyword to declare
        that you're making one of these types. You need a Typename,
        since you're declaring a type. You need a list of types, so you
        provide those types. And half the point of P0095 is that the
        individual elements are named, so you need a name for each one.<br>
      </div>
    </blockquote>
    Why do you need to name the fields if you never used them as fields
    This is what I find weird in p0095.<br>
    The syntax Typename::name1(v1) is not too c++, or is it?<br>
    <br>
    <blockquote
      cite=3D"mid:99f7f42b-a051-46f0-9246-d2928ffb8d23@isocpp.org"
      type=3D"cite">
      <div><br>
        With the exception of the use of `enum` rather than having its
        own keyword, there is no superfluous syntax present. So this is
        the minimum possible syntax for communicating the idea that this
        type is trying to communicate.<br>
        <br>
        Furthermore, it follows the traditional rules of C++ with regard
        to syntax, member variable declarations, and so forth. It looks
        like normal C++ code. Indeed, you could easily understand what
        this would mean:<br>
        <br>
        <div class=3D"prettyprint" style=3D"background-color: rgb(250, 250,
          250); border-color: rgb(187, 187, 187); border-style: solid;
          border-width: 1px; word-wrap: break-word;"><code
            class=3D"prettyprint">
            <div class=3D"subprettyprint"><span style=3D"color: #008;"
                class=3D"styled-by-prettify">enum</span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span
                style=3D"color: #008;" class=3D"styled-by-prettify">union</=
span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span
                style=3D"color: #606;" class=3D"styled-by-prettify">Typenam=
e</span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"><br>
              </span><span style=3D"color: #660;"
                class=3D"styled-by-prettify">{</span><span style=3D"color:
                #000;" class=3D"styled-by-prettify"><br>
                =C2=A0 </span><span style=3D"color: #606;"
                class=3D"styled-by-prettify">Type1</span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> name1<=
/span><span
                style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
><span
                style=3D"color: #000;" class=3D"styled-by-prettify"><br>
                =C2=A0 </span><span style=3D"color: #606;"
                class=3D"styled-by-prettify">Type2</span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> name2 =
</span><span
                style=3D"color: #660;" class=3D"styled-by-prettify">=3D</sp=
an><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span
                style=3D"color: #660;" class=3D"styled-by-prettify">{...};<=
/span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"><br>
              </span><span style=3D"color: #660;"
                class=3D"styled-by-prettify">};</span></div>
          </code></div>
        <br>
      </div>
    </blockquote>
    I don't buy that. This could means the default value for name2, not
    the default for Typename.<br>
    <br>
    But what does mean the following<br>
    <br>
    Typename v;<br>
    v.name1 =3D1,<br>
    f(v.name2);<br>
    <br>
    This is what we usually have when we have fields names, we use them
    to set a value and to obtain it.<br>
    I don't want a union, I want a variant.<br>
    <br>
    <blockquote
      cite=3D"mid:99f7f42b-a051-46f0-9246-d2928ffb8d23@isocpp.org"
      type=3D"cite">
      <div>With this definition, it would make sense to believe that a
        default-initialized `Typename` would be in the `Type2` state.<br>
        <br>
        That would be a good example of elegant syntax: strong points of
        familiarity and a lack of surplus syntax.<br>
        <br>
        Now, compare that to what you want:<br>
        <br>
        <div class=3D"prettyprint" style=3D"background-color: rgb(250, 250,
          250); border-color: rgb(187, 187, 187); border-style: solid;
          border-width: 1px; word-wrap: break-word;"><code
            class=3D"prettyprint">
            <div class=3D"subprettyprint"><span style=3D"color: #008;"
                class=3D"styled-by-prettify">enum</span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span
                style=3D"color: #008;" class=3D"styled-by-prettify">union</=
span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span
                style=3D"color: #606;" class=3D"styled-by-prettify">Typenam=
e</span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"><br>
              </span><span style=3D"color: #660;"
                class=3D"styled-by-prettify">{</span><span style=3D"color:
                #000;" class=3D"styled-by-prettify"><br>
                =C2=A0 =C2=A0</span><span style=3D"color: #008;"
                class=3D"styled-by-prettify">struct</span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> name1 =
</span><span
                style=3D"color: #660;" class=3D"styled-by-prettify">{</span=
><span
                style=3D"color: #606;" class=3D"styled-by-prettify">Type1</=
span><span
                style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span
                style=3D"color: #660;" class=3D"styled-by-prettify">};</spa=
n><span
                style=3D"color: #000;" class=3D"styled-by-prettify"><br>
                =C2=A0 =C2=A0</span><span style=3D"color: #008;"
                class=3D"styled-by-prettify">struct</span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> name2 =
</span><span
                style=3D"color: #660;" class=3D"styled-by-prettify">{</span=
><span
                style=3D"color: #606;" class=3D"styled-by-prettify">Type2</=
span><span
                style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span
                style=3D"color: #660;" class=3D"styled-by-prettify">};</spa=
n><span
                style=3D"color: #000;" class=3D"styled-by-prettify"><br>
              </span><span style=3D"color: #660;"
                class=3D"styled-by-prettify">};</span></div>
          </code></div>
        <br>
      </div>
    </blockquote>
    In reality what I want is either to extend the enums having
    enumerations that have parameters<br>
    <br>
    <div class=3D"prettyprint" style=3D"background-color: rgb(250, 250,
      250); border-color: rgb(187, 187, 187); border-style: solid;
      border-width: 1px; word-wrap: break-word;"><code
        class=3D"prettyprint">
        <div class=3D"subprettyprint"><span style=3D"color: #008;"
            class=3D"styled-by-prettify">variantKeyword</span><span
            style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an
            style=3D"color: #606;" class=3D"styled-by-prettify">Typename</s=
pan><span
            style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an
            style=3D"color: #660;" class=3D"styled-by-prettify">{</span><sp=
an
            style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an
            style=3D"color: #000;" class=3D"styled-by-prettify">name1 </spa=
n><span
            style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an
            style=3D"color: #606;" class=3D"styled-by-prettify">Type1</span=
><span
            style=3D"color: #660;" class=3D"styled-by-prettify"></span><spa=
n
            style=3D"color: #000;" class=3D"styled-by-prettify">),</span><s=
pan
            style=3D"color: #660;" class=3D"styled-by-prettify"></span><spa=
n
            style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an
            style=3D"color: #000;" class=3D"styled-by-prettify">name2 </spa=
n><span
            style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an
            style=3D"color: #606;" class=3D"styled-by-prettify">Type2</span=
><span
            style=3D"color: #660;" class=3D"styled-by-prettify">)</span> <s=
pan
            style=3D"color: #660;" class=3D"styled-by-prettify">}; // enum
            like extension</span><br>
        </div>
      </code></div>
    <br>
    This is the minimum I can have. What I was proposing was using
    existing facilities that allow to us name1(v1). An the single one I
    find was a Type itself as the type constructor uses this syntax
    name1(v1) and we are really creating a new type that depends on
    name1.<br>
    <br>
    In order you see that the field names as used in P0095 are part of
    the type, lets see the case where we have the same type twice, but
    with different field names<br>
    <br>
    <div class=3D"prettyprint" style=3D"background-color: rgb(250, 250,
      250); border-color: rgb(187, 187, 187); border-style: solid;
      border-width: 1px; word-wrap: break-word;"><code
        class=3D"prettyprint">
        <div class=3D"subprettyprint"><span style=3D"color: #008;"
            class=3D"styled-by-prettify">enum</span><span style=3D"color:
            #000;" class=3D"styled-by-prettify"> </span><span
            style=3D"color: #008;" class=3D"styled-by-prettify">union</span=
><span
            style=3D"color: #000;" class=3D"styled-by-prettify"> A</span><s=
pan
            style=3D"color: #606;" class=3D"styled-by-prettify"></span><spa=
n
            style=3D"color: #000;" class=3D"styled-by-prettify"><br>
          </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
{</span><span
            style=3D"color: #000;" class=3D"styled-by-prettify"><br>
            =C2=A0 B</span><span style=3D"color: #000;"
            class=3D"styled-by-prettify"> c1</span><span style=3D"color:
            #660;" class=3D"styled-by-prettify">;</span><span
            style=3D"color: #000;" class=3D"styled-by-prettify"><br>
            =C2=A0 </span><span style=3D"color: #606;"
            class=3D"styled-by-prettify">B</span><span style=3D"color:
            #000;" class=3D"styled-by-prettify"> c2</span><span
            style=3D"color: #660;" class=3D"styled-by-prettify">;</span><sp=
an
            style=3D"color: #000;" class=3D"styled-by-prettify"><br>
          </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
};</span></div>
      </code></div>
    <br>
    You can then have <br>
    <br>
    B b;<br>
    A a =3D A::c1(b);<br>
    a =3D A::c2(b);<br>
    <br>
    Here we have always the same B value, but we have changed the
    selector. So the selector is part of the type. This is not the same
    that a field name of a struct or a union.<br>
    <br>
    switch (a) {<br>
    =C2=A0=C2=A0=C2=A0 case A::c1 x:<br>
    =C2=A0=C2=A0=C2=A0 case A::c2 x:<br>
    };<br>
    <br>
    Having <br>
    <br>
    <div class=3D"prettyprint" style=3D"background-color: rgb(250, 250,
      250); border-color: rgb(187, 187, 187); border-style: solid;
      border-width: 1px; word-wrap: break-word;"><code
        class=3D"prettyprint">
        <div class=3D"subprettyprint"><span style=3D"color: #008;"
            class=3D"styled-by-prettify">variantKeyword</span><span
            style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an
            style=3D"color: #000;" class=3D"styled-by-prettify">A</span><sp=
an
            style=3D"color: #606;" class=3D"styled-by-prettify"></span> <sp=
an
            style=3D"color: #660;" class=3D"styled-by-prettify">{</span><sp=
an
            style=3D"color: #000;" class=3D"styled-by-prettify">=C2=A0 c1(B=
),
            c2(B) </span><span style=3D"color: #660;"
            class=3D"styled-by-prettify">};</span></div>
      </code></div>
    <br>
    switch (a) {<br>
    =C2=A0=C2=A0=C2=A0 case A::c1(x):<br>
    =C2=A0=C2=A0=C2=A0 case A::c2(x):<br>
    };<br>
    <br>
    Is this better for you? If yes, choose you keyword.<br>
    <br>
    Or <br>
    <br>
    <div class=3D"prettyprint" style=3D"background-color: rgb(250, 250,
      250); border-color: rgb(187, 187, 187); border-style: solid;
      border-width: 1px; word-wrap: break-word;"><code
        class=3D"prettyprint">
        <div class=3D"subprettyprint"><span style=3D"color: #660;"
            class=3D"styled-by-prettify">variantKeeyword Type =3D
            name1(Type1) | name2(Type2);<br>
            <br>
          </span><br>
          inspect (a) {<br>
          =C2=A0=C2=A0=C2=A0 when A::c1(x):<br>
          =C2=A0=C2=A0=C2=A0 <code class=3D"prettyprint">when</code> A::c2(=
x):<br>
          };<br>
        </div>
      </code></div>
    <br>
    <blockquote
      cite=3D"mid:99f7f42b-a051-46f0-9246-d2928ffb8d23@isocpp.org"
      type=3D"cite">
      <div>Here, it takes more syntax to say the exact same thing. We
        have a repetition of the keyword `struct`. We have some internal
        braces that don't really need to be there for what we're doing.<br>
        <br>
        Also, it lacks familiarity with C++ rules. You're declaring a
        nested struct, but the members of that struct have no names. Not
        only that, you're declaring a nested struct, but never declaring
        variables of that struct's type, yet a variable is being created
        anyway. </div>
    </blockquote>
    No, we don't create a variable of each one of the alternatives.<br>
    <blockquote
      cite=3D"mid:99f7f42b-a051-46f0-9246-d2928ffb8d23@isocpp.org"
      type=3D"cite">
      <div>These are very new things for C++, so it lacks familiarity.<br>
        <br>
        In your `inspect` syntax, you refer to members, not by variable
        names, but by <i>typenames</i>. Which means that the conceptual
        name of the state comes before the <i>useful</i> type of that
        state. That is, `name1` happens before `Type1`. That's also very
        un-C++-ish.<br>
      </div>
    </blockquote>
    I don't want them to be members, as they aren't. I want the type to
    be A or B. <br>
    <blockquote
      cite=3D"mid:99f7f42b-a051-46f0-9246-d2928ffb8d23@isocpp.org"
      type=3D"cite">
      <div><br>
        If we were to apply that default initialization thing, what
        would that look like?<br>
        <br>
        <div class=3D"prettyprint" style=3D"background-color: rgb(250, 250,
          250); border-color: rgb(187, 187, 187); border-style: solid;
          border-width: 1px; word-wrap: break-word;"><code
            class=3D"prettyprint">
            <div class=3D"subprettyprint"><span style=3D"color: #008;"
                class=3D"styled-by-prettify">enum</span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span
                style=3D"color: #008;" class=3D"styled-by-prettify">union</=
span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span
                style=3D"color: #606;" class=3D"styled-by-prettify">Typenam=
e</span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"><br>
              </span><span style=3D"color: #660;"
                class=3D"styled-by-prettify">{</span><span style=3D"color:
                #000;" class=3D"styled-by-prettify"><br>
                =C2=A0 =C2=A0</span><span style=3D"color: #008;"
                class=3D"styled-by-prettify">struct</span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> name1 =
</span><span
                style=3D"color: #660;" class=3D"styled-by-prettify">{</span=
><span
                style=3D"color: #606;" class=3D"styled-by-prettify">Type1</=
span><span
                style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span
                style=3D"color: #660;" class=3D"styled-by-prettify">};</spa=
n><span
                style=3D"color: #000;" class=3D"styled-by-prettify"><br>
                =C2=A0 =C2=A0</span><span style=3D"color: #008;"
                class=3D"styled-by-prettify">struct</span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> name2 =
</span><span
                style=3D"color: #660;" class=3D"styled-by-prettify">{</span=
><span
                style=3D"color: #606;" class=3D"styled-by-prettify">Type2</=
span><span
                style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span
                style=3D"color: #660;" class=3D"styled-by-prettify">}</span=
><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span
                style=3D"color: #660;" class=3D"styled-by-prettify">=3D</sp=
an><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span
                style=3D"color: #660;" class=3D"styled-by-prettify">{...};<=
/span><span
                style=3D"color: #000;" class=3D"styled-by-prettify"><br>
              </span><span style=3D"color: #660;"
                class=3D"styled-by-prettify">};</span></div>
          </code></div>
        <br>
      </div>
    </blockquote>
    <br>
    But you could name the fields if you wanted, but their access would
    not be safe?<br>
    <br>
    <div class=3D"prettyprint" style=3D"background-color: rgb(250, 250,
      250); border-color: rgb(187, 187, 187); border-style: solid;
      border-width: 1px; word-wrap: break-word;"><code
        class=3D"prettyprint">
        <div class=3D"subprettyprint"><span style=3D"color: #008;"
            class=3D"styled-by-prettify">enum</span><span style=3D"color:
            #000;" class=3D"styled-by-prettify"> </span><span
            style=3D"color: #008;" class=3D"styled-by-prettify">union</span=
><span
            style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an
            style=3D"color: #606;" class=3D"styled-by-prettify">Typename</s=
pan><span
            style=3D"color: #000;" class=3D"styled-by-prettify"><br>
          </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
{</span><span
            style=3D"color: #000;" class=3D"styled-by-prettify"><br>
            =C2=A0 =C2=A0</span><span style=3D"color: #008;"
            class=3D"styled-by-prettify">struct</span><span style=3D"color:
            #000;" class=3D"styled-by-prettify"> name1 </span><span
            style=3D"color: #660;" class=3D"styled-by-prettify">{</span><sp=
an
            style=3D"color: #606;" class=3D"styled-by-prettify">Type1</span=
><span
            style=3D"color: #660;" class=3D"styled-by-prettify">;</span><sp=
an
            style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an
            style=3D"color: #660;" class=3D"styled-by-prettify">} x;</span>=
<span
            style=3D"color: #000;" class=3D"styled-by-prettify"><br>
            =C2=A0 =C2=A0</span><span style=3D"color: #008;"
            class=3D"styled-by-prettify">struct</span><span style=3D"color:
            #000;" class=3D"styled-by-prettify"> name2 </span><span
            style=3D"color: #660;" class=3D"styled-by-prettify">{</span><sp=
an
            style=3D"color: #606;" class=3D"styled-by-prettify">Type2</span=
><span
            style=3D"color: #660;" class=3D"styled-by-prettify">;</span><sp=
an
            style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an
            style=3D"color: #660;" class=3D"styled-by-prettify">}</span><sp=
an
            style=3D"color: #000;" class=3D"styled-by-prettify"> y</span><s=
pan
            style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><=
span
            style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an
            style=3D"color: #660;" class=3D"styled-by-prettify">{...};</spa=
n><span
            style=3D"color: #000;" class=3D"styled-by-prettify"><br>
          </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
};</span></div>
      </code></div>
    <br>
    This is not what I'm proposing, so I don't need to justify anything
    here.<br>
    <blockquote
      cite=3D"mid:99f7f42b-a051-46f0-9246-d2928ffb8d23@isocpp.org"
      type=3D"cite">
      <div>That looks even fishier, since you're supposed to use an
        initializer on a variable, not a type. Variables have <i>names</i>
        in C++, and your feature revolves entirely around unnamed
        variables. That's a *very* new thing for C++, so again, it lacks
        familiarity.<br>
        <br>
        What is your reason for claiming that your proposal, which
        involves unnamed variables and various other things, is more
        elegant?<br>
      </div>
    </blockquote>
    Resuming: P00095 make use of field names as been part of the
    alternative types. This is wrong IMO.<br>
    A variant needs selector to mean one type or another if we want to
    do pattern matching.<br>
    <br>
    E.g. in Pascal you have fist a selector and then depending on the
    selector you have something more specific.<br>
    <br>
    <meta charset=3D"utf-8">
    type paytype =3D (salaried,hourly);
    <br>
    var employee : record
    <br>
    id : integer;
    <br>
    dept: integer;
    <br>
    age : integer;
    <br>
    case payclass: paytype of=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=
=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 { selector }<br>
    salaried: (monthlyrate : real; startdate : integer); <br>
    hourly: (rateperhour : real; reghours : integer; overtime :
    integer); <br>
    end;<br>
    <br>
    <meta charset=3D"utf-8">
    employee.payclass:=3Dsalaried;
    <br>
    employee.monthlyrate:=3D575.0;
    <br>
    employee.startdate:=3D13085;
    <br>
    {this should bomb as there are no
    rateperhour, etc. because
    payclass=3Dsalaried}<br>
    <br>
    <br>
    Note that the fields that have a name are the fields that have a
    sens once we have the selector initialized. <br>
    In order to ensure that we don't have bombs, the better is to don't
    give access via the names.<br>
    <br>
    <br>
    Vicente<br>
  </body>
</html>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--------------000902030103060403090003--

.

------=_Part_789_1313887952.1450109704629
Content-Type: multipart/alternative;
 boundary="----=_Part_790_1919878843.1450109704630"

------=_Part_790_1919878843.1450109704630
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Looking back at the P0095 proposal, I made an assumption that it allowed=20
explicit access of members. That is, `v.s1` would give you the value in=20
that state; presumably, if no such value existed, it would throw.=20
Similarly, `v.s2 =3D ...` would set the state to the `s2` state.

Apparently, P0095 doesn't actually say any of that. Even though it used, as=
=20
one of its main justifications, an explicit analogy between language=20
variants and structs compared to their library equivalents.

*However*, P0095's syntax could easily allow such constructs. Whereas your=
=20
(initial) suggested syntax does not.

On Monday, December 14, 2015 at 1:25:58 AM UTC-5, Vicente J. Botet Escriba=
=20
wrote:
>
> Le 13/12/2015 19:21, Nicol Bolas a =C3=A9crit :
>
> On Sunday, December 13, 2015 at 6:15:15 AM UTC-5, Vicente J. Botet Escrib=
a=20
> wrote:=20
>>
>> Le 13/12/2015 10:17, Nicol Bolas a =C3=A9crit :
>>
> The overall result is far more cumbersome than the P0095 method.=20
>>
>> What do you find is cumbersome?  The use of a field name to be used as a=
=20
>> type constructor and as a type matching don't seems to me the best thing=
..
>>
>
> Using a variable name as what appears to be the typename in a variable=20
> declaration is odd. Your way is far more odd, in that it requires a whole=
=20
> new bit of syntax, with its own keywords and everything. Not to mention=
=20
> needing to be able to create variables that have no names. That's *far*=
=20
> more odd than anything P0095 proposes.
>
> You can have parameters that have no name because you don't use them. Her=
e=20
> is the same. We don't use the field name, we have just a field type, so w=
hy=20
> to give them a name?
>

Because we already have nested type definitions that *don't* declare=20
unnamed variables. Consider this:

struct Outer
{
  struct Inner {int x};
  struct Inner2 {int x} v;
};

How many NSDMs does `Outer` have? One. It has two nested types, but only=20
one NSDM of that type.

Your plan has struct declarations creating actual NSDMs within their=20
contained types *without* having an explicit variable name. This makes your=
=20
variant type declarations work very differently from regular type=20
declarations (struct/class/union).

> With the exception of the use of `enum` rather than having its own=20
> keyword, there is no superfluous syntax present. So this is the minimum=
=20
> possible syntax for communicating the idea that this type is trying to=20
> communicate.
>
> Furthermore, it follows the traditional rules of C++ with regard to=20
> syntax, member variable declarations, and so forth. It looks like normal=
=20
> C++ code. Indeed, you could easily understand what this would mean:
>
> enum union Typename
> {
>   Type1 name1;
>   Type2 name2 =3D {...};
> };
>
> I don't buy that. This could means the default value for name2, not the=
=20
> default for Typename.
>
> But what does mean the following
>
> Typename v;
> v.name1 =3D1,
> f(v.name2);
>

If P0095 did provide such functionality, then it would simply throw some=20
form of runtime exception. It would be no different from doing this with a=
=20
variant type:

variant<Type1, Type2> v;
v.assign(inplace_t<1>(), 1);
f(get<2>(v));

That's the analogy between language-variants and structs: ease of member=20
access vs. ease of template metaprogrammability. The named language=20
constructs make member access easy. While the library constructs make=20
metaprogramming with them easy.

P0095 doesn't provide this, but the syntax it relies on *could* (and=20
should) provide it. Your idea seems to sacrifice ease of member access to=
=20
gain... what, exactly?

This is what we usually have when we have fields names, we use them to set=
=20
> a value and to obtain it.
> I don't want a union, I want a variant.=20
>

> With this definition, it would make sense to believe that a=20
> default-initialized `Typename` would be in the `Type2` state.
>
> That would be a good example of elegant syntax: strong points of=20
> familiarity and a lack of surplus syntax.
>
> Now, compare that to what you want:
>
> enum union Typename
> {
>    struct name1 {Type1; };
>    struct name2 {Type2; };
> };
>
> In reality what I want is either to extend the enums having enumerations=
=20
> that have parameters
>
> variantKeyword Typename { name1 (Type1), name2 (Type2) }; // enum like=20
> extension
>
> This is the minimum I can have.
>

Then why didn't you *start with that?* Why all the rigmarole about unnamed=
=20
struct members and nested struct declarations and so forth?

You're already proposing new syntax, so you may as well propose the syntax=
=20
you actually want. Compromises should come later.

Having=20
>
> variantKeyword A {  c1(B), c2(B) };
>
> switch (a) {
>     case A::c1(x):
>     case A::c2(x):
> };
>
> Is this better for you?
>

So, how do you access the value? Is it `a.c1`? If so, you haven't really=20
solved the problem, since `c1` acts as both a typename (in your view) and=
=20
as a member name.

And if you can't access the state by name like that, if the only way to=20
access the data is to use a switch statement, then what's the point of=20
putting the variant into the language at all?

It's not clear what `c1` actually is. Is it a typename? Is it legal to do=
=20
`using v =3D A::c1;`?

If yes, choose you keyword.
>
> Or=20
>
> variantKeeyword Type =3D name1(Type1) | name2(Type2);
>
>
> inspect (a) {
>     when A::c1(x):
>     when A::c2(x):
> };
>
> That looks even fishier, since you're supposed to use an initializer on a=
=20
> variable, not a type. Variables have *names* in C++, and your feature=20
> revolves entirely around unnamed variables. That's a *very* new thing for=
=20
> C++, so again, it lacks familiarity.
>
> What is your reason for claiming that your proposal, which involves=20
> unnamed variables and various other things, is more elegant?
>
> Resuming: P00095 make use of field names as been part of the alternative=
=20
> types. This is wrong IMO.
> A variant needs selector to mean one type or another if we want to do=20
> pattern matching.
>

No. A variant needs the selector to mean one *state* or another. Whether=20
that state has a distinct typename from another state is irrelevant. States=
=20
have types, but there's nothing that requires those types to be different.=
=20
That's a requirement you're inventing, not one that's actually there. P0088=
=20
variants allow using the type as a state name, but the primary state name=
=20
is an integer.

In P0095, the state is a member variable name, just like with unions. In=20
your idea, the state is a typename.

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<div dir=3D"ltr">Looking back at the P0095 proposal, I made an assumption t=
hat it allowed explicit access of members. That is, `v.s1` would give you t=
he value in that state; presumably, if no such value existed, it would thro=
w. Similarly, `v.s2 =3D ...` would set the state to the `s2` state.<br><br>=
Apparently, P0095 doesn&#39;t actually say any of that. Even though it used=
, as one of its main justifications, an explicit analogy between language v=
ariants and structs compared to their library equivalents.<br><br><i>Howeve=
r</i>, P0095&#39;s syntax could easily allow such constructs. Whereas your =
(initial) suggested syntax does not.<br><br>On Monday, December 14, 2015 at=
 1:25:58 AM UTC-5, Vicente J. Botet Escriba wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;">
 =20
   =20
 =20
  <div text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div>Le 13/12/2015 19:21, Nicol Bolas a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite">On Sunday, December 13, 2015 at 6:15:15 AM UT=
C-5,
      Vicente J. Botet Escriba wrote:
      <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex">
        <div text=3D"#000000" bgcolor=3D"#FFFFFF">
          <div>Le 13/12/2015 10:17, Nicol Bolas a =C3=A9crit=C2=A0:<br>
          </div></div></blockquote></blockquote>
   =20
    <blockquote type=3D"cite">
      <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex">
        <div text=3D"#000000" bgcolor=3D"#FFFFFF">
          <blockquote type=3D"cite">The overall result is far more
            cumbersome than the P0095 method. </blockquote>
          What do you find is cumbersome?=C2=A0 The use of a field name to =
be
          used as a type constructor and as a type matching don&#39;t seems
          to me the best thing.</div>
      </blockquote>
      <div><br>
        Using a variable name as what appears to be the typename in a
        variable declaration is odd. Your way is far more odd, in that
        it requires a whole new bit of syntax, with its own keywords and
        everything. Not to mention needing to be able to create
        variables that have no names. That&#39;s <i>far</i> more odd than
        anything P0095 proposes.<br>
      </div>
    </blockquote>
    You can have parameters that have no name because you don&#39;t use
    them. Here is the same. We don&#39;t use the field name, we have just a
    field type, so why to give them a name?</div></blockquote><div><br>Beca=
use we already have nested type definitions that <i>don&#39;t</i> declare u=
nnamed variables. Consider this:<br><br><div class=3D"prettyprint" style=3D=
"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bo=
rder-style: solid; border-width: 1px; word-wrap: break-word;"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"sty=
led-by-prettify">Outer</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">st=
ruct</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #606;" class=3D"styled-by-prettify">Inner</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> x</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">struct</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pretti=
fy">Inner2</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> v</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span></div></code></div><br>How many NSDMs does `Outer` have? One. =
It has two nested types, but only one NSDM of that type.<br><br>Your plan h=
as struct declarations creating actual NSDMs within their contained types <=
i>without</i> having an explicit variable name. This makes your variant typ=
e declarations work very differently from regular type declarations (struct=
/class/union).<br></div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div t=
ext=3D"#000000" bgcolor=3D"#FFFFFF">
    <blockquote type=3D"cite">
      <div>
        With the exception of the use of `enum` rather than having its
        own keyword, there is no superfluous syntax present. So this is
        the minimum possible syntax for communicating the idea that this
        type is trying to communicate.<br>
        <br>
        Furthermore, it follows the traditional rules of C++ with regard
        to syntax, member variable declarations, and so forth. It looks
        like normal C++ code. Indeed, you could easily understand what
        this would mean:<br>
        <br>
        <div style=3D"background-color:rgb(250,250,250);border-color:rgb(18=
7,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><code>
            <div><span style=3D"color:#008">enum</span><span style=3D"color=
:#000"> </span><span style=3D"color:#008">union</span><span style=3D"color:=
#000"> </span><span style=3D"color:#606">Typename</span><span style=3D"colo=
r:#000"><br>
              </span><span style=3D"color:#660">{</span><span style=3D"colo=
r:#000"><br>
                =C2=A0 </span><span style=3D"color:#606">Type1</span><span =
style=3D"color:#000"> name1</span><span style=3D"color:#660">;</span><span =
style=3D"color:#000"><br>
                =C2=A0 </span><span style=3D"color:#606">Type2</span><span =
style=3D"color:#000"> name2 </span><span style=3D"color:#660">=3D</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#660">{...};</span><sp=
an style=3D"color:#000"><br>
              </span><span style=3D"color:#660">};</span></div>
          </code></div>
        <br>
      </div>
    </blockquote>
    I don&#39;t buy that. This could means the default value for name2, not
    the default for Typename.<br>
    <br>
    But what does mean the following<br>
    <br>
    Typename v;<br>
    v.name1 =3D1,<br>
    f(v.name2);<br></div></blockquote><div><br>If P0095 did provide such fu=
nctionality, then it would simply throw some form of runtime exception. It =
would be no different from doing this with a variant type:<br><br><div clas=
s=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-col=
or: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: =
break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">variant</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Type1</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Type2</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> v</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
v</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">assign</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">inplace_t</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color:=
 #066;" class=3D"styled-by-prettify">1</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">&gt;(),</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styl=
ed-by-prettify">1</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>f</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">get</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">2</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">&gt;(</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">v</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">));</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span></div></code></div><br>That&#39;s the analogy b=
etween language-variants and structs: ease of member access vs. ease of tem=
plate metaprogrammability. The named language constructs make member access=
 easy. While the library constructs make metaprogramming with them easy.<br=
><br>P0095 doesn&#39;t provide this, but the syntax it relies on <i>could</=
i> (and should) provide it. Your idea seems to sacrifice ease of member acc=
ess to gain... what, exactly?<br><br></div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;"><div>
   =20
    This is what we usually have when we have fields names, we use them
    to set a value and to obtain it.<br>
    I don&#39;t want a union, I want a variant.=C2=A0</div></blockquote><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div text=3D"#000000" bgcolor=3D"=
#FFFFFF">
    <br>
    <blockquote type=3D"cite">
      <div>With this definition, it would make sense to believe that a
        default-initialized `Typename` would be in the `Type2` state.<br>
        <br>
        That would be a good example of elegant syntax: strong points of
        familiarity and a lack of surplus syntax.<br>
        <br>
        Now, compare that to what you want:<br>
        <br>
        <div style=3D"background-color:rgb(250,250,250);border-color:rgb(18=
7,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><code>
            <div><span style=3D"color:#008">enum</span><span style=3D"color=
:#000"> </span><span style=3D"color:#008">union</span><span style=3D"color:=
#000"> </span><span style=3D"color:#606">Typename</span><span style=3D"colo=
r:#000"><br>
              </span><span style=3D"color:#660">{</span><span style=3D"colo=
r:#000"><br>
                =C2=A0 =C2=A0</span><span style=3D"color:#008">struct</span=
><span style=3D"color:#000"> name1 </span><span style=3D"color:#660">{</spa=
n><span style=3D"color:#606">Type1</span><span style=3D"color:#660">;</span=
><span style=3D"color:#000"> </span><span style=3D"color:#660">};</span><sp=
an style=3D"color:#000"><br>
                =C2=A0 =C2=A0</span><span style=3D"color:#008">struct</span=
><span style=3D"color:#000"> name2 </span><span style=3D"color:#660">{</spa=
n><span style=3D"color:#606">Type2</span><span style=3D"color:#660">;</span=
><span style=3D"color:#000"> </span><span style=3D"color:#660">};</span><sp=
an style=3D"color:#000"><br>
              </span><span style=3D"color:#660">};</span></div>
          </code></div>
        <br>
      </div>
    </blockquote>
    In reality what I want is either to extend the enums having
    enumerations that have parameters<br>
    <br>
    <div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,18=
7,187);border-style:solid;border-width:1px;word-wrap:break-word"><code>
        <div><span style=3D"color:#008">variantKeyword</span><span style=3D=
"color:#000"> </span><span style=3D"color:#606">Typename</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">{</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#000">name1 </span><span style=3D"c=
olor:#660">(</span><span style=3D"color:#606">Type1</span><span style=3D"co=
lor:#660"></span><span style=3D"color:#000">),</span><span style=3D"color:#=
660"></span><span style=3D"color:#000"> </span><span style=3D"color:#000">n=
ame2 </span><span style=3D"color:#660">(</span><span style=3D"color:#606">T=
ype2</span><span style=3D"color:#660">)</span> <span style=3D"color:#660">}=
; // enum
            like extension</span><br>
        </div>
      </code></div>
    <br>
    This is the minimum I can have.</div></blockquote><div><br>Then why did=
n&#39;t you <i>start with that?</i> Why all the rigmarole about unnamed str=
uct members and nested struct declarations and so forth?<br><br>You&#39;re =
already proposing new syntax, so you may as well propose the syntax you act=
ually want. Compromises should come later.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div text=3D"#000000" bgcolor=3D"#FFFFFF">
    Having <br>
    <br>
    <div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,18=
7,187);border-style:solid;border-width:1px;word-wrap:break-word"><code>
        <div><span style=3D"color:#008">variantKeyword</span><span style=3D=
"color:#000"> </span><span style=3D"color:#000">A</span><span style=3D"colo=
r:#606"></span> <span style=3D"color:#660">{</span><span style=3D"color:#00=
0">=C2=A0 c1(B),
            c2(B) </span><span style=3D"color:#660">};</span></div>
      </code></div>
    <br>
    switch (a) {<br>
    =C2=A0=C2=A0=C2=A0 case A::c1(x):<br>
    =C2=A0=C2=A0=C2=A0 case A::c2(x):<br>
    };<br>
    <br>
    Is this better for you?</div></blockquote><div><br>So, how do you acces=
s the value? Is it `a.c1`? If so, you haven&#39;t really solved the problem=
, since `c1` acts as both a typename (in your view) and as a member name.<b=
r><br>And if you can&#39;t access the state by name like that, if the only =
way to access the data is to use a switch statement, then what&#39;s the po=
int of putting the variant into the language at all?<br><br>It&#39;s not cl=
ear what `c1` actually is. Is=20
it a typename? Is it legal to do `using v =3D A::c1;`?<br><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div text=3D"#000000" bgcolor=3D"#FFF=
FFF">If yes, choose you keyword.<br>
    <br>
    Or <br>
    <br>
    <div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,18=
7,187);border-style:solid;border-width:1px;word-wrap:break-word"><code>
        <div><span style=3D"color:#660">variantKeeyword Type =3D
            name1(Type1) | name2(Type2);<br>
            <br>
          </span><br>
          inspect (a) {<br>
          =C2=A0=C2=A0=C2=A0 when A::c1(x):<br>
          =C2=A0=C2=A0=C2=A0 <code>when</code> A::c2(x):<br>
          };<br>
        </div>
      </code></div>
    <blockquote type=3D"cite">
      <div>That looks even fishier, since you&#39;re supposed to use an
        initializer on a variable, not a type. Variables have <i>names</i>
        in C++, and your feature revolves entirely around unnamed
        variables. That&#39;s a *very* new thing for C++, so again, it lack=
s
        familiarity.<br>
        <br>
        What is your reason for claiming that your proposal, which
        involves unnamed variables and various other things, is more
        elegant?<br>
      </div>
    </blockquote>
    Resuming: P00095 make use of field names as been part of the
    alternative types. This is wrong IMO.<br>
    A variant needs selector to mean one type or another if we want to
    do pattern matching.<br></div></blockquote><div><br>No. A variant needs=
 the selector to mean one <b><i>state</i></b> or another. Whether that stat=
e has a distinct typename from another state is irrelevant. States have typ=
es, but there&#39;s nothing that requires those types to be different. That=
&#39;s a requirement you&#39;re inventing, not one that&#39;s actually ther=
e. P0088 variants allow using the type as a state name, but the primary sta=
te name is an integer.<br><br>In P0095, the state is a member variable name=
, just like with unions. In your idea, the state is a typename.<br></div></=
div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_790_1919878843.1450109704630--
------=_Part_789_1313887952.1450109704629--

.

This is a multi-part message in MIME format.
--------------090106010806080405060906
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 14/12/2015 17:15, Nicol Bolas a =C3=A9crit :
> Looking back at the P0095 proposal, I made an assumption that it=20
> allowed explicit access of members. That is, `v.s1` would give you the=20
> value in that state; presumably, if no such value existed, it would=20
> throw. Similarly, `v.s2 =3D ...` would set the state to the `s2` state.
Hmm, assigning to a data member would change something else than the=20
member. There is no such thing in the C++ language yet. I recognize that=20
the syntax is terse,

     v.s2 =3D x;

but I could live with that

     v=3D S::s2(x);
>
> Apparently, P0095 doesn't actually say any of that. Even though it=20
> used, as one of its main justifications, an explicit analogy between=20
> language variants and structs compared to their library equivalents.
>
> /However/, P0095's syntax could easily allow such constructs. Whereas=20
> your (initial) suggested syntax does not.
>
Please, forget my initial suggestion. I suggest we move to my last=20
suggestion :)

If you want to have access to the fields you need a way to check which=20
one is active. While your suggestion to throw an exception is a=20
possibility I don't know of other data member access that throws in the=20
language. We could also use some kind of index() and have let the data=20
member access undefined if not active, but this is not safe.

One of the advantages for me introducing the variant in the language is=20
that visitation(matching) shouldn't be less efficient that using index=20
and alternative access.

We are in C++ world, maybe we want to provide some terse syntax. I would=20
prefer not, but I will not be strongly against.

> On Monday, December 14, 2015 at 1:25:58 AM UTC-5, Vicente J. Botet=20
> Escriba wrote:
>
>     Le 13/12/2015 19:21, Nicol Bolas a =C3=A9crit :
>>     On Sunday, December 13, 2015 at 6:15:15 AM UTC-5, Vicente J.
>>     Botet Escriba wrote:
>>
>>         Le 13/12/2015 10:17, Nicol Bolas a =C3=A9crit :
>>
>>>         The overall result is far more cumbersome than the P0095
>>>         method.=20
>>         What do you find is cumbersome?  The use of a field name to
>>         be used as a type constructor and as a type matching don't
>>         seems to me the best thing.
>>
>>
>>     Using a variable name as what appears to be the typename in a
>>     variable declaration is odd. Your way is far more odd, in that it
>>     requires a whole new bit of syntax, with its own keywords and
>>     everything. Not to mention needing to be able to create variables
>>     that have no names. That's /far/ more odd than anything P0095
>>     proposes.
>     You can have parameters that have no name because you don't use
>     them. Here is the same. We don't use the field name, we have just
>     a field type, so why to give them a name?
>
>
> Because we already have nested type definitions that /don't/ declare=20
> unnamed variables. Consider this:
>
> |
> structOuter
> {
> structInner{intx};
> structInner2{intx}v;
> };
> |
>
Good point. This kills my initial suggestion.
> How many NSDMs does `Outer` have? One. It has two nested types, but=20
> only one NSDM of that type.
>
> Your plan has struct declarations creating actual NSDMs within their=20
> contained types /without/ having an explicit variable name. This makes=20
> your variant type declarations work very differently from regular type=20
> declarations (struct/class/union).
>
>>     With the exception of the use of `enum` rather than having its
>>     own keyword, there is no superfluous syntax present. So this is
>>     the minimum possible syntax for communicating the idea that this
>>     type is trying to communicate.
>>
>>     Furthermore, it follows the traditional rules of C++ with regard
>>     to syntax, member variable declarations, and so forth. It looks
>>     like normal C++ code. Indeed, you could easily understand what
>>     this would mean:
>>
>>     |
>>     enumunionTypename
>>     {
>>     Type1name1;
>>     Type2name2 =3D{...};
>>     };
>>     |
>>
>     I don't buy that. This could means the default value for name2,
>     not the default for Typename.
>
>     But what does mean the following
>
>     Typename v;
>     v.name1 =3D1,
>     f(v.name2);
>
>
> If P0095 did provide such functionality, then it would simply throw=20
> some form of runtime exception. It would be no different from doing=20
> this with a variant type:
>
> |
> variant<Type1,Type2>v;
> v.assign(inplace_t<1>(),1);
> f(get<2>(v));
> |
>
> That's the analogy between language-variants and structs: ease of=20
> member access vs. ease of template metaprogrammability. The named=20
> language constructs make member access easy. While the library=20
> constructs make metaprogramming with them easy.
For the time being the proposal doesn't include member access, neither=20
to assign or get them. David?
I would prefer to don't provide such terse syntax. I could however admit=20
it. Could it be more efficient than the alternative

v =3D Typename::name1(1);

switch (v) {
     case Typename::name2(x): f(x);
};


>
> P0095 doesn't provide this, but the syntax it relies on /could/ (and=20
> should) provide it. Your idea seems to sacrifice ease of member access=20
> to gain... what, exactly?
I must recognize that as P0095 I have not though about that. Now that=20
you talk, I believe that we can consider the use case. I believe my last=20
generalized enum suggestion could adapt provide a terse syntax. Anyway=20
we don't have it in P0095.
>
>     This is what we usually have when we have fields names, we use
>     them to set a value and to obtain it.
>     I don't want a union, I want a variant.
>
>
>>     With this definition, it would make sense to believe that a
>>     default-initialized `Typename` would be in the `Type2` state.
>>
>>     That would be a good example of elegant syntax: strong points of
>>     familiarity and a lack of surplus syntax.
>>
>>     Now, compare that to what you want:
>>
>>     |
>>     enumunionTypename
>>     {
>>     structname1 {Type1;};
>>     structname2 {Type2;};
>>     };
>>     |
>>
>     In reality what I want is either to extend the enums having
>     enumerations that have parameters
>
>     |
>     variantKeywordTypename{name1 (Type1),name2 (Type2) }; // enum like
>     extension
>     |
>
>     This is the minimum I can have.
>
>
> Then why didn't you /start with that?/ Why all the rigmarole about=20
> unnamed struct members and nested struct declarations and so forth?
I don't know :(  name1, name2 seem like symbolic functional terms and=20
wrapping types was quite close to this.
>
> You're already proposing new syntax, so you may as well propose the=20
> syntax you actually want. Compromises should come later.
>
>     Having
>
>     |
>     variantKeywordA{  c1(B), c2(B) };
>     |
>
>     switch (a) {
>         case A::c1(x):
>         case A::c2(x):
>     };
>
>     Is this better for you?
>
>
> So, how do you access the value? Is it `a.c1`?
I'm not proposing direct access. Access is done by pattern matching.=20
This is in line with P0095.

However, as c1 signature is

c1(B) -> A

The inverse function signature is

~c1(1) ->B

Your a.c1 suggestion would have the following inverse signature

c1(A) -> B

Allowing a.c1 would mean that we use the same name for the inverse function=
..

We could use A::~c1(a) or a.~c1.

And as the syntax is not ambiguous the more terse syntax a.c1.

Compare the following variant type using P0095 and my last proposal

struct unit{};

enum union E {
     unit c1;
     unit c2;
};

variantKeyword E { c1(unit), c2(unit) };

When the type stored is a unit type like unit we can make abstraction of=20
it and remove it

variantKeyword E { c1, c2 };

and this is exactly the same as an enum

enum class E { c1, c2 };

> If so, you haven't really solved the problem, since `c1` acts as both=20
> a typename (in your view) and as a member name.
>
You are right. My original suggestion using structs doesn't works well=20
if this use case must be taken in account. I would say that we are using=20
c1 to mean two things, the injection and the partial projection.
> And if you can't access the state by name like that, if the only way=20
> to access the data is to use a switch statement, then what's the point=20
> of putting the variant into the language at all?
It is up to us to decide if we want direct access or not. I don't see a=20
problem don't providing it as I could admit that in a C++ world the=20
access you are proposing could be what the user expects. This is a=20
question not related to my suggestion, but to P0095 author and supporters.
>
> It's not clear what `c1` actually is. Is it a typename? Is it legal to=20
> do `using v =3D A::c1;`?

Good question. No, it is not a type on the last suggested syntax. It is=20
something new.
>
>     If yes, choose you keyword.
>
>     Or
>
>     |
>     variantKeeyword Type =3D name1(Type1) | name2(Type2);
>
>
>     inspect (a) {
>         when A::c1(x):
>     |when| A::c2(x):
>     };
>     |
>>     That looks even fishier, since you're supposed to use an
>>     initializer on a variable, not a type. Variables have /names/ in
>>     C++, and your feature revolves entirely around unnamed variables.
>>     That's a *very* new thing for C++, so again, it lacks familiarity.
>>
>>     What is your reason for claiming that your proposal, which
>>     involves unnamed variables and various other things, is more elegant=
?
>     Resuming: P00095 make use of field names as been part of the
>     alternative types. This is wrong IMO.
>     A variant needs selector to mean one type or another if we want to
>     do pattern matching.
>
>
> No. A variant needs the selector to mean one */state/* or another.=20
> Whether that state has a distinct typename from another state is=20
> irrelevant. States have types, but there's nothing that requires those=20
> types to be different. That's a requirement you're inventing, not one=20
> that's actually there. P0088 variants allow using the type as a state=20
> name, but the primary state name is an integer.
I don't understand the last sentence.
>
> In P0095, the state is a member variable name, just like with unions.=20
> In your idea, the state is a typename.
>
I'm not thinking in terms of state, but I'm trying to think in terms of=20
types, functions and values (Maths).

name1, name2 behave in some way as symbolic enumerations that are=20
different as in

|enum class E { name1 , name2  };

E e;

switch (e) {
     case name1: ...
     case name2: ...
};


What are name1, name2? types? functions? values?

When I write

enum E {name1(Type1), name2(Type2) };


We can see them as functions that transform the T in another different=20
type, as soon as name1(T) and name2(T) are different types.

     name1(Type1) | name2(Type2)

We can see them as values (name1, name2 are different values)

    {name1}xType1 | {name2}xType2

We can see name1 as a single unit type with a single element name1{}

    name1xType1 | name2xType2

When Type1 and Type2 are the same type, it is this symbolic names name1,=20
name2 that makes the difference.

I like the function view.


I believe we need to state clearly how the variant can be used. Your=20
direct access is a good example. P0095 don't talk neither of=20
constructors, except for the default constructor. Do we want to be able=20
to add constructors other? Other member operations? I don't believe we=20
want. Maybe others have some examples where adding other members=20
functions make the code clearer.

||Vicente||

P.S. Apologies if I'm often not clear enough.
|

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 14/12/2015 17:15, Nicol Bolas a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:c709ec06-3cff-485d-b6a1-6a2c62d4cc78@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">Looking back at the P0095 proposal, I made an
        assumption that it allowed explicit access of members. That is,
        `v.s1` would give you the value in that state; presumably, if no
        such value existed, it would throw. Similarly, `v.s2 =3D ...`
        would set the state to the `s2` state.<br>
      </div>
    </blockquote>
    Hmm, assigning to a data member would change something else than the
    member. There is no such thing in the C++ language yet. I recognize
    that the syntax is terse, <br>
    <br>
    =C2=A0=C2=A0=C2=A0 v.s2 =3D x;<br>
    <br>
    but I could live with that<br>
    <br>
    =C2=A0=C2=A0=C2=A0 v=3D S::s2(x);<br>
    <blockquote
      cite=3D"mid:c709ec06-3cff-485d-b6a1-6a2c62d4cc78@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr"><br>
        Apparently, P0095 doesn't actually say any of that. Even though
        it used, as one of its main justifications, an explicit analogy
        between language variants and structs compared to their library
        equivalents.<br>
        <br>
        <i>However</i>, P0095's syntax could easily allow such
        constructs. Whereas your (initial) suggested syntax does not.<br>
        <br>
      </div>
    </blockquote>
    Please, forget my initial suggestion. I suggest we move to my last
    suggestion :) <br>
    <br>
    If you want to have access to the fields you need a way to check
    which one is active. While your suggestion to throw an exception is
    a possibility I don't know of other data member access that throws
    in the language. We could also use some kind of index() and have let
    the data member access undefined if not active, but this is not
    safe.<br>
    <br>
    One of the advantages for me introducing the variant in the language
    is that visitation(matching) shouldn't be less efficient that using
    index and alternative access.<br>
    <br>
    We are in C++ world, maybe we want to provide some terse syntax. I
    would prefer not, but I will not be strongly against.<br>
    <br>
    <blockquote
      cite=3D"mid:c709ec06-3cff-485d-b6a1-6a2c62d4cc78@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">On Monday, December 14, 2015 at 1:25:58 AM UTC-5,
        Vicente J. Botet Escriba wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div text=3D"#000000" bgcolor=3D"#FFFFFF">
            <div>Le 13/12/2015 19:21, Nicol Bolas a =C3=A9crit=C2=A0:<br>
            </div>
            <blockquote type=3D"cite">On Sunday, December 13, 2015 at
              6:15:15 AM UTC-5, Vicente J. Botet Escriba wrote:
              <blockquote class=3D"gmail_quote"
                style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
                solid;padding-left:1ex">
                <div text=3D"#000000" bgcolor=3D"#FFFFFF">
                  <div>Le 13/12/2015 10:17, Nicol Bolas a =C3=A9crit=C2=A0:=
<br>
                  </div>
                </div>
              </blockquote>
            </blockquote>
            <blockquote type=3D"cite">
              <blockquote class=3D"gmail_quote"
                style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
                solid;padding-left:1ex">
                <div text=3D"#000000" bgcolor=3D"#FFFFFF">
                  <blockquote type=3D"cite">The overall result is far more
                    cumbersome than the P0095 method. </blockquote>
                  What do you find is cumbersome?=C2=A0 The use of a field
                  name to be used as a type constructor and as a type
                  matching don't seems to me the best thing.</div>
              </blockquote>
              <div><br>
                Using a variable name as what appears to be the typename
                in a variable declaration is odd. Your way is far more
                odd, in that it requires a whole new bit of syntax, with
                its own keywords and everything. Not to mention needing
                to be able to create variables that have no names.
                That's <i>far</i> more odd than anything P0095
                proposes.<br>
              </div>
            </blockquote>
            You can have parameters that have no name because you don't
            use them. Here is the same. We don't use the field name, we
            have just a field type, so why to give them a name?</div>
        </blockquote>
        <div><br>
          Because we already have nested type definitions that <i>don't</i>
          declare unnamed variables. Consider this:<br>
          <br>
          <div class=3D"prettyprint" style=3D"background-color: rgb(250,
            250, 250); border-color: rgb(187, 187, 187); border-style:
            solid; border-width: 1px; word-wrap: break-word;"><code
              class=3D"prettyprint">
              <div class=3D"subprettyprint"><span style=3D"color: #008;"
                  class=3D"styled-by-prettify">struct</span><span
                  style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
                  style=3D"color: #606;" class=3D"styled-by-prettify">Outer=
</span><span
                  style=3D"color: #000;" class=3D"styled-by-prettify"><br>
                </span><span style=3D"color: #660;"
                  class=3D"styled-by-prettify">{</span><span style=3D"color=
:
                  #000;" class=3D"styled-by-prettify"><br>
                  =C2=A0 </span><span style=3D"color: #008;"
                  class=3D"styled-by-prettify">struct</span><span
                  style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
                  style=3D"color: #606;" class=3D"styled-by-prettify">Inner=
</span><span
                  style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
                  style=3D"color: #660;" class=3D"styled-by-prettify">{</sp=
an><span
                  style=3D"color: #008;" class=3D"styled-by-prettify">int</=
span><span
                  style=3D"color: #000;" class=3D"styled-by-prettify"> x</s=
pan><span
                  style=3D"color: #660;" class=3D"styled-by-prettify">};</s=
pan><span
                  style=3D"color: #000;" class=3D"styled-by-prettify"><br>
                  =C2=A0 </span><span style=3D"color: #008;"
                  class=3D"styled-by-prettify">struct</span><span
                  style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
                  style=3D"color: #606;" class=3D"styled-by-prettify">Inner=
2</span><span
                  style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
                  style=3D"color: #660;" class=3D"styled-by-prettify">{</sp=
an><span
                  style=3D"color: #008;" class=3D"styled-by-prettify">int</=
span><span
                  style=3D"color: #000;" class=3D"styled-by-prettify"> x</s=
pan><span
                  style=3D"color: #660;" class=3D"styled-by-prettify">}</sp=
an><span
                  style=3D"color: #000;" class=3D"styled-by-prettify"> v</s=
pan><span
                  style=3D"color: #660;" class=3D"styled-by-prettify">;</sp=
an><span
                  style=3D"color: #000;" class=3D"styled-by-prettify"><br>
                </span><span style=3D"color: #660;"
                  class=3D"styled-by-prettify">};</span><span
                  style=3D"color: #000;" class=3D"styled-by-prettify"><br>
                </span></div>
            </code></div>
          <br>
        </div>
      </div>
    </blockquote>
    Good point. This kills my initial suggestion.<br>
    <blockquote
      cite=3D"mid:c709ec06-3cff-485d-b6a1-6a2c62d4cc78@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>How many NSDMs does `Outer` have? One. It has two nested
          types, but only one NSDM of that type.<br>
          <br>
          Your plan has struct declarations creating actual NSDMs within
          their contained types <i>without</i> having an explicit
          variable name. This makes your variant type declarations work
          very differently from regular type declarations
          (struct/class/union).<br>
        </div>
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div text=3D"#000000" bgcolor=3D"#FFFFFF">
            <blockquote type=3D"cite">
              <div> With the exception of the use of `enum` rather than
                having its own keyword, there is no superfluous syntax
                present. So this is the minimum possible syntax for
                communicating the idea that this type is trying to
                communicate.<br>
                <br>
                Furthermore, it follows the traditional rules of C++
                with regard to syntax, member variable declarations, and
                so forth. It looks like normal C++ code. Indeed, you
                could easily understand what this would mean:<br>
                <br>
                <div
style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);bo=
rder-style:solid;border-width:1px;word-wrap:break-word"><code>
                    <div><span style=3D"color:#008">enum</span><span
                        style=3D"color:#000"> </span><span
                        style=3D"color:#008">union</span><span
                        style=3D"color:#000"> </span><span
                        style=3D"color:#606">Typename</span><span
                        style=3D"color:#000"><br>
                      </span><span style=3D"color:#660">{</span><span
                        style=3D"color:#000"><br>
                        =C2=A0 </span><span style=3D"color:#606">Type1</spa=
n><span
                        style=3D"color:#000"> name1</span><span
                        style=3D"color:#660">;</span><span
                        style=3D"color:#000"><br>
                        =C2=A0 </span><span style=3D"color:#606">Type2</spa=
n><span
                        style=3D"color:#000"> name2 </span><span
                        style=3D"color:#660">=3D</span><span
                        style=3D"color:#000"> </span><span
                        style=3D"color:#660">{...};</span><span
                        style=3D"color:#000"><br>
                      </span><span style=3D"color:#660">};</span></div>
                  </code></div>
                <br>
              </div>
            </blockquote>
            I don't buy that. This could means the default value for
            name2, not the default for Typename.<br>
            <br>
            But what does mean the following<br>
            <br>
            Typename v;<br>
            v.name1 =3D1,<br>
            f(v.name2);<br>
          </div>
        </blockquote>
        <div><br>
          If P0095 did provide such functionality, then it would simply
          throw some form of runtime exception. It would be no different
          from doing this with a variant type:<br>
          <br>
          <div class=3D"prettyprint" style=3D"background-color: rgb(250,
            250, 250); border-color: rgb(187, 187, 187); border-style:
            solid; border-width: 1px; word-wrap: break-word;"><code
              class=3D"prettyprint">
              <div class=3D"subprettyprint"><span style=3D"color: #000;"
                  class=3D"styled-by-prettify">variant</span><span
                  style=3D"color: #660;" class=3D"styled-by-prettify">&lt;<=
/span><span
                  style=3D"color: #606;" class=3D"styled-by-prettify">Type1=
</span><span
                  style=3D"color: #660;" class=3D"styled-by-prettify">,</sp=
an><span
                  style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
                  style=3D"color: #606;" class=3D"styled-by-prettify">Type2=
</span><span
                  style=3D"color: #660;" class=3D"styled-by-prettify">&gt;<=
/span><span
                  style=3D"color: #000;" class=3D"styled-by-prettify"> v</s=
pan><span
                  style=3D"color: #660;" class=3D"styled-by-prettify">;</sp=
an><span
                  style=3D"color: #000;" class=3D"styled-by-prettify"><br>
                  v</span><span style=3D"color: #660;"
                  class=3D"styled-by-prettify">.</span><span style=3D"color=
:
                  #000;" class=3D"styled-by-prettify">assign</span><span
                  style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an><span
                  style=3D"color: #000;" class=3D"styled-by-prettify">inpla=
ce_t</span><span
                  style=3D"color: #660;" class=3D"styled-by-prettify">&lt;<=
/span><span
                  style=3D"color: #066;" class=3D"styled-by-prettify">1</sp=
an><span
                  style=3D"color: #660;" class=3D"styled-by-prettify">&gt;(=
),</span><span
                  style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
                  style=3D"color: #066;" class=3D"styled-by-prettify">1</sp=
an><span
                  style=3D"color: #660;" class=3D"styled-by-prettify">);</s=
pan><span
                  style=3D"color: #000;" class=3D"styled-by-prettify"><br>
                  f</span><span style=3D"color: #660;"
                  class=3D"styled-by-prettify">(</span><span style=3D"color=
:
                  #008;" class=3D"styled-by-prettify">get</span><span
                  style=3D"color: #660;" class=3D"styled-by-prettify">&lt;<=
/span><span
                  style=3D"color: #066;" class=3D"styled-by-prettify">2</sp=
an><span
                  style=3D"color: #660;" class=3D"styled-by-prettify">&gt;(=
</span><span
                  style=3D"color: #000;" class=3D"styled-by-prettify">v</sp=
an><span
                  style=3D"color: #660;" class=3D"styled-by-prettify">));</=
span><span
                  style=3D"color: #000;" class=3D"styled-by-prettify"><br>
                </span></div>
            </code></div>
          <br>
          That's the analogy between language-variants and structs: ease
          of member access vs. ease of template metaprogrammability. The
          named language constructs make member access easy. While the
          library constructs make metaprogramming with them easy.<br>
        </div>
      </div>
    </blockquote>
    For the time being the proposal doesn't include member access,
    neither to assign or get them. David?<br>
    I would prefer to don't provide such terse syntax. I could however
    admit it. Could it be more efficient than the alternative <br>
    <br>
    v =3D Typename::name1(1);<br>
    <br>
    switch (v) {<br>
    =C2=A0=C2=A0=C2=A0 case Typename::name2(x): f(x);<br>
    };<br>
    <br>
    <br>
    <blockquote
      cite=3D"mid:c709ec06-3cff-485d-b6a1-6a2c62d4cc78@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
          P0095 doesn't provide this, but the syntax it relies on <i>could<=
/i>
          (and should) provide it. Your idea seems to sacrifice ease of
          member access to gain... what, exactly?<br>
        </div>
      </div>
    </blockquote>
    I must recognize that as P0095 I have not though about that. Now
    that you talk, I believe that we can consider the use case. I
    believe my last generalized enum suggestion could adapt provide a
    terse syntax. Anyway we don't have it in P0095.<br>
    <blockquote
      cite=3D"mid:c709ec06-3cff-485d-b6a1-6a2c62d4cc78@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div> This is what we usually have when we have fields names,
            we use them to set a value and to obtain it.<br>
            I don't want a union, I want a variant.=C2=A0</div>
        </blockquote>
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div text=3D"#000000" bgcolor=3D"#FFFFFF"> <br>
            <blockquote type=3D"cite">
              <div>With this definition, it would make sense to believe
                that a default-initialized `Typename` would be in the
                `Type2` state.<br>
                <br>
                That would be a good example of elegant syntax: strong
                points of familiarity and a lack of surplus syntax.<br>
                <br>
                Now, compare that to what you want:<br>
                <br>
                <div
style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);bo=
rder-style:solid;border-width:1px;word-wrap:break-word"><code>
                    <div><span style=3D"color:#008">enum</span><span
                        style=3D"color:#000"> </span><span
                        style=3D"color:#008">union</span><span
                        style=3D"color:#000"> </span><span
                        style=3D"color:#606">Typename</span><span
                        style=3D"color:#000"><br>
                      </span><span style=3D"color:#660">{</span><span
                        style=3D"color:#000"><br>
                        =C2=A0 =C2=A0</span><span style=3D"color:#008">stru=
ct</span><span
                        style=3D"color:#000"> name1 </span><span
                        style=3D"color:#660">{</span><span
                        style=3D"color:#606">Type1</span><span
                        style=3D"color:#660">;</span><span
                        style=3D"color:#000"> </span><span
                        style=3D"color:#660">};</span><span
                        style=3D"color:#000"><br>
                        =C2=A0 =C2=A0</span><span style=3D"color:#008">stru=
ct</span><span
                        style=3D"color:#000"> name2 </span><span
                        style=3D"color:#660">{</span><span
                        style=3D"color:#606">Type2</span><span
                        style=3D"color:#660">;</span><span
                        style=3D"color:#000"> </span><span
                        style=3D"color:#660">};</span><span
                        style=3D"color:#000"><br>
                      </span><span style=3D"color:#660">};</span></div>
                  </code></div>
                <br>
              </div>
            </blockquote>
            In reality what I want is either to extend the enums having
            enumerations that have parameters<br>
            <br>
            <div
style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);bo=
rder-style:solid;border-width:1px;word-wrap:break-word"><code>
                <div><span style=3D"color:#008">variantKeyword</span><span
                    style=3D"color:#000"> </span><span style=3D"color:#606"=
>Typename</span><span
                    style=3D"color:#000"> </span><span style=3D"color:#660"=
>{</span><span
                    style=3D"color:#000"> </span><span style=3D"color:#000"=
>name1
                  </span><span style=3D"color:#660">(</span><span
                    style=3D"color:#606">Type1</span><span
                    style=3D"color:#660"></span><span style=3D"color:#000">=
),</span><span
                    style=3D"color:#660"></span><span style=3D"color:#000">
                  </span><span style=3D"color:#000">name2 </span><span
                    style=3D"color:#660">(</span><span style=3D"color:#606"=
>Type2</span><span
                    style=3D"color:#660">)</span> <span
                    style=3D"color:#660">}; // enum like extension</span><b=
r>
                </div>
              </code></div>
            <br>
            This is the minimum I can have.</div>
        </blockquote>
        <div><br>
          Then why didn't you <i>start with that?</i> Why all the
          rigmarole about unnamed struct members and nested struct
          declarations and so forth?<br>
        </div>
      </div>
    </blockquote>
    I don't know :(=C2=A0 name1, name2 seem like symbolic functional terms
    and wrapping types was quite close to this.<br>
    <blockquote
      cite=3D"mid:c709ec06-3cff-485d-b6a1-6a2c62d4cc78@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
          You're already proposing new syntax, so you may as well
          propose the syntax you actually want. Compromises should come
          later.<br>
          <br>
        </div>
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div text=3D"#000000" bgcolor=3D"#FFFFFF"> Having <br>
            <br>
            <div
style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);bo=
rder-style:solid;border-width:1px;word-wrap:break-word"><code>
                <div><span style=3D"color:#008">variantKeyword</span><span
                    style=3D"color:#000"> </span><span style=3D"color:#000"=
>A</span><span
                    style=3D"color:#606"></span> <span style=3D"color:#660"=
>{</span><span
                    style=3D"color:#000">=C2=A0 c1(B), c2(B) </span><span
                    style=3D"color:#660">};</span></div>
              </code></div>
            <br>
            switch (a) {<br>
            =C2=A0=C2=A0=C2=A0 case A::c1(x):<br>
            =C2=A0=C2=A0=C2=A0 case A::c2(x):<br>
            };<br>
            <br>
            Is this better for you?</div>
        </blockquote>
        <div><br>
          So, how do you access the value? Is it `a.c1`?</div>
      </div>
    </blockquote>
    I'm not proposing direct access. Access is done by pattern matching.
    This is in line with P0095.<br>
    <br>
    However, as c1 signature is<br>
    <br>
    c1(B) -&gt; A<br>
    <br>
    The inverse function signature is<br>
    <br>
    ~c1(1) -&gt;B<br>
    <br>
    Your a.c1 suggestion would have the following inverse signature<br>
    <br>
    c1(A) -&gt; B<br>
    <br>
    Allowing a.c1 would mean that we use the same name for the inverse
    function.<br>
    <br>
    We could use A::~c1(a) or a.~c1.<br>
    <br>
    And as the syntax is not ambiguous the more terse syntax a.c1.<br>
    <br>
    Compare the following variant type using P0095 and my last proposal<br>
    <br>
    struct unit{};<br>
    <br>
    enum union E {<br>
    =C2=A0=C2=A0=C2=A0 unit c1;<br>
    =C2=A0=C2=A0=C2=A0 unit c2;<br>
    };<br>
    <br>
    variantKeyword E { c1(unit), c2(unit) };<br>
    <br>
    When the type stored is a unit type like unit we can make
    abstraction of it and remove it<br>
    <br>
    variantKeyword E { c1, c2 };<br>
    <br>
    and this is exactly the same as an enum<br>
    <br>
    enum class E { c1, c2 };<br>
    <br>
    <blockquote
      cite=3D"mid:c709ec06-3cff-485d-b6a1-6a2c62d4cc78@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div> If so, you haven't really solved the problem, since `c1`
          acts as both a typename (in your view) and as a member name.<br>
          <br>
        </div>
      </div>
    </blockquote>
    You are right. My original suggestion using structs doesn't works
    well if this use case must be taken in account. I would say that we
    are using c1 to mean two things, the injection and the partial
    projection. <br>
    <blockquote
      cite=3D"mid:c709ec06-3cff-485d-b6a1-6a2c62d4cc78@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>And if you can't access the state by name like that, if the
          only way to access the data is to use a switch statement, then
          what's the point of putting the variant into the language at
          all?<br>
        </div>
      </div>
    </blockquote>
    It is up to us to decide if we want direct access or not. I don't
    see a problem don't providing it as I could admit that in a C++
    world the access you are proposing could be what the user expects.
    This is a question not related to my suggestion, but to P0095 author
    and supporters.<br>
    <blockquote
      cite=3D"mid:c709ec06-3cff-485d-b6a1-6a2c62d4cc78@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
          It's not clear what `c1` actually is. Is it a typename? Is it
          legal to do `using v =3D A::c1;`?<br>
        </div>
      </div>
    </blockquote>
    <br>
    Good question. No, it is not a type on the last suggested syntax. It
    is something new.<br>
    <blockquote
      cite=3D"mid:c709ec06-3cff-485d-b6a1-6a2c62d4cc78@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div text=3D"#000000" bgcolor=3D"#FFFFFF">If yes, choose you
            keyword.<br>
            <br>
            Or <br>
            <br>
            <div
style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);bo=
rder-style:solid;border-width:1px;word-wrap:break-word"><code>
                <div><span style=3D"color:#660">variantKeeyword Type =3D
                    name1(Type1) | name2(Type2);<br>
                    <br>
                  </span><br>
                  inspect (a) {<br>
                  =C2=A0=C2=A0=C2=A0 when A::c1(x):<br>
                  =C2=A0=C2=A0=C2=A0 <code>when</code> A::c2(x):<br>
                  };<br>
                </div>
              </code></div>
            <blockquote type=3D"cite">
              <div>That looks even fishier, since you're supposed to use
                an initializer on a variable, not a type. Variables have
                <i>names</i> in C++, and your feature revolves entirely
                around unnamed variables. That's a *very* new thing for
                C++, so again, it lacks familiarity.<br>
                <br>
                What is your reason for claiming that your proposal,
                which involves unnamed variables and various other
                things, is more elegant?<br>
              </div>
            </blockquote>
            Resuming: P00095 make use of field names as been part of the
            alternative types. This is wrong IMO.<br>
            A variant needs selector to mean one type or another if we
            want to do pattern matching.<br>
          </div>
        </blockquote>
        <div><br>
          No. A variant needs the selector to mean one <b><i>state</i></b>
          or another. Whether that state has a distinct typename from
          another state is irrelevant. States have types, but there's
          nothing that requires those types to be different. That's a
          requirement you're inventing, not one that's actually there.
          P0088 variants allow using the type as a state name, but the
          primary state name is an integer.<br>
        </div>
      </div>
    </blockquote>
    I don't understand the last sentence.<br>
    <blockquote
      cite=3D"mid:c709ec06-3cff-485d-b6a1-6a2c62d4cc78@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
          In P0095, the state is a member variable name, just like with
          unions. In your idea, the state is a typename.<br>
        </div>
      </div>
      <br>
    </blockquote>
    I'm not thinking in terms of state, but I'm trying to think in terms
    of types, functions and values (Maths).<br>
    <br>
    name1, name2 behave in some way as symbolic enumerations that are
    different as in<br>
    <br>
    <code>enum class E { name1 , name2=C2=A0 };<br>
      <br>
      E e;<br>
      <br>
      switch (e) {<br>
      =C2=A0=C2=A0=C2=A0 case name1: ...<br>
      =C2=A0=C2=A0=C2=A0 case name2: ...<br>
      };<br>
      <br>
      <br>
      What are name1, name2? types? functions? values?<br>
      <br>
      When I write<br>
      <br>
      enum E {name1(Type1), name2(Type2) };<br>
      <br>
      <br>
      We can see them as functions that transform the T in another
      different type, as soon as name1(T) and name2(T) are different
      types.<br>
      <br>
      =C2=A0=C2=A0=C2=A0 name1(Type1) | name2(Type2)<br>
      <br>
      We can see them as values (name1, name2 are different values)<br>
      <br>
      =C2=A0=C2=A0 {name1}xType1 | {name2}xType2<br>
      <br>
      We can see name1 as a single unit type with a single element
      name1{}<br>
      <br>
      =C2=A0=C2=A0 name1xType1 | name2xType2<br>
      <br>
      When Type1 and Type2 are the same type, it is this symbolic names
      name1, name2 that makes the difference.<br>
      <br>
      I like the function view.<br>
      <br>
      <br>
      I believe we need to state clearly how the variant can be used.
      Your direct access is a good example. P0095 don't talk neither of
      constructors, except for the default constructor. Do we want to be
      able to add constructors other? Other member operations? I don't
      believe we want. Maybe others have some examples where adding
      other members functions make the code clearer.<br>
      <br>
    </code><code>Vicente</code><code><span style=3D"color:#660"><br>
        <br>
        P.S. Apologies if I'm often not clear enough.<br>
      </span></code>
  </body>
</html>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--------------090106010806080405060906--

.

------=_Part_307_180009642.1450172660710
Content-Type: multipart/alternative;
 boundary="----=_Part_308_1397529469.1450172660710"

------=_Part_308_1397529469.1450172660710
Content-Type: text/plain; charset=UTF-8

On Monday, December 14, 2015 at 4:15:04 PM UTC, Nicol Bolas wrote:
>
>
> [...] we already have nested type definitions that *don't* declare
> unnamed variables. Consider this:
>
> struct Outer
> {
>   struct Inner {int x};
>   struct Inner2 {int x} v;
> };
>
> How many NSDMs does `Outer` have? One. It has two nested types, but only
> one NSDM of that type.
>
> Your plan has struct declarations creating actual NSDMs within their
> contained types *without* having an explicit variable name. This makes
> your variant type declarations work very differently from regular type
> declarations (struct/class/union).
>


I wish it was that simple:

struct Outer2 {
{
     union { int x; };
     struct { int y; } z;
};

How many NSDM does Outer2 have? Yes, 2. In C11 (and, as a very common
extension, in C++) you can also replace union with struct.

Having said that, I agree with you that tags are better than types to name
variant 'fields'.

-- gpd

--

---
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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Monday, December 14, 2015 at 4:15:04 PM UTC, Nicol Bolas wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><div>[...] we alre=
ady have nested type definitions that <i>don&#39;t</i> declare unnamed vari=
ables. Consider this:<br><br><div style=3D"background-color:rgb(250,250,250=
);border-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wr=
ap:break-word"><code><div><span style=3D"color:#008">struct</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#606">Outer</span><span styl=
e=3D"color:#000"><br></span><span style=3D"color:#660">{</span><span style=
=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#008">struct</span><=
span style=3D"color:#000"> </span><span style=3D"color:#606">Inner</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#660">{</span><span s=
tyle=3D"color:#008">int</span><span style=3D"color:#000"> x</span><span sty=
le=3D"color:#660">};</span><span style=3D"color:#000"><br>=C2=A0 </span><sp=
an style=3D"color:#008">struct</span><span style=3D"color:#000"> </span><sp=
an style=3D"color:#606">Inner2</span><span style=3D"color:#000"> </span><sp=
an style=3D"color:#660">{</span><span style=3D"color:#008">int</span><span =
style=3D"color:#000"> x</span><span style=3D"color:#660">}</span><span styl=
e=3D"color:#000"> v</span><span style=3D"color:#660">;</span><span style=3D=
"color:#000"><br></span><span style=3D"color:#660">};</span><span style=3D"=
color:#000"><br></span></div></code></div><br>How many NSDMs does `Outer` h=
ave? One. It has two nested types, but only one NSDM of that type.<br><br><=
/div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div>Your plan has struct declarations creating actual NSDMs wit=
hin their contained types <i>without</i> having an explicit variable name. =
This makes your variant type declarations work very differently from regula=
r type declarations (struct/class/union).<br></div></div></blockquote><div>=
<br><br>I wish it was that simple:<br><br>struct Outer2 {<br>{<br>=C2=A0=C2=
=A0=C2=A0=C2=A0 union { int x; };<br>=C2=A0=C2=A0=C2=A0=C2=A0 struct { int =
y; } z;<br>};<br><br>How many NSDM does Outer2 have? Yes, 2. In C11 (and, a=
s a very common extension, in C++) you can also replace union with struct.<=
br><br>Having said that, I agree with you that tags are better than types t=
o name variant &#39;fields&#39;. <br><br>-- gpd<br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_308_1397529469.1450172660710--
------=_Part_307_180009642.1450172660710--

.

--089e01494452fa5d6a0526f2e7c4
Content-Type: text/plain; charset=UTF-8

Hello all,

On Sat, Dec 12, 2015 at 11:54 PM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:

> If we remove the field names in POD structs and unions
>
> union S {
>     struct left {int a;}  c1;
>     struct right{string a;}  c2;
> };
>
> as in
>
> union S {
>     struct left {int;}  ;
>     struct right{string;}  ;
> };
>
> The result is syntactically quite close to sum types in functional
> languages like Haskhell
>
> data S = Left int | Right string
>

Thanks for getting this discussion going! I found the conversation to be
enlightening and productive.

While I highly appreciate functional languages and know Haskell quite well,
"syntactically quite close to sum types in functional languages like
Haskell" is not something that I'm going for with P0095. I'm much more
interested in the use cases that drive the need for the feature and
achieving resonance with the rest of the C++ language. I realize this is a
philosophical choice, but nonetheless I think this approach is going to
foster wider adoption of the feature by those who need it.

That being said, if there is a driving use case for "sum of products" as
opposed to having sums and products being separate entities, I'd like to
see it. As it is, I find the separation of the two to be syntactically
cleaner. As an aside (and this is *not* a motivation) separation of sums
and products is much closer to how they are defined and used mathematically.

Regarding 'switch' vs. 'inspect', in Kona it was pointed out that P0095's
reuse of the 'switch' keyword could create new developer confusion in that
sometimes a 'switch' statement is going to require 'break's and other
places it will not. The next P0095 revision will not be using the 'switch'
keyword for this reason.

I didn't discuss the use of field accessors in P0095 because I was unsure
whether or not their use would be superior to some sort of cast syntax. The
semantics that Giovanni gives them makes a lot of sense to me though. I can
see both sides of the issue. Hopefully we can explore the two options
further in Jacksonville.

Lately I've been working on generalizing the pattern matching to user
defined types. Achieving resonance with the rest of C++ is proving the most
difficult aspect here, especially for sum types. I think we'll be able to
come up with something nice though. I'll be releasing a blog post about it
in the next couple weeks.

-- David

--

---
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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">Hell=
o all,</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote"=
>On Sat, Dec 12, 2015 at 11:54 PM, Vicente J. Botet Escriba <span dir=3D"lt=
r">&lt;<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vicent=
e.botet@wanadoo.fr</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-colo=
r:rgb(204,204,204);border-left-style:solid;padding-left:1ex">If we remove t=
he field names in POD structs and unions<br>
<br>
union S {<br>
=C2=A0 =C2=A0 struct left {int a;}=C2=A0 c1;<br>
=C2=A0 =C2=A0 struct right{string a;}=C2=A0 c2;<br>
};<br>
<br>
as in<br>
<br>
union S {<br>
=C2=A0 =C2=A0 struct left {int;}=C2=A0 ;<br>
=C2=A0 =C2=A0 struct right{string;}=C2=A0 ;<br>
};<br>
<br>
The result is syntactically quite close to sum types in functional language=
s like Haskhell<br>
<br>
data S =3D Left int | Right string<br></blockquote><div><br></div><div>Than=
ks for getting this discussion going! I found the conversation to be enligh=
tening and productive.</div><div><br></div><div><div>While I highly appreci=
ate functional languages and know Haskell quite well, &quot;syntactically q=
uite close to sum types in functional languages like Haskell&quot; is not s=
omething that I&#39;m going for with P0095. I&#39;m much more interested in=
 the use cases that drive the need for the feature and achieving resonance =
with the rest of the C++ language. I realize this is a philosophical choice=
, but nonetheless I think this approach is going to foster wider adoption o=
f the feature by those who need it.</div></div><div><br></div><div>That bei=
ng said, if there is a driving use case for &quot;sum of products&quot; as =
opposed to having sums and products being separate entities, I&#39;d like t=
o see it. As it is, I find the separation of the two to be syntactically cl=
eaner. As an aside (and this is *not* a motivation) separation of sums and =
products is much closer to how they are defined and used mathematically.<br=
></div><div><br></div><div><div>Regarding &#39;switch&#39; vs. &#39;inspect=
&#39;, in Kona it was pointed out that P0095&#39;s reuse of the &#39;switch=
&#39; keyword could create new developer confusion in that sometimes a &#39=
;switch&#39; statement is going to require &#39;break&#39;s and other place=
s it will not. The next P0095 revision will not be using the &#39;switch&#3=
9; keyword for this reason.</div></div><div><br></div><div><div>I didn&#39;=
t discuss the use of field accessors in P0095 because I was unsure whether =
or not their use would be superior to some sort of cast syntax. The semanti=
cs that Giovanni gives them makes a lot of sense to me though. I can see bo=
th sides of the issue. Hopefully we can explore the two options further in =
Jacksonville.</div></div><div><br></div><div>Lately I&#39;ve been working o=
n generalizing the pattern matching to user defined types. Achieving resona=
nce with the rest of C++ is proving the most difficult aspect here, especia=
lly for sum types. I think we&#39;ll be able to come up with something nice=
 though. I&#39;ll be releasing a blog post about it in the next couple week=
s.</div><div><br></div><div>-- David</div></div></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--089e01494452fa5d6a0526f2e7c4--

.

This is a multi-part message in MIME format.
--------------030407080908030209070303
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 15/12/2015 18:12, David Sankel a =C3=A9crit :
> Hello all,
>
> On Sat, Dec 12, 2015 at 11:54 PM, Vicente J. Botet Escriba=20
> <vicente.botet@wanadoo.fr <mailto:vicente.botet@wanadoo.fr>> wrote:
>
>     If we remove the field names in POD structs and unions
>
>     union S {
>         struct left {int a;}  c1;
>         struct right{string a;}  c2;
>     };
>
>     as in
>
>     union S {
>         struct left {int;}  ;
>         struct right{string;}  ;
>     };
>
>     The result is syntactically quite close to sum types in functional
>     languages like Haskhell
>
>     data S =3D Left int | Right string
>
>
> Thanks for getting this discussion going! I found the conversation to=20
> be enlightening and productive.
>
> While I highly appreciate functional languages and know Haskell quite=20
> well, "syntactically quite close to sum types in functional languages=20
> like Haskell" is not something that I'm going for with P0095. I'm much=20
> more interested in the use cases that drive the need for the feature=20
> and achieving resonance with the rest of the C++ language. I realize=20
> this is a philosophical choice, but nonetheless I think this approach=20
> is going to foster wider adoption of the feature by those who need it.
>
> That being said, if there is a driving use case for "sum of products"=20
> as opposed to having sums and products being separate entities, I'd=20
> like to see it. As it is, I find the separation of the two to be=20
> syntactically cleaner. As an aside (and this is *not* a motivation)=20
> separation of sums and products is much closer to how they are defined=20
> and used mathematically.

If we had generalized enum I was proposing lately such as

     enum P { p(int, string) };

product types would come for free.
>
> Regarding 'switch' vs. 'inspect', in Kona it was pointed out that=20
> P0095's reuse of the 'switch' keyword could create new developer=20
> confusion in that sometimes a 'switch' statement is going to require=20
> 'break's and other places it will not. The next P0095 revision will=20
> not be using the 'switch' keyword for this reason.
>
> I didn't discuss the use of field accessors in P0095 because I was=20
> unsure whether or not their use would be superior to some sort of cast=20
> syntax. The semantics that Giovanni gives them makes a lot of sense to=20
> me though. I can see both sides of the issue. Hopefully we can explore=20
> the two options further in Jacksonville.
What about having additional constructors and member functions. Do you=20
plan to allow them or not?
>
> Lately I've been working on generalizing the pattern matching to user=20
> defined types. Achieving resonance with the rest of C++ is proving the=20
> most difficult aspect here, especially for sum types. I think we'll be=20
> able to come up with something nice though. I'll be releasing a blog=20
> post about it in the next couple weeks.
>
Having generalized pattern matching on these generalized enums is much=20
simpler and would be already a good thing (of course if we consider that=20
the generalized enum is a good feature).

     enum class PQ { p(int, string), q(int) };

I'm impatient for reading the blog,
Vicente

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 15/12/2015 18:12, David Sankel a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
cite=3D"mid:CAFYdOOK218iE6ps-C25QN_L-zL0CbZgOG-MuX6j5nO=3DRYqqusg@mail.gmai=
l.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">Hello all,</div>
          <div class=3D"gmail_quote"><br>
          </div>
          <div class=3D"gmail_quote">On Sat, Dec 12, 2015 at 11:54 PM,
            Vicente J. Botet Escriba <span dir=3D"ltr">&lt;<a
                moz-do-not-send=3D"true"
                href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">=
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:vicente.botet@wanadoo.=
fr">vicente.botet@wanadoo.fr</a></a>&gt;</span>
            wrote:<br>
            <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex">If
              we remove the field names in POD structs and unions<br>
              <br>
              union S {<br>
              =C2=A0 =C2=A0 struct left {int a;}=C2=A0 c1;<br>
              =C2=A0 =C2=A0 struct right{string a;}=C2=A0 c2;<br>
              };<br>
              <br>
              as in<br>
              <br>
              union S {<br>
              =C2=A0 =C2=A0 struct left {int;}=C2=A0 ;<br>
              =C2=A0 =C2=A0 struct right{string;}=C2=A0 ;<br>
              };<br>
              <br>
              The result is syntactically quite close to sum types in
              functional languages like Haskhell<br>
              <br>
              data S =3D Left int | Right string<br>
            </blockquote>
            <div><br>
            </div>
            <div>Thanks for getting this discussion going! I found the
              conversation to be enlightening and productive.</div>
            <div><br>
            </div>
            <div>
              <div>While I highly appreciate functional languages and
                know Haskell quite well, "syntactically quite close to
                sum types in functional languages like Haskell" is not
                something that I'm going for with P0095. I'm much more
                interested in the use cases that drive the need for the
                feature and achieving resonance with the rest of the C++
                language. I realize this is a philosophical choice, but
                nonetheless I think this approach is going to foster
                wider adoption of the feature by those who need it.</div>
            </div>
            <div><br>
            </div>
            <div>That being said, if there is a driving use case for
              "sum of products" as opposed to having sums and products
              being separate entities, I'd like to see it. As it is, I
              find the separation of the two to be syntactically
              cleaner. As an aside (and this is *not* a motivation)
              separation of sums and products is much closer to how they
              are defined and used mathematically.<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    If we had generalized enum I was proposing lately such as<br>
    <br>
    =C2=A0=C2=A0=C2=A0 enum P { p(int, string) };<br>
    <br>
    product types would come for free.<br>
    <blockquote
cite=3D"mid:CAFYdOOK218iE6ps-C25QN_L-zL0CbZgOG-MuX6j5nO=3DRYqqusg@mail.gmai=
l.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <div><br>
            </div>
            <div>
              <div>Regarding 'switch' vs. 'inspect', in Kona it was
                pointed out that P0095's reuse of the 'switch' keyword
                could create new developer confusion in that sometimes a
                'switch' statement is going to require 'break's and
                other places it will not. The next P0095 revision will
                not be using the 'switch' keyword for this reason.</div>
            </div>
            <div><br>
            </div>
            <div>
              <div>I didn't discuss the use of field accessors in P0095
                because I was unsure whether or not their use would be
                superior to some sort of cast syntax. The semantics that
                Giovanni gives them makes a lot of sense to me though. I
                can see both sides of the issue. Hopefully we can
                explore the two options further in Jacksonville.</div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    What about having additional constructors and member functions. Do
    you plan to allow them or not? <br>
    <blockquote
cite=3D"mid:CAFYdOOK218iE6ps-C25QN_L-zL0CbZgOG-MuX6j5nO=3DRYqqusg@mail.gmai=
l.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <div><br>
            </div>
            <div>Lately I've been working on generalizing the pattern
              matching to user defined types. Achieving resonance with
              the rest of C++ is proving the most difficult aspect here,
              especially for sum types. I think we'll be able to come up
              with something nice though. I'll be releasing a blog post
              about it in the next couple weeks.</div>
            <br>
          </div>
        </div>
      </div>
    </blockquote>
    Having generalized pattern matching on these generalized enums is
    much simpler and would be already a good thing (of course if we
    consider that the generalized enum is a good feature).<br>
    <br>
    =C2=A0=C2=A0=C2=A0 enum class PQ { p(int, string), q(int) };<br>
    <br>
    I'm impatient for reading the blog,<br>
    Vicente<br>
  </body>
</html>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--------------030407080908030209070303--

.

--001a1140f7e0789e550526f3de60
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 15, 2015 at 11:06 AM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:

> Le 15/12/2015 18:12, David Sankel a =C3=A9crit :
>
> Hello all,
>
> On Sat, Dec 12, 2015 at 11:54 PM, Vicente J. Botet Escriba <
> <vicente.botet@wanadoo.fr>vicente.botet@wanadoo.fr> wrote:
>
>> If we remove the field names in POD structs and unions
>>
>> union S {
>>     struct left {int a;}  c1;
>>     struct right{string a;}  c2;
>> };
>>
>> as in
>>
>> union S {
>>     struct left {int;}  ;
>>     struct right{string;}  ;
>> };
>>
>> The result is syntactically quite close to sum types in functional
>> languages like Haskhell
>>
>> data S =3D Left int | Right string
>>
>
> Thanks for getting this discussion going! I found the conversation to be
> enlightening and productive.
>
> While I highly appreciate functional languages and know Haskell quite
> well, "syntactically quite close to sum types in functional languages lik=
e
> Haskell" is not something that I'm going for with P0095. I'm much more
> interested in the use cases that drive the need for the feature and
> achieving resonance with the rest of the C++ language. I realize this is =
a
> philosophical choice, but nonetheless I think this approach is going to
> foster wider adoption of the feature by those who need it.
>
> That being said, if there is a driving use case for "sum of products" as
> opposed to having sums and products being separate entities, I'd like to
> see it. As it is, I find the separation of the two to be syntactically
> cleaner. As an aside (and this is *not* a motivation) separation of sums
> and products is much closer to how they are defined and used mathematical=
ly.
>
>
> If we had generalized enum I was proposing lately such as
>
>     enum P { p(int, string) };
>
> product types would come for free.
>


Yes, but we already get product types for free with structs. I'm not
convinced we need another product type. Credit to Bengt Gustafsson for
pointing out that we could use anonymous structs to get something close to
the Haskell syntax for those who want it.

enum union {
  int theInt;
  struct { int x; int y; } thePoint;
};



>
>
> Regarding 'switch' vs. 'inspect', in Kona it was pointed out that P0095's
> reuse of the 'switch' keyword could create new developer confusion in tha=
t
> sometimes a 'switch' statement is going to require 'break's and other
> places it will not. The next P0095 revision will not be using the 'switch=
'
> keyword for this reason.
>
> I didn't discuss the use of field accessors in P0095 because I was unsure
> whether or not their use would be superior to some sort of cast syntax. T=
he
> semantics that Giovanni gives them makes a lot of sense to me though. I c=
an
> see both sides of the issue. Hopefully we can explore the two options
> further in Jacksonville.
>
> What about having additional constructors and member functions. Do you
> plan to allow them or not?
>

I think at the very least we'll want to allow for a customizable assignment
operator.


> Lately I've been working on generalizing the pattern matching to user
> defined types. Achieving resonance with the rest of C++ is proving the mo=
st
> difficult aspect here, especially for sum types. I think we'll be able to
> come up with something nice though. I'll be releasing a blog post about i=
t
> in the next couple weeks.
>
> Having generalized pattern matching on these generalized enums is much
> simpler and would be already a good thing (of course if we consider that
> the generalized enum is a good feature).
>
>     enum class PQ { p(int, string), q(int) };
>
> I'm impatient for reading the blog,
>

I feel you. It's coming...

-- David

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Dec 15, 2015 at 11:06 AM, Vicente J. Botet Escriba <span dir=3D"ltr">&l=
t;<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vicente.bot=
et@wanadoo.fr</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div text=3D"#000000" bgcolor=3D"#FFFFFF"><span class=3D"">
    <div>Le 15/12/2015 18:12, David Sankel a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">Hello all,</div>
          <div class=3D"gmail_quote"><br>
          </div>
          <div class=3D"gmail_quote">On Sat, Dec 12, 2015 at 11:54 PM,
            Vicente J. Botet Escriba <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:vicente.botet@wanadoo.fr" target=3D"_blank"></a><a href=3D"mailto:vicente=
..botet@wanadoo.fr" target=3D"_blank">vicente.botet@wanadoo.fr</a>&gt;</span=
>
            wrote:<br>
            <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex">If
              we remove the field names in POD structs and unions<br>
              <br>
              union S {<br>
              =C2=A0 =C2=A0 struct left {int a;}=C2=A0 c1;<br>
              =C2=A0 =C2=A0 struct right{string a;}=C2=A0 c2;<br>
              };<br>
              <br>
              as in<br>
              <br>
              union S {<br>
              =C2=A0 =C2=A0 struct left {int;}=C2=A0 ;<br>
              =C2=A0 =C2=A0 struct right{string;}=C2=A0 ;<br>
              };<br>
              <br>
              The result is syntactically quite close to sum types in
              functional languages like Haskhell<br>
              <br>
              data S =3D Left int | Right string<br>
            </blockquote>
            <div><br>
            </div>
            <div>Thanks for getting this discussion going! I found the
              conversation to be enlightening and productive.</div>
            <div><br>
            </div>
            <div>
              <div>While I highly appreciate functional languages and
                know Haskell quite well, &quot;syntactically quite close to
                sum types in functional languages like Haskell&quot; is not
                something that I&#39;m going for with P0095. I&#39;m much m=
ore
                interested in the use cases that drive the need for the
                feature and achieving resonance with the rest of the C++
                language. I realize this is a philosophical choice, but
                nonetheless I think this approach is going to foster
                wider adoption of the feature by those who need it.</div>
            </div>
            <div><br>
            </div>
            <div>That being said, if there is a driving use case for
              &quot;sum of products&quot; as opposed to having sums and pro=
ducts
              being separate entities, I&#39;d like to see it. As it is, I
              find the separation of the two to be syntactically
              cleaner. As an aside (and this is *not* a motivation)
              separation of sums and products is much closer to how they
              are defined and used mathematically.<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></span>
    If we had generalized enum I was proposing lately such as<br>
    <br>
    =C2=A0=C2=A0=C2=A0 enum P { p(int, string) };<br>
    <br>
    product types would come for free.</div></blockquote><div><br></div><di=
v><br></div><div>Yes, but we already get product types for free with struct=
s. I&#39;m not convinced we need another product type. Credit to Bengt Gust=
afsson for pointing out that we could use anonymous structs to get somethin=
g close to the Haskell syntax for those who want it.</div><div><br></div><d=
iv>enum union {</div><div>=C2=A0 int theInt;</div><div>=C2=A0 struct { int =
x; int y; } thePoint;</div><div>};</div><div><br></div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div text=3D"#000000" bgcolor=3D"#FFFFFF"><span=
 class=3D""><br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <div><br>
            </div>
            <div>
              <div>Regarding &#39;switch&#39; vs. &#39;inspect&#39;, in Kon=
a it was
                pointed out that P0095&#39;s reuse of the &#39;switch&#39; =
keyword
                could create new developer confusion in that sometimes a
                &#39;switch&#39; statement is going to require &#39;break&#=
39;s and
                other places it will not. The next P0095 revision will
                not be using the &#39;switch&#39; keyword for this reason.<=
/div>
            </div>
            <div><br>
            </div>
            <div>
              <div>I didn&#39;t discuss the use of field accessors in P0095
                because I was unsure whether or not their use would be
                superior to some sort of cast syntax. The semantics that
                Giovanni gives them makes a lot of sense to me though. I
                can see both sides of the issue. Hopefully we can
                explore the two options further in Jacksonville.</div>
            </div>
          </div>
        </div>
      </div>
    </blockquote></span>
    What about having additional constructors and member functions. Do
    you plan to allow them or not? <br></div></blockquote><div><br></div><d=
iv>I think at the very least we&#39;ll want to allow for a customizable ass=
ignment operator.</div><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div t=
ext=3D"#000000" bgcolor=3D"#FFFFFF"><span class=3D"">
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <div><br>
            </div>
            <div>Lately I&#39;ve been working on generalizing the pattern
              matching to user defined types. Achieving resonance with
              the rest of C++ is proving the most difficult aspect here,
              especially for sum types. I think we&#39;ll be able to come u=
p
              with something nice though. I&#39;ll be releasing a blog post
              about it in the next couple weeks.</div>
            <br>
          </div>
        </div>
      </div>
    </blockquote></span>
    Having generalized pattern matching on these generalized enums is
    much simpler and would be already a good thing (of course if we
    consider that the generalized enum is a good feature).<br>
    <br>
    =C2=A0=C2=A0=C2=A0 enum class PQ { p(int, string), q(int) };<br>
    <br>
    I&#39;m impatient for reading the blog,<br></div></blockquote><div><br>=
</div><div>I feel you. It&#39;s coming...</div><div><br></div><div>-- David=
=C2=A0</div></div></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a1140f7e0789e550526f3de60--

.