Topic: C++ named tuple - attribute_key


Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sat, 09 May 2015 18:54:04 +0200
Raw View
This is a multi-part message in MIME format.
--------------000006040803090909080405
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 13/07/14 17:34, Jean-Bernard Jansen a =C3=A9crit :
> Hello guys
>
> This post will sure be of interest to @German Diago. I drastically=20
> improved my named tuple prototype since the last time. Changes includes:
> - More generic API, easier to use.
> - New internal storage method : base on a std::stuple instead of a=20
> recursive class hierachy, allowing for nice and fast interactions with=20
> std::tuple.
> - The hash collision problem has been solved : if two members happen=20
> to have the same id, name or hash, the compilation will fail.
> - Smaller code, easier to read.
>
> Enjoy code and examples here: https://github.com/duckie/named_tuple.
>
>
Hi,

even if this is  an old post, I find this library quite interesting.

I like a lot
* the function syntax to identify the attribute holder int(age),

I like, but less
* the named parameter syntax _<name> =3D val
* the selector syntax tuple. _<name>

Just wondering if you could add in addition to attributes_holder,=20
attributes_key. An attribute_key instance could have a name.
  E.g.

     constexpr struct name_t : attribute_key<name_t> {} name;


This could help to replace _<name>=3Dval by *name=3Dval*.

template <class Id, class T>
auto attribute_key<Id>::operator=3D(attibute_key<Id>, T val) {return=20
attribute_helper::_<Id>=3Dval; }

The member _ could also be overloaded with attribute_key<name_t>=20
*tpl._(name).*

template <class Id>
auto named_tuple::_(attibute_key<Id>) {return attribute_helper::_<Id>(); }

or the operator() *tpl(name).*

Alternatively an overload for the operator% on tuple and=20
attribute_key<name> *tpl%name*.

template <class NamedTuple, class Id>
auto operator%(NamedTuple const& tpl, attibute_key<Id>) {return=20
tpl._<Id>(); }

Last the attribute_key could be seen as a key selector function *name(tml)*=
..

template <class NamedTuple>
auto attibute_key<Id>::operator()(NamedTuple const& tpl) {return=20
tpl._<Id>(); }


The following example

namespace {
struct name;
struct age;
struct taille;
struct liste;
}

int main() {
   auto test =3D make_named_tuple(
       _<name>() =3D std::string("Roger")
       , _<age>() =3D 47
       , _<taille>() =3D 1.92
       , _<liste>() =3D std::vector<int>({1,2,3})
       );

   std::cout
     << test._<name>() << "\n"
     << test._<age>() << "\n"
     << test._<taille>() << "\n"
     << test._<liste>().size() << std::endl;


could be transformed using the new attribute_key as follows

namespace {
     constexpr struct name_t : attribute_key<name_t> {} name;
     constexpr struct age_t : attribute_key<age_t> {} age;
     constexpr struct taille_t : attribute_key<taille_t> {} taille;
     constexpr struct liste_t : attribute_key<liste_t> {} liste;
}

int main() {

// No need to use the artificial _<name> =3D, name =3Dis enough

   auto test =3D make_named_tuple(
         name =3D std::string("Roger")
       , age =3D 47
       , taille =3D 1.92
       , liste =3D std::vector<int>({1,2,3})
       );

// However, here we need the type, name_t :(

   std::cout
     << test._<name_t>() << "\n"
     << test._<age_t>() << "\n"
     << test._<taille_t>() << "\n"
     << test._<liste_t>().size() << std::endl;

// making use of overloaded member _
   std::cout
     << test._(name) << "\n"
     << test._(age) << "\n"
     << test._(taille) << "\n"
     << test._(liste_t).size() << std::endl;

// making use of overloaded member operator()
   std::cout
     << test(name) << "\n"
     << test(age) << "\n"
     << test(taille) << "\n"
     << test(liste_t).size() << std::endl;

// Using the operator tuple % attribute_key

   std::cout
     << test%name << "\n"
     << test%age << "\n"
     << test%taille << "\n"
     << (test%liste_t).size() << std::endl;

// Using the attribute_key operator ()

   std::cout
     << name(test) << "\n"
     << age(test) << "\n"
     << taille(test) << "\n"
     << liste(test).size() << std::endl;

}

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 http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--------------000006040803090909080405
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 bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 13/07/14 17:34, Jean-Bernard Jansen
      a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
cite=3D"mid:CALoNf_VL8L7R+=3DmuvdtJybh3eHfhKqMC2uQj5L+Jcxs6F__YVg@mail.gmai=
l.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>
            <div>
              <div>
                <div>
                  <div>
                    <div>Hello guys<br>
                      <br>
                    </div>
                    This post will sure be of interest to @German Diago.
                    I drastically improved my named tuple prototype
                    since the last time. Changes includes:<br>
                  </div>
                </div>
                - More generic API, easier to use.<br>
              </div>
              - New internal storage method : base on a std::stuple
              instead of a recursive class hierachy, allowing for nice
              and fast interactions with std::tuple.<br>
            </div>
            - The hash collision problem has been solved : if two
            members happen to have the same id, name or hash, the
            compilation will fail.<br>
          </div>
          - Smaller code, easier to read.<br>
          <br>
        </div>
        Enjoy code and examples here: <a moz-do-not-send=3D"true"
          href=3D"https://github.com/duckie/named_tuple">https://github.com=
/duckie/named_tuple</a>.<br>
        <br>
        <br>
      </div>
    </blockquote>
    Hi,<br>
    <br>
    even if this is=C2=A0 an old post, I find this library quite interestin=
g.<br>
    <br>
    I like a lot<br>
    * the function syntax to identify the attribute holder int(age),<br>
    <br>
    I like, but less<br>
    * the named parameter syntax _&lt;name&gt; =3D val<br>
    * the selector syntax tuple. _&lt;name&gt;<br>
    <br>
    Just wondering if you could add in addition to attributes_holder,
    attributes_key. An attribute_key instance could have a name.<br>
    =C2=A0E.g.<br>
    <br>
    =C2=A0=C2=A0=C2=A0 constexpr struct name_t : attribute_key&lt;name_t&gt=
; {} name;<br>
    <br>
    <br>
    This could help to replace _&lt;name&gt;=3Dval by=C2=A0 <b>name=3Dval</=
b>.<br>
    <br>
    template &lt;class Id, class T&gt;<br>
    auto attribute_key&lt;Id&gt;::operator=3D(attibute_key&lt;Id&gt;, T
    val) {return attribute_helper::_&lt;Id&gt;=3Dval; }<br>
    <br>
    The member _ could also be overloaded with
    attribute_key&lt;name_t&gt; <b>tpl._(name).</b><br>
    <br>
    template &lt;class Id&gt;<br>
    auto named_tuple::_(attibute_key&lt;Id&gt;) {return
    attribute_helper::_&lt;Id&gt;(); }<br>
    <br>
    or the operator() <b>tpl(name).</b><br>
    <br>
    Alternatively an overload for the operator% on tuple and
    attribute_key&lt;name&gt; <b>tpl%name</b>.<br>
    <br>
    template &lt;class NamedTuple, class Id&gt;<br>
    auto operator%(NamedTuple const&amp; tpl, attibute_key&lt;Id&gt;)
    {return tpl._&lt;Id&gt;(); }<br>
    <br>
    Last the attribute_key could be seen as a key selector function <b>name=
(tml)</b>.<br>
    <br>
    template &lt;class NamedTuple&gt;<br>
    auto attibute_key&lt;Id&gt;::operator()(NamedTuple const&amp; tpl)
    {return tpl._&lt;Id&gt;(); }<br>
    <br>
    <br>
    The following example<br>
    <br>
    namespace {<br>
    struct name;<br>
    struct age;<br>
    struct taille;<br>
    struct liste;<br>
    }<br>
    <br>
    int main() {<br>
    =C2=A0 auto test =3D make_named_tuple(<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 _&lt;name&gt;() =3D std::string("Roger")=
<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , _&lt;age&gt;() =3D 47<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , _&lt;taille&gt;() =3D 1.92<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , _&lt;liste&gt;() =3D std::vector&lt;in=
t&gt;({1,2,3})<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 );<br>
    <br>
    =C2=A0 std::cout<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test._&lt;name&gt;() &lt;&lt; "\n"<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test._&lt;age&gt;() &lt;&lt; "\n"<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test._&lt;taille&gt;() &lt;&lt; "\n"<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test._&lt;liste&gt;().size() &lt;&lt; std::=
endl;<br>
    <br>
    <br>
    could be transformed using the new attribute_key as follows<br>
    <br>
    namespace {<br>
    =C2=A0=C2=A0=C2=A0 constexpr struct name_t : attribute_key&lt;name_t&gt=
; {} name;<br>
    =C2=A0=C2=A0=C2=A0 constexpr struct age_t : attribute_key&lt;age_t&gt; =
{} age;<br>
    =C2=A0=C2=A0=C2=A0 constexpr struct taille_t : attribute_key&lt;taille_=
t&gt; {}
    taille;<br>
    =C2=A0=C2=A0=C2=A0 constexpr struct liste_t : attribute_key&lt;liste_t&=
gt; {}
    liste;<br>
    }<br>
    <br>
    int main() {<br>
    <br>
    // No need to use the artificial _&lt;name&gt; =3D, name =3Dis enough<b=
r>
    <br>
    =C2=A0 auto test =3D make_named_tuple(<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 name =3D std::string("Roger"=
)<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , age =3D 47<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , taille =3D 1.92<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , liste =3D std::vector&lt;int&gt;({1,2,=
3})<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 );<br>
    <br>
    // However, here we need the type, name_t :(<br>
    <br>
    =C2=A0 std::cout<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test._&lt;name_t&gt;() &lt;&lt; "\n"<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test._&lt;age_t&gt;() &lt;&lt; "\n"<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test._&lt;taille_t&gt;() &lt;&lt; "\n"<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test._&lt;liste_t&gt;().size() &lt;&lt; std=
::endl;<br>
    <br>
    // making use of overloaded member _<br>
    =C2=A0 std::cout<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test._(name) &lt;&lt; "\n"<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test._(age) &lt;&lt; "\n"<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test._(taille) &lt;&lt; "\n"<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test._(liste_t).size() &lt;&lt; std::endl;<=
br>
    <br>
    // making use of overloaded member operator()<br>
    =C2=A0 std::cout<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test(name) &lt;&lt; "\n"<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test(age) &lt;&lt; "\n"<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test(taille) &lt;&lt; "\n"<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test(liste_t).size() &lt;&lt; std::endl;<br=
>
    <br>
    // Using the operator tuple % attribute_key<br>
    <br>
    =C2=A0 std::cout<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test%name &lt;&lt; "\n"<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test%age &lt;&lt; "\n"<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test%taille &lt;&lt; "\n"<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; (test%liste_t).size() &lt;&lt; std::endl;<b=
r>
    <br>
    // Using the attribute_key operator ()<br>
    <br>
    =C2=A0 std::cout<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; name(test) &lt;&lt; "\n"<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; age(test) &lt;&lt; "\n"<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; taille(test) &lt;&lt; "\n"<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; liste(test).size() &lt;&lt; std::endl;<br>
    <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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--------------000006040803090909080405--

.


Author: Jean-Bernard Jansen <jeanbernard.jansen@gmail.com>
Date: Mon, 11 May 2015 12:47:31 +0200
Raw View
--f46d044281000cb7300515cc1cf6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello Vicente

Thank you very much for your interest about this work.

What you propose is actually doable, and is quite similar to what we can
found in this project <https://github.com/matt-42/iod>, which basically
does the same thing. I am a little bit reluctant to add this feature for a
very particular reason. Using static instances as you propose adds a
problem : you have static symbols to manage, thus leading to potential
conflicts between different compilation units. Those problems can be solved
but extra care about them is needed. For instance, you used an anonymous
namespace. It works, but duplicates every static instance in every
compilation unit using them. This adds unused data in the resulting
compiled code. When using declared (but NOT defined) types, no extra data
is added.

The main point of my particular implementation is to avoid static instances
as much as possible (cannot be avoided when you want to use runtime
introspection, obviously). This allows to use a syntax with wich you dont
even have to declare attribute names before using them.


auto test =3D make_named_tuple(
      _<"nom"_h>() =3D std::string("Roger")
      , _<"age"_h>() =3D 47
      , _<"taille"_h>() =3D 1.92
      , _<"liste"_h>() =3D std::vector<int>({1,2,3})
      );

What is your opinion on this point ? My mind is always open to changes, and
I do like the proposal about using key selector function to access members.
This really is elegant, I'll think about it.

Best regards
JB




On Sat, May 9, 2015 at 6:54 PM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:

>  Le 13/07/14 17:34, Jean-Bernard Jansen a =C3=A9crit :
>
>     Hello guys
>
>  This post will sure be of interest to @German Diago. I drastically
> improved my named tuple prototype since the last time. Changes includes:
>  - More generic API, easier to use.
>  - New internal storage method : base on a std::stuple instead of a
> recursive class hierachy, allowing for nice and fast interactions with
> std::tuple.
>  - The hash collision problem has been solved : if two members happen to
> have the same id, name or hash, the compilation will fail.
>  - Smaller code, easier to read.
>
>  Enjoy code and examples here: https://github.com/duckie/named_tuple.
>
>
>  Hi,
>
> even if this is  an old post, I find this library quite interesting.
>
> I like a lot
> * the function syntax to identify the attribute holder int(age),
>
> I like, but less
> * the named parameter syntax _<name> =3D val
> * the selector syntax tuple. _<name>
>
> Just wondering if you could add in addition to attributes_holder,
> attributes_key. An attribute_key instance could have a name.
>  E.g.
>
>     constexpr struct name_t : attribute_key<name_t> {} name;
>
>
> This could help to replace _<name>=3Dval by  *name=3Dval*.
>
> template <class Id, class T>
> auto attribute_key<Id>::operator=3D(attibute_key<Id>, T val) {return
> attribute_helper::_<Id>=3Dval; }
>
> The member _ could also be overloaded with attribute_key<name_t>
> *tpl._(name).*
>
> template <class Id>
> auto named_tuple::_(attibute_key<Id>) {return attribute_helper::_<Id>(); =
}
>
> or the operator() *tpl(name).*
>
> Alternatively an overload for the operator% on tuple and
> attribute_key<name> *tpl%name*.
>
> template <class NamedTuple, class Id>
> auto operator%(NamedTuple const& tpl, attibute_key<Id>) {return
> tpl._<Id>(); }
>
> Last the attribute_key could be seen as a key selector function
> *name(tml)*.
>
> template <class NamedTuple>
> auto attibute_key<Id>::operator()(NamedTuple const& tpl) {return
> tpl._<Id>(); }
>
>
> The following example
>
> namespace {
> struct name;
> struct age;
> struct taille;
> struct liste;
> }
>
> int main() {
>   auto test =3D make_named_tuple(
>       _<name>() =3D std::string("Roger")
>       , _<age>() =3D 47
>       , _<taille>() =3D 1.92
>       , _<liste>() =3D std::vector<int>({1,2,3})
>       );
>
>   std::cout
>     << test._<name>() << "\n"
>     << test._<age>() << "\n"
>     << test._<taille>() << "\n"
>     << test._<liste>().size() << std::endl;
>
>
> could be transformed using the new attribute_key as follows
>
> namespace {
>     constexpr struct name_t : attribute_key<name_t> {} name;
>     constexpr struct age_t : attribute_key<age_t> {} age;
>     constexpr struct taille_t : attribute_key<taille_t> {} taille;
>     constexpr struct liste_t : attribute_key<liste_t> {} liste;
> }
>
> int main() {
>
> // No need to use the artificial _<name> =3D, name =3Dis enough
>
>   auto test =3D make_named_tuple(
>         name =3D std::string("Roger")
>       , age =3D 47
>       , taille =3D 1.92
>       , liste =3D std::vector<int>({1,2,3})
>       );
>
> // However, here we need the type, name_t :(
>
>   std::cout
>     << test._<name_t>() << "\n"
>     << test._<age_t>() << "\n"
>     << test._<taille_t>() << "\n"
>     << test._<liste_t>().size() << std::endl;
>
> // making use of overloaded member _
>   std::cout
>     << test._(name) << "\n"
>     << test._(age) << "\n"
>     << test._(taille) << "\n"
>     << test._(liste_t).size() << std::endl;
>
> // making use of overloaded member operator()
>   std::cout
>     << test(name) << "\n"
>     << test(age) << "\n"
>     << test(taille) << "\n"
>     << test(liste_t).size() << std::endl;
>
> // Using the operator tuple % attribute_key
>
>   std::cout
>     << test%name << "\n"
>     << test%age << "\n"
>     << test%taille << "\n"
>     << (test%liste_t).size() << std::endl;
>
> // Using the attribute_key operator ()
>
>   std::cout
>     << name(test) << "\n"
>     << age(test) << "\n"
>     << taille(test) << "\n"
>     << liste(test).size() << std::endl;
>
> }
>
> Vicente
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/N-kIXNrkTUk/=
unsubscribe
> .
> To unsubscribe from this group and all its topics, 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
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=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 http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><div><div><div><div>Hello Vicente<br></div><br></div>Thank=
 you very much for your interest about this work.<br><br></div>What you pro=
pose is actually doable, and is quite similar to what we can found <a href=
=3D"https://github.com/matt-42/iod">in this project</a>, which basically do=
es the same thing. I am a little bit reluctant to add this feature for a ve=
ry particular reason. Using static instances as you propose adds a problem =
: you have static symbols to manage, thus leading to potential conflicts be=
tween different compilation units. Those problems can be solved but extra c=
are about them is needed. For instance, you used an anonymous namespace. It=
 works, but duplicates every static instance in every compilation unit usin=
g them. This adds unused data in the resulting compiled code. When using de=
clared (but NOT defined) types, no extra data is added.<br><br></div><div>T=
he main point of my particular implementation is to avoid static instances =
as much as possible (cannot be avoided when you want to use runtime introsp=
ection, obviously). This allows to use a syntax with wich you dont even hav=
e to declare attribute names before using them.<br><br><br>auto test =3D ma=
ke_named_tuple( <br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 _&lt;&quot;nom&quot;_h&g=
t;() =3D std::string(&quot;Roger&quot;)<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ,=
 _&lt;&quot;age&quot;_h&gt;() =3D 47<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , _&=
lt;&quot;taille&quot;_h&gt;() =3D 1.92<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , =
_&lt;&quot;liste&quot;_h&gt;() =3D std::vector&lt;int&gt;({1,2,3})<br>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 );<br><br></div><div>What is your opinion on th=
is point ? My mind is always open to changes, and I do like the proposal ab=
out using key selector function to access members. This really is elegant, =
I&#39;ll think about it.<br><br></div><div>Best regards<br></div><div>JB<br=
></div><div><br></div><div><br></div><div><br></div></div><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote">On Sat, May 9, 2015 at 6:54 PM, Vi=
cente J. Botet Escriba <span dir=3D"ltr">&lt;<a href=3D"mailto:vicente.bote=
t@wanadoo.fr" target=3D"_blank">vicente.botet@wanadoo.fr</a>&gt;</span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div>Le 13/07/14 17:34, Jean-Bernard Jansen
      a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>
            <div>
              <div>
                <div>
                  <div>
                    <div>Hello guys<br>
                      <br>
                    </div>
                    This post will sure be of interest to @German Diago.
                    I drastically improved my named tuple prototype
                    since the last time. Changes includes:<br>
                  </div>
                </div>
                - More generic API, easier to use.<br>
              </div>
              - New internal storage method : base on a std::stuple
              instead of a recursive class hierachy, allowing for nice
              and fast interactions with std::tuple.<br>
            </div>
            - The hash collision problem has been solved : if two
            members happen to have the same id, name or hash, the
            compilation will fail.<br>
          </div>
          - Smaller code, easier to read.<br>
          <br>
        </div>
        Enjoy code and examples here: <a href=3D"https://github.com/duckie/=
named_tuple" target=3D"_blank">https://github.com/duckie/named_tuple</a>.<b=
r>
        <br>
        <br>
      </div>
    </blockquote>
    Hi,<br>
    <br>
    even if this is=C2=A0 an old post, I find this library quite interestin=
g.<br>
    <br>
    I like a lot<br>
    * the function syntax to identify the attribute holder int(age),<br>
    <br>
    I like, but less<br>
    * the named parameter syntax _&lt;name&gt; =3D val<br>
    * the selector syntax tuple. _&lt;name&gt;<br>
    <br>
    Just wondering if you could add in addition to attributes_holder,
    attributes_key. An attribute_key instance could have a name.<br>
    =C2=A0E.g.<br>
    <br>
    =C2=A0=C2=A0=C2=A0 constexpr struct name_t : attribute_key&lt;name_t&gt=
; {} name;<br>
    <br>
    <br>
    This could help to replace _&lt;name&gt;=3Dval by=C2=A0 <b>name=3Dval</=
b>.<br>
    <br>
    template &lt;class Id, class T&gt;<br>
    auto attribute_key&lt;Id&gt;::operator=3D(attibute_key&lt;Id&gt;, T
    val) {return attribute_helper::_&lt;Id&gt;=3Dval; }<br>
    <br>
    The member _ could also be overloaded with
    attribute_key&lt;name_t&gt; <b>tpl._(name).</b><br>
    <br>
    template &lt;class Id&gt;<br>
    auto named_tuple::_(attibute_key&lt;Id&gt;) {return
    attribute_helper::_&lt;Id&gt;(); }<br>
    <br>
    or the operator() <b>tpl(name).</b><br>
    <br>
    Alternatively an overload for the operator% on tuple and
    attribute_key&lt;name&gt; <b>tpl%name</b>.<br>
    <br>
    template &lt;class NamedTuple, class Id&gt;<br>
    auto operator%(NamedTuple const&amp; tpl, attibute_key&lt;Id&gt;)
    {return tpl._&lt;Id&gt;(); }<br>
    <br>
    Last the attribute_key could be seen as a key selector function <b>name=
(tml)</b>.<br>
    <br>
    template &lt;class NamedTuple&gt;<br>
    auto attibute_key&lt;Id&gt;::operator()(NamedTuple const&amp; tpl)
    {return tpl._&lt;Id&gt;(); }<br>
    <br>
    <br>
    The following example<br>
    <br>
    namespace {<br>
    struct name;<br>
    struct age;<br>
    struct taille;<br>
    struct liste;<br>
    }<br>
    <br>
    int main() {<br>
    =C2=A0 auto test =3D make_named_tuple(<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 _&lt;name&gt;() =3D std::string(&quot;Ro=
ger&quot;)<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , _&lt;age&gt;() =3D 47<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , _&lt;taille&gt;() =3D 1.92<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , _&lt;liste&gt;() =3D std::vector&lt;in=
t&gt;({1,2,3})<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 );<br>
    <br>
    =C2=A0 std::cout<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test._&lt;name&gt;() &lt;&lt; &quot;\n&quot=
;<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test._&lt;age&gt;() &lt;&lt; &quot;\n&quot;=
<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test._&lt;taille&gt;() &lt;&lt; &quot;\n&qu=
ot;<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test._&lt;liste&gt;().size() &lt;&lt; std::=
endl;<br>
    <br>
    <br>
    could be transformed using the new attribute_key as follows<br>
    <br>
    namespace {<br>
    =C2=A0=C2=A0=C2=A0 constexpr struct name_t : attribute_key&lt;name_t&gt=
; {} name;<br>
    =C2=A0=C2=A0=C2=A0 constexpr struct age_t : attribute_key&lt;age_t&gt; =
{} age;<br>
    =C2=A0=C2=A0=C2=A0 constexpr struct taille_t : attribute_key&lt;taille_=
t&gt; {}
    taille;<br>
    =C2=A0=C2=A0=C2=A0 constexpr struct liste_t : attribute_key&lt;liste_t&=
gt; {}
    liste;<br>
    }<br>
    <br>
    int main() {<br>
    <br>
    // No need to use the artificial _&lt;name&gt; =3D, name =3Dis enough<b=
r>
    <br>
    =C2=A0 auto test =3D make_named_tuple(<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 name =3D std::string(&quot;R=
oger&quot;)<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , age =3D 47<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , taille =3D 1.92<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , liste =3D std::vector&lt;int&gt;({1,2,=
3})<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 );<br>
    <br>
    // However, here we need the type, name_t :(<br>
    <br>
    =C2=A0 std::cout<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test._&lt;name_t&gt;() &lt;&lt; &quot;\n&qu=
ot;<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test._&lt;age_t&gt;() &lt;&lt; &quot;\n&quo=
t;<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test._&lt;taille_t&gt;() &lt;&lt; &quot;\n&=
quot;<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test._&lt;liste_t&gt;().size() &lt;&lt; std=
::endl;<br>
    <br>
    // making use of overloaded member _<br>
    =C2=A0 std::cout<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test._(name) &lt;&lt; &quot;\n&quot;<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test._(age) &lt;&lt; &quot;\n&quot;<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test._(taille) &lt;&lt; &quot;\n&quot;<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test._(liste_t).size() &lt;&lt; std::endl;<=
br>
    <br>
    // making use of overloaded member operator()<br>
    =C2=A0 std::cout<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test(name) &lt;&lt; &quot;\n&quot;<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test(age) &lt;&lt; &quot;\n&quot;<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test(taille) &lt;&lt; &quot;\n&quot;<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test(liste_t).size() &lt;&lt; std::endl;<br=
>
    <br>
    // Using the operator tuple % attribute_key<br>
    <br>
    =C2=A0 std::cout<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test%name &lt;&lt; &quot;\n&quot;<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test%age &lt;&lt; &quot;\n&quot;<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; test%taille &lt;&lt; &quot;\n&quot;<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; (test%liste_t).size() &lt;&lt; std::endl;<b=
r>
    <br>
    // Using the attribute_key operator ()<br>
    <br>
    =C2=A0 std::cout<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; name(test) &lt;&lt; &quot;\n&quot;<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; age(test) &lt;&lt; &quot;\n&quot;<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; taille(test) &lt;&lt; &quot;\n&quot;<br>
    =C2=A0=C2=A0=C2=A0 &lt;&lt; liste(test).size() &lt;&lt; std::endl;<br>
    <br>
    }<span class=3D"HOEnZb"><font color=3D"#888888"><br>
    <br>
    Vicente<br>
  </font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">


<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/N-kIXNrkTUk/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/N-kIXNrkTUk=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--f46d044281000cb7300515cc1cf6--

.


Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Tue, 12 May 2015 00:11:48 +0200
Raw View
This is a multi-part message in MIME format.
--------------090603070509010504050702
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 11/05/15 12:47, Jean-Bernard Jansen a =C3=A9crit :
> Hello Vicente
>
Salut Jean-Bernard,
> Thank you very much for your interest about this work.
>
> What you propose is actually doable, and is quite similar to what we=20
> can found in this project <https://github.com/matt-42/iod>, which=20
> basically does the same thing.
A quick look let me think that there are a lot of macros there :(
> I am a little bit reluctant to add this feature for a very particular=20
> reason. Using static instances as you propose adds a problem : you=20
> have static symbols to manage, thus leading to potential conflicts=20
> between different compilation units. Those problems can be solved but=20
> extra care about them is needed. For instance, you used an anonymous=20
> namespace. It works, but duplicates every static instance in every=20
> compilation unit using them. This adds unused data in the resulting=20
> compiled code. When using declared (but NOT defined) types, no extra=20
> data is added.
The attribute_key class template has no data, so it has the same issues=20
that we have with nullopt, in_place, ..... There is a ODR issue, but we=20
can live with that, as soon as we don't use the address of these objects.
Note that I included them in an anonymous namespace as it was just an=20
example. I believe the users have other possibilities and the standard=20
doesn't need to solve this problem for them.
>
> The main point of my particular implementation is to avoid static=20
> instances as much as possible (cannot be avoided when you want to use=20
> runtime introspection, obviously). This allows to use a syntax with=20
> wich you dont even have to declare attribute names before using them.
>
>
> auto test =3D make_named_tuple(
>       _<"nom"_h>() =3D std::string("Roger")
>       , _<"age"_h>() =3D 47
>       , _<"taille"_h>() =3D 1.92
>       , _<"liste"_h>() =3D std::vector<int>({1,2,3})
>       );
>
> What is your opinion on this point ?
I see the advantage but I would prefer to have less noise

_<"nom"_h>()
    nom

even if this would require a declaration. Anyway the attribute key is no=20
more than syntactic sugar, and with the exception of the syntax=20
test._(name) and test(name) all the others could be added in a=20
non-intrusive way by the user on top of your proposal. If the fuction=20
call unification is adopted the function call name(test) could be used=20
also as test.name().
> My mind is always open to changes, and I do like the proposal about=20
> using key selector function to access members. This really is elegant,=20
> I'll think about it.
>

BTW, if tagged types were adopted in the standard, it would be nice to=20
use them also with std::experimental::any and=20
std::experimental::variant. What do you think of this possibility?

Vicente

P.S. What prevents to extend std::tuple with tagged types? Have you=20
found any backward compatibility issues or any lost of efficiency?

P.S..S Do you plan a have a first proposal for the next meeting?

--=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 http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--------------090603070509010504050702
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 bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 11/05/15 12:47, Jean-Bernard Jansen
      a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
cite=3D"mid:CALoNf_UeReAes5N_b=3D7OoQjKGO55sGCd2gs69LRiO8KwgymkjA@mail.gmai=
l.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>
            <div>
              <div>Hello Vicente<br>
              </div>
              <br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    Salut Jean-Bernard,<br>
    <blockquote
cite=3D"mid:CALoNf_UeReAes5N_b=3D7OoQjKGO55sGCd2gs69LRiO8KwgymkjA@mail.gmai=
l.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>Thank you very much for your interest about this work.<br>
            <br>
          </div>
          What you propose is actually doable, and is quite similar to
          what we can found <a moz-do-not-send=3D"true"
            href=3D"https://github.com/matt-42/iod">in this project</a>,
          which basically does the same thing.</div>
      </div>
    </blockquote>
    A quick look let me think that there are a lot of macros there :(<br>
    <blockquote
cite=3D"mid:CALoNf_UeReAes5N_b=3D7OoQjKGO55sGCd2gs69LRiO8KwgymkjA@mail.gmai=
l.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div> I am a little bit reluctant to add this feature for a very
          particular reason. Using static instances as you propose adds
          a problem : you have static symbols to manage, thus leading to
          potential conflicts between different compilation units. Those
          problems can be solved but extra care about them is needed.
          For instance, you used an anonymous namespace. It works, but
          duplicates every static instance in every compilation unit
          using them. This adds unused data in the resulting compiled
          code. When using declared (but NOT defined) types, no extra
          data is added.<br>
        </div>
      </div>
    </blockquote>
    The attribute_key class template has no data, so it has the same
    issues that we have with nullopt, in_place, ..... There is a ODR
    issue, but we can live with that, as soon as we don't use the
    address of these objects.<br>
    Note that I included them in an anonymous namespace as it was just
    an example. I believe the users have other possibilities and the
    standard doesn't need to solve this problem for them.<br>
    <blockquote
cite=3D"mid:CALoNf_UeReAes5N_b=3D7OoQjKGO55sGCd2gs69LRiO8KwgymkjA@mail.gmai=
l.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div>The main point of my particular implementation is to avoid
          static instances as much as possible (cannot be avoided when
          you want to use runtime introspection, obviously). This allows
          to use a syntax with wich you dont even have to declare
          attribute names before using them.<br>
          <br>
          <br>
          auto test =3D make_named_tuple( <br>
          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 _&lt;"nom"_h&gt;() =3D std::string=
("Roger")<br>
          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , _&lt;"age"_h&gt;() =3D 47<br>
          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , _&lt;"taille"_h&gt;() =3D 1.92<b=
r>
          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , _&lt;"liste"_h&gt;() =3D std::ve=
ctor&lt;int&gt;({1,2,3})<br>
          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 );<br>
          <br>
        </div>
        <div>What is your opinion on this point ? </div>
      </div>
    </blockquote>
    I see the advantage but I would prefer to have less noise<br>
    <br>
    <tt>_&lt;"nom"_h&gt;()</tt><tt><br>
    </tt><tt>=C2=A0=C2=A0 nom</tt><br>
    <br>
    even if this would require a declaration. Anyway the attribute key
    is no more than syntactic sugar, and with the exception of the
    syntax test._(name) and test(name) all the others could be added in
    a non-intrusive way by the user on top of your proposal. If the
    fuction call unification is adopted the function call name(test)
    could be used also as test.name().
    <blockquote
cite=3D"mid:CALoNf_UeReAes5N_b=3D7OoQjKGO55sGCd2gs69LRiO8KwgymkjA@mail.gmai=
l.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>My mind is always open to changes, and I do like the
          proposal about using key selector function to access members.
          This really is elegant, I'll think about it.<br>
          <br>
        </div>
      </div>
    </blockquote>
    <br>
    BTW, if tagged types were adopted in the standard, it would be nice
    to use them also with std::experimental::any and
    std::experimental::variant. What do you think of this possibility?<br>
    <br>
    Vicente <br>
    <br>
    P.S. What prevents to extend std::tuple with tagged types? Have you
    found any backward compatibility issues or any lost of efficiency?<br>
    <br>
    P.S..S Do you plan a have a first proposal for the next meeting?<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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--------------090603070509010504050702--

.


Author: Jean-Bernard Jansen <jeanbernard.jansen@gmail.com>
Date: Tue, 12 May 2015 01:27:14 +0200
Raw View
--f46d043c7f0a003b1a0515d6b964
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi again :)

Yes, the IOD project uses macros, and I dont like it either.

And yes, we could add what you propose just on top of what already exists :
this convinces me to give it a try very soon.

As for tagged types into the standard, I am convinced they will make their
way through one day or antoher. *Tuple addressing via type* was the first
baby step toward it. Yes I would gladly see them well integrated with
std::exprimental::any and std::experimental::variant. And to be fully
honest, I just see them as a step toward anonymous structures : a type
described by its members' names and types, but not by its own name. It
would spare the developpers a lot of conversion code to make libraries from
different sources interoperable. Thats what I had in mind while working on
the named tuple.

I dont think anything prevents from extending std::tuple with tagged types.
I did not use inheritance because the first implementation was not based on
std::tuple.. But now that you state it, it makes sense.

I did not plan to write a proposal for the next meeting, but I can spare
time to. I am not used to the exercise though, any advice on the matter
will be appreciated.

Thank you again for your toughts.

JB


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

>  Le 11/05/15 12:47, Jean-Bernard Jansen a =C3=A9crit :
>
>   Hello Vicente
>
>    Salut Jean-Bernard,
>
>  Thank you very much for your interest about this work.
>
>  What you propose is actually doable, and is quite similar to what we can
> found in this project <https://github.com/matt-42/iod>, which basically
> does the same thing.
>
> A quick look let me think that there are a lot of macros there :(
>
>  I am a little bit reluctant to add this feature for a very particular
> reason. Using static instances as you propose adds a problem : you have
> static symbols to manage, thus leading to potential conflicts between
> different compilation units. Those problems can be solved but extra care
> about them is needed. For instance, you used an anonymous namespace. It
> works, but duplicates every static instance in every compilation unit usi=
ng
> them. This adds unused data in the resulting compiled code. When using
> declared (but NOT defined) types, no extra data is added.
>
> The attribute_key class template has no data, so it has the same issues
> that we have with nullopt, in_place, ..... There is a ODR issue, but we c=
an
> live with that, as soon as we don't use the address of these objects.
> Note that I included them in an anonymous namespace as it was just an
> example. I believe the users have other possibilities and the standard
> doesn't need to solve this problem for them.
>
>
>  The main point of my particular implementation is to avoid static
> instances as much as possible (cannot be avoided when you want to use
> runtime introspection, obviously). This allows to use a syntax with wich
> you dont even have to declare attribute names before using them.
>
>
> auto test =3D make_named_tuple(
>       _<"nom"_h>() =3D std::string("Roger")
>       , _<"age"_h>() =3D 47
>       , _<"taille"_h>() =3D 1.92
>       , _<"liste"_h>() =3D std::vector<int>({1,2,3})
>       );
>
>  What is your opinion on this point ?
>
> I see the advantage but I would prefer to have less noise
>
> _<"nom"_h>()
>    nom
>
> even if this would require a declaration. Anyway the attribute key is no
> more than syntactic sugar, and with the exception of the syntax
> test._(name) and test(name) all the others could be added in a
> non-intrusive way by the user on top of your proposal. If the fuction cal=
l
> unification is adopted the function call name(test) could be used also as
> test.name().
>
>  My mind is always open to changes, and I do like the proposal about
> using key selector function to access members. This really is elegant, I'=
ll
> think about it.
>
>
> BTW, if tagged types were adopted in the standard, it would be nice to us=
e
> them also with std::experimental::any and std::experimental::variant. Wha=
t
> do you think of this possibility?
>
> Vicente
>
> P.S. What prevents to extend std::tuple with tagged types? Have you found
> any backward compatibility issues or any lost of efficiency?
>
> P.S..S Do you plan a have a first proposal for the next meeting?
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/N-kIXNrkTUk/=
unsubscribe
> .
> To unsubscribe from this group and all its topics, 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
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=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 http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><div><div><div><div>Hi again :)<br></div><div><br></div>Ye=
s, the IOD project uses macros, and I dont like it either.<br><br></div>And=
 yes, we could add what you propose just on top of what already exists : th=
is convinces me to give it a try very soon.<br><br></div>As for tagged type=
s into the standard, I am convinced they will make their way through one da=
y or antoher. <i>Tuple addressing via type</i> was the first baby step towa=
rd it. Yes I would gladly see them well integrated with std::exprimental::a=
ny and std::experimental::variant. And to be fully honest, I just see them =
as a step toward anonymous structures : a type described by its members&#39=
; names and types, but not by its own name. It would spare the developpers =
a lot of conversion code to make libraries from different sources interoper=
able. Thats what I had in mind while working on the named tuple.<br><br></d=
iv><div>I dont think anything prevents from extending std::tuple with tagge=
d types. I did not use inheritance because the first implementation was not=
 based on std::tuple.. But now that you state it, it makes sense.<br><br></=
div><div>I did not plan to write a proposal for the next meeting, but I can=
 spare time to. I am not used to the exercise though, any advice on the mat=
ter will be appreciated.<br><br></div><div>Thank you again for your toughts=
..<br><br></div><div>JB<br></div><div><br></div></div><div class=3D"gmail_ex=
tra"><br><div class=3D"gmail_quote">On Tue, May 12, 2015 at 12:11 AM, Vicen=
te J. Botet Escriba <span dir=3D"ltr">&lt;<a href=3D"mailto:vicente.botet@w=
anadoo.fr" target=3D"_blank">vicente.botet@wanadoo.fr</a>&gt;</span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div>Le 11/05/15 12:47, Jean-Bernard Jansen
      a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>
            <div>
              <div>Hello Vicente<br>
              </div>
              <br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    Salut Jean-Bernard,<span class=3D""><br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>Thank you very much for your interest about this work.<br>
            <br>
          </div>
          What you propose is actually doable, and is quite similar to
          what we can found <a href=3D"https://github.com/matt-42/iod" targ=
et=3D"_blank">in this project</a>,
          which basically does the same thing.</div>
      </div>
    </blockquote></span>
    A quick look let me think that there are a lot of macros there :(<span =
class=3D""><br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div> I am a little bit reluctant to add this feature for a very
          particular reason. Using static instances as you propose adds
          a problem : you have static symbols to manage, thus leading to
          potential conflicts between different compilation units. Those
          problems can be solved but extra care about them is needed.
          For instance, you used an anonymous namespace. It works, but
          duplicates every static instance in every compilation unit
          using them. This adds unused data in the resulting compiled
          code. When using declared (but NOT defined) types, no extra
          data is added.<br>
        </div>
      </div>
    </blockquote></span>
    The attribute_key class template has no data, so it has the same
    issues that we have with nullopt, in_place, ..... There is a ODR
    issue, but we can live with that, as soon as we don&#39;t use the
    address of these objects.<br>
    Note that I included them in an anonymous namespace as it was just
    an example. I believe the users have other possibilities and the
    standard doesn&#39;t need to solve this problem for them.<span class=3D=
""><br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div>The main point of my particular implementation is to avoid
          static instances as much as possible (cannot be avoided when
          you want to use runtime introspection, obviously). This allows
          to use a syntax with wich you dont even have to declare
          attribute names before using them.<br>
          <br>
          <br>
          auto test =3D make_named_tuple( <br>
          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 _&lt;&quot;nom&quot;_h&gt;() =3D s=
td::string(&quot;Roger&quot;)<br>
          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , _&lt;&quot;age&quot;_h&gt;() =3D=
 47<br>
          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , _&lt;&quot;taille&quot;_h&gt;() =
=3D 1.92<br>
          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , _&lt;&quot;liste&quot;_h&gt;() =
=3D std::vector&lt;int&gt;({1,2,3})<br>
          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 );<br>
          <br>
        </div>
        <div>What is your opinion on this point ? </div>
      </div>
    </blockquote></span>
    I see the advantage but I would prefer to have less noise<br>
    <br>
    <tt>_&lt;&quot;nom&quot;_h&gt;()</tt><tt><br>
    </tt><tt>=C2=A0=C2=A0 nom</tt><br>
    <br>
    even if this would require a declaration. Anyway the attribute key
    is no more than syntactic sugar, and with the exception of the
    syntax test._(name) and test(name) all the others could be added in
    a non-intrusive way by the user on top of your proposal. If the
    fuction call unification is adopted the function call name(test)
    could be used also as <a href=3D"http://test.name" target=3D"_blank">te=
st.name</a>().
    <span class=3D""><blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>My mind is always open to changes, and I do like the
          proposal about using key selector function to access members.
          This really is elegant, I&#39;ll think about it.<br>
          <br>
        </div>
      </div>
    </blockquote>
    <br></span>
    BTW, if tagged types were adopted in the standard, it would be nice
    to use them also with std::experimental::any and
    std::experimental::variant. What do you think of this possibility?<br>
    <br>
    Vicente <br>
    <br>
    P.S. What prevents to extend std::tuple with tagged types? Have you
    found any backward compatibility issues or any lost of efficiency?<br>
    <br>
    P.S..S Do you plan a have a first proposal for the next meeting?<br>
  </div><div class=3D"HOEnZb"><div class=3D"h5">


<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/N-kIXNrkTUk/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/N-kIXNrkTUk=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--f46d043c7f0a003b1a0515d6b964--

.


Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 13 May 2015 19:04:05 +0200
Raw View
This is a multi-part message in MIME format.
--------------010207080202060705030203
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 12/05/15 01:27, Jean-Bernard Jansen a =C3=A9crit :
> Hi again :)
>
> Yes, the IOD project uses macros, and I dont like it either.
>
> And yes, we could add what you propose just on top of what already=20
> exists : this convinces me to give it a try very soon.
>
> As for tagged types into the standard, I am convinced they will make=20
> their way through one day or antoher. /Tuple addressing via type/ was=20
> the first baby step toward it. Yes I would gladly see them well=20
> integrated with std::exprimental::any and std::experimental::variant.=20
> And to be fully honest, I just see them as a step toward anonymous=20
> structures : a type described by its members' names and types, but not=20
> by its own name.
This exist already.
struct {
     T1 n1;
     T2 n2;
}

I believe that what your are talking off is the ability to built them at=20
compile time.
> It would spare the developpers a lot of conversion code to make=20
> libraries from different sources interoperable. Thats what I had in=20
> mind while working on the named tuple.
I agree that this will be really a good thing, but I'm not a compiler=20
guy, so I couldn't prototype anything. Recently there were some that=20
were talking about introducing discriminated unions in C++. It would be=20
great if we were also able to built these discriminated unions at=20
compile time.

Waiting for that, we can take see what can be done in C++14/17 with a=20
library solution, even if the solution couldn't be as elegant as if it=20
was integrated on the language.
>
> I dont think anything prevents from extending std::tuple with tagged=20
> types. I did not use inheritance because the first implementation was=20
> not based on std::tuple.. But now that you state it, it makes sense.
>
I was not thinking about using inheritance, but to re-define std::tuple=20
in std::experimental::tuple extending it to take in account named/tag types=
..
> I did not plan to write a proposal for the next meeting, but I can=20
> spare time to. I am not used to the exercise though, any advice on the=20
> matter will be appreciated.
>
Let see this point off line then.

Vicente
> Thank you again for your toughts.
>
> JB
>
>
> On Tue, May 12, 2015 at 12:11 AM, Vicente J. Botet Escriba=20
> <vicente.botet@wanadoo.fr <mailto:vicente.botet@wanadoo.fr>> wrote:
>
>     Le 11/05/15 12:47, Jean-Bernard Jansen a =C3=A9crit :
>>     Hello Vicente
>>
>     Salut Jean-Bernard,
>>     Thank you very much for your interest about this work.
>>
>>     What you propose is actually doable, and is quite similar to what
>>     we can found in this project <https://github.com/matt-42/iod>,
>>     which basically does the same thing.
>     A quick look let me think that there are a lot of macros there :(
>>     I am a little bit reluctant to add this feature for a very
>>     particular reason. Using static instances as you propose adds a
>>     problem : you have static symbols to manage, thus leading to
>>     potential conflicts between different compilation units. Those
>>     problems can be solved but extra care about them is needed. For
>>     instance, you used an anonymous namespace. It works, but
>>     duplicates every static instance in every compilation unit using
>>     them. This adds unused data in the resulting compiled code. When
>>     using declared (but NOT defined) types, no extra data is added.
>     The attribute_key class template has no data, so it has the same
>     issues that we have with nullopt, in_place, ..... There is a ODR
>     issue, but we can live with that, as soon as we don't use the
>     address of these objects.
>     Note that I included them in an anonymous namespace as it was just
>     an example. I believe the users have other possibilities and the
>     standard doesn't need to solve this problem for them.
>>
>>     The main point of my particular implementation is to avoid static
>>     instances as much as possible (cannot be avoided when you want to
>>     use runtime introspection, obviously). This allows to use a
>>     syntax with wich you dont even have to declare attribute names
>>     before using them.
>>
>>
>>     auto test =3D make_named_tuple(
>>           _<"nom"_h>() =3D std::string("Roger")
>>           , _<"age"_h>() =3D 47
>>           , _<"taille"_h>() =3D 1.92
>>           , _<"liste"_h>() =3D std::vector<int>({1,2,3})
>>           );
>>
>>     What is your opinion on this point ?
>     I see the advantage but I would prefer to have less noise
>
>     _<"nom"_h>()
>        nom
>
>     even if this would require a declaration. Anyway the attribute key
>     is no more than syntactic sugar, and with the exception of the
>     syntax test._(name) and test(name) all the others could be added
>     in a non-intrusive way by the user on top of your proposal. If the
>     fuction call unification is adopted the function call name(test)
>     could be used also as test.name <http://test.name>().
>>     My mind is always open to changes, and I do like the proposal
>>     about using key selector function to access members. This really
>>     is elegant, I'll think about it.
>>
>
>     BTW, if tagged types were adopted in the standard, it would be
>     nice to use them also with std::experimental::any and
>     std::experimental::variant. What do you think of this possibility?
>
>     Vicente
>
>     P.S. What prevents to extend std::tuple with tagged types? Have
>     you found any backward compatibility issues or any lost of efficiency=
?
>
>     P.S..S Do you plan a have a first proposal for the next meeting?
>     --=20
>
>     ---
>     You received this message because you are subscribed to a topic in
>     the Google Groups "ISO C++ Standard - Future Proposals" group.
>     To unsubscribe from this topic, visit
>     https://groups.google.com/a/isocpp.org/d/topic/std-proposals/N-kIXNrk=
TUk/unsubscribe.
>     To unsubscribe from this group and all its topics, send an email
>     to std-proposals+unsubscribe@isocpp.org
>     <mailto:std-proposals+unsubscribe@isocpp.org>.
>     To post to this group, send email to std-proposals@isocpp.org
>     <mailto:std-proposals@isocpp.org>.
>     Visit this group at
>     http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>
> --=20
>
> ---
> You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send=20
> an email to std-proposals+unsubscribe@isocpp.org=20
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org=20
> <mailto:std-proposals@isocpp.org>.
> Visit this group at=20
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

--=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 http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--------------010207080202060705030203
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 bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 12/05/15 01:27, Jean-Bernard Jansen
      a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
cite=3D"mid:CALoNf_W4WSAsNn7=3D0=3DbZbp5c+LAc_SruHxM9_vu1eE-5gLxRPA@mail.gm=
ail.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>
            <div>
              <div>Hi again :)<br>
              </div>
              <div><br>
              </div>
              Yes, the IOD project uses macros, and I dont like it
              either.<br>
              <br>
            </div>
            And yes, we could add what you propose just on top of what
            already exists : this convinces me to give it a try very
            soon.<br>
            <br>
          </div>
          As for tagged types into the standard, I am convinced they
          will make their way through one day or antoher. <i>Tuple
            addressing via type</i> was the first baby step toward it.
          Yes I would gladly see them well integrated with
          std::exprimental::any and std::experimental::variant. And to
          be fully honest, I just see them as a step toward anonymous
          structures : a type described by its members' names and types,
          but not by its own name. </div>
      </div>
    </blockquote>
    This exist already. <br>
    struct {<br>
    =C2=A0=C2=A0=C2=A0 T1 n1;<br>
    =C2=A0=C2=A0=C2=A0 T2 n2;<br>
    }<br>
    <br>
    I believe that what your are talking off is the ability to built
    them at compile time. <br>
    <blockquote
cite=3D"mid:CALoNf_W4WSAsNn7=3D0=3DbZbp5c+LAc_SruHxM9_vu1eE-5gLxRPA@mail.gm=
ail.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>It would spare the developpers a lot of conversion code to
          make libraries from different sources interoperable. Thats
          what I had in mind while working on the named tuple.<br>
        </div>
      </div>
    </blockquote>
    I agree that this will be really a good thing, but I'm not a
    compiler guy, so I couldn't prototype anything. Recently there were
    some that were talking about introducing discriminated unions in
    C++. It would be great if we were also able to built these
    discriminated unions at compile time. <br>
    <br>
    Waiting for that, we can take see what can be done in C++14/17 with
    a library solution, even if the solution couldn't be as elegant as
    if it was integrated on the language.<br>
    <blockquote
cite=3D"mid:CALoNf_W4WSAsNn7=3D0=3DbZbp5c+LAc_SruHxM9_vu1eE-5gLxRPA@mail.gm=
ail.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div>I dont think anything prevents from extending std::tuple
          with tagged types. I did not use inheritance because the first
          implementation was not based on std::tuple.. But now that you
          state it, it makes sense.<br>
          <br>
        </div>
      </div>
    </blockquote>
    I was not thinking about using inheritance, but to re-define
    std::tuple in std::experimental::tuple extending it to take in
    account named/tag types.<br>
    <blockquote
cite=3D"mid:CALoNf_W4WSAsNn7=3D0=3DbZbp5c+LAc_SruHxM9_vu1eE-5gLxRPA@mail.gm=
ail.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>I did not plan to write a proposal for the next meeting,
          but I can spare time to. I am not used to the exercise though,
          any advice on the matter will be appreciated.<br>
          <br>
        </div>
      </div>
    </blockquote>
    Let see this point off line then.<br>
    <br>
    Vicente<br>
    <blockquote
cite=3D"mid:CALoNf_W4WSAsNn7=3D0=3DbZbp5c+LAc_SruHxM9_vu1eE-5gLxRPA@mail.gm=
ail.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>Thank you again for your toughts.<br>
          <br>
        </div>
        <div>JB<br>
        </div>
        <div><br>
        </div>
      </div>
      <div class=3D"gmail_extra"><br>
        <div class=3D"gmail_quote">On Tue, May 12, 2015 at 12:11 AM,
          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">vi=
cente.botet@wanadoo.fr</a>&gt;</span>
          wrote:<br>
          <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div bgcolor=3D"#FFFFFF" text=3D"#000000">
              <div>Le 11/05/15 12:47, Jean-Bernard Jansen a =C3=A9crit=C2=
=A0:<br>
              </div>
              <blockquote type=3D"cite">
                <div dir=3D"ltr">
                  <div>
                    <div>
                      <div>
                        <div>Hello Vicente<br>
                        </div>
                        <br>
                      </div>
                    </div>
                  </div>
                </div>
              </blockquote>
              Salut Jean-Bernard,<span class=3D""><br>
                <blockquote type=3D"cite">
                  <div dir=3D"ltr">
                    <div>
                      <div>Thank you very much for your interest about
                        this work.<br>
                        <br>
                      </div>
                      What you propose is actually doable, and is quite
                      similar to what we can found <a
                        moz-do-not-send=3D"true"
                        href=3D"https://github.com/matt-42/iod"
                        target=3D"_blank">in this project</a>, which
                      basically does the same thing.</div>
                  </div>
                </blockquote>
              </span> A quick look let me think that there are a lot of
              macros there :(<span class=3D""><br>
                <blockquote type=3D"cite">
                  <div dir=3D"ltr">
                    <div> I am a little bit reluctant to add this
                      feature for a very particular reason. Using static
                      instances as you propose adds a problem : you have
                      static symbols to manage, thus leading to
                      potential conflicts between different compilation
                      units. Those problems can be solved but extra care
                      about them is needed. For instance, you used an
                      anonymous namespace. It works, but duplicates
                      every static instance in every compilation unit
                      using them. This adds unused data in the resulting
                      compiled code. When using declared (but NOT
                      defined) types, no extra data is added.<br>
                    </div>
                  </div>
                </blockquote>
              </span> The attribute_key class template has no data, so
              it has the same issues that we have with nullopt,
              in_place, ..... There is a ODR issue, but we can live with
              that, as soon as we don't use the address of these
              objects.<br>
              Note that I included them in an anonymous namespace as it
              was just an example. I believe the users have other
              possibilities and the standard doesn't need to solve this
              problem for them.<span class=3D""><br>
                <blockquote type=3D"cite">
                  <div dir=3D"ltr">
                    <div><br>
                    </div>
                    <div>The main point of my particular implementation
                      is to avoid static instances as much as possible
                      (cannot be avoided when you want to use runtime
                      introspection, obviously). This allows to use a
                      syntax with wich you dont even have to declare
                      attribute names before using them.<br>
                      <br>
                      <br>
                      auto test =3D make_named_tuple( <br>
                      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 _&lt;"nom"_h&gt;() =3D=
 std::string("Roger")<br>
                      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , _&lt;"age"_h&gt;() =
=3D 47<br>
                      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , _&lt;"taille"_h&gt;(=
) =3D 1.92<br>
                      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , _&lt;"liste"_h&gt;()=
 =3D
                      std::vector&lt;int&gt;({1,2,3})<br>
                      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 );<br>
                      <br>
                    </div>
                    <div>What is your opinion on this point ? </div>
                  </div>
                </blockquote>
              </span> I see the advantage but I would prefer to have
              less noise<br>
              <br>
              <tt>_&lt;"nom"_h&gt;()</tt><tt><br>
              </tt><tt>=C2=A0=C2=A0 nom</tt><br>
              <br>
              even if this would require a declaration. Anyway the
              attribute key is no more than syntactic sugar, and with
              the exception of the syntax test._(name) and test(name)
              all the others could be added in a non-intrusive way by
              the user on top of your proposal. If the fuction call
              unification is adopted the function call name(test) could
              be used also as <a moz-do-not-send=3D"true"
                href=3D"http://test.name" target=3D"_blank">test.name</a>()=
..
              <span class=3D"">
                <blockquote type=3D"cite">
                  <div dir=3D"ltr">
                    <div>My mind is always open to changes, and I do
                      like the proposal about using key selector
                      function to access members. This really is
                      elegant, I'll think about it.<br>
                      <br>
                    </div>
                  </div>
                </blockquote>
                <br>
              </span> BTW, if tagged types were adopted in the standard,
              it would be nice to use them also with
              std::experimental::any and std::experimental::variant.
              What do you think of this possibility?<br>
              <br>
              Vicente <br>
              <br>
              P.S. What prevents to extend std::tuple with tagged types?
              Have you found any backward compatibility issues or any
              lost of efficiency?<br>
              <br>
              P.S..S Do you plan a have a first proposal for the next
              meeting?<br>
            </div>
            <div class=3D"HOEnZb">
              <div class=3D"h5">
                -- <br>
                <br>
                --- <br>
                You received this message because you are subscribed to
                a topic in the Google Groups "ISO C++ Standard - Future
                Proposals" group.<br>
                To unsubscribe from this topic, visit <a
                  moz-do-not-send=3D"true"
href=3D"https://groups.google.com/a/isocpp.org/d/topic/std-proposals/N-kIXN=
rkTUk/unsubscribe"
                  target=3D"_blank">https://groups.google.com/a/isocpp.org/=
d/topic/std-proposals/N-kIXNrkTUk/unsubscribe</a>.<br>
                To unsubscribe from this group and all its topics, send
                an email to <a moz-do-not-send=3D"true"
                  href=3D"mailto:std-proposals+unsubscribe@isocpp.org"
                  target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a=
>.<br>
                To post to this group, send email to <a
                  moz-do-not-send=3D"true"
                  href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank=
">std-proposals@isocpp.org</a>.<br>
                Visit this group at <a moz-do-not-send=3D"true"
                  href=3D"http://groups.google.com/a/isocpp.org/group/std-p=
roposals/"
                  target=3D"_blank">http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/</a>.<br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
      -- <br>
      <br>
      --- <br>
      You received this message because you are subscribed to the Google
      Groups "ISO C++ Standard - Future Proposals" group.<br>
      To unsubscribe from this group and stop receiving emails from it,
      send an email to <a moz-do-not-send=3D"true"
        href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+=
unsubscribe@isocpp.org</a>.<br>
      To post to this group, send email to <a moz-do-not-send=3D"true"
        href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</=
a>.<br>
      Visit this group at <a moz-do-not-send=3D"true"
        href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
>http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
    </blockquote>
    <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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--------------010207080202060705030203--

.