Topic: Reasoning about names
Author: Roland Bock <rbock@eudoxos.de>
Date: Mon, 23 Mar 2015 18:09:38 +0100
Raw View
Hi,
here is an idea I first talked about in a workshop at CppCon 2014 and
recently at the Munich C++ Meetup:
In templates we can use types and values as parameters. We cannot
specify names though.
But wouldn't it be cool to be able to parametrize templates with names? E.g.
// ------------------------
template<typename Type,
name Name, // New template parameter type
Type Value>
struct Foo
{
Type Name = Value;
};
// ------------------------
Ok, this may look boring, so how about a tuple with named members?
// ------------------------
template<typename... T>
struct named_tuple
{
typename T::type T::name;... // New expansion style
};
// ------------------------
It could be used with
// ------------------------
template<typename T, name X>
struct type_name
{
using type = T;
using name = X;
};
using my_struct =
named_tuple
<
type_name<int, `foo`>,
type_name<char, `bar`>
>;
auto ms = my_struct{7, 'c'};
ms.foo = 9;
// ------------------------
This is a much nicer user interface, when you are not targeting TMP. But
such a named tuple could (of course) also be used like a std::tuple,
too. For instance, std::get wouldn't be hard to specialize for a named
tuple.
With these mechanisms, it would also be possible to replace CRTP with
mixins in some scenarios.
I posted my ideas/use-cases in more detail here:
http://cpp.eudoxos.de/dreaming-of-names/
Please let me know what you think!
Regards,
Roland
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: gmisocpp@gmail.com
Date: Mon, 23 Mar 2015 12:35:57 -0700 (PDT)
Raw View
------=_Part_4726_841399902.1427139357193
Content-Type: multipart/alternative;
boundary="----=_Part_4727_228337419.1427139357193"
------=_Part_4727_228337419.1427139357193
Content-Type: text/plain; charset=UTF-8
Hi
I think a feature like this would be great.
I don't know if the feature should take that form though, but that's to be
explored.
The solution may be related to work meta data task group are doing I wonder.
I'm sure this has come up before somewhere, but I would like to be able to
make existing code more readable.
I would like to provide the ability for a class like pair, to be able
to alias first_name with first and last_name with second.
If no name is given, pair should work as normal.
std::pair<string first_name, string last_name> name{"bob", "jones"};
printf("Hello %s %s\n", name.first_name.c_str(), name.second_name.c_str());
But mostly I wish for a feature that would make people use pair and tuple a
lot less, that's what I really want!
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_4727_228337419.1427139357193
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi</div><div><br></div><div>I think a feature like th=
is would be great.</div><div>I don't know if the feature should take that f=
orm though, but that's to be explored.</div><div>The solution may be relate=
d to work meta data task group are doing I wonder.</div><div><br></div=
><div>I'm sure this has come up before somewhere, but I would like&nbs=
p;to be able to make existing code more readable.</div><div>I would li=
ke to provide the ability for a class like pair, to be able to&nb=
sp;alias first_name with first and last_name with second.</div><d=
iv>If no name is given, pair should work as normal.</div><div><br></di=
v><div>std::pair<string first_name, string last_name> name{"bob", "jo=
nes"};</div><div>printf("Hello %s %s\n", name.first_name.c_str(), name.seco=
nd_name.c_str());</div><div><br></div><div>But mostly I wish for a feature =
that would make people use pair and tuple a lot less, that's what I re=
ally want!</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" 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 />
------=_Part_4727_228337419.1427139357193--
------=_Part_4726_841399902.1427139357193--
.
Author: Douglas Boffey <douglas.boffey@gmail.com>
Date: Mon, 23 Mar 2015 20:04:45 +0000
Raw View
I, personally, don't like the idea of quoted strings used for
identifiers, but, I suppose, that's just a bikeshed.
On 3/23/15, gmisocpp@gmail.com <gmisocpp@gmail.com> wrote:
> Hi
>
> I think a feature like this would be great.
> I don't know if the feature should take that form though, but that's to be
> explored.
> The solution may be related to work meta data task group are doing I
> wonder.
>
> I'm sure this has come up before somewhere, but I would like to be able to
> make existing code more readable.
> I would like to provide the ability for a class like pair, to be able
> to alias first_name with first and last_name with second.
> If no name is given, pair should work as normal.
>
> std::pair<string first_name, string last_name> name{"bob", "jones"};
> printf("Hello %s %s\n", name.first_name.c_str(), name.second_name.c_str());
>
> But mostly I wish for a feature that would make people use pair and tuple a
>
> lot less, that's what I really want!
>
> --
>
> ---
> 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
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: gmisocpp@gmail.com
Date: Mon, 23 Mar 2015 13:57:54 -0700 (PDT)
Raw View
------=_Part_2535_2017406612.1427144275064
Content-Type: multipart/alternative;
boundary="----=_Part_2536_2081109048.1427144275064"
------=_Part_2536_2081109048.1427144275064
Content-Type: text/plain; charset=UTF-8
On Tuesday, March 24, 2015 at 9:04:47 AM UTC+13, Douglas Boffey wrote:
>
> I, personally, don't like the idea of quoted strings used for
> identifiers, but, I suppose, that's just a bikeshed.
>
I don't know if you were referring to the OP or me with that comment but I
agree with you and am not suggesting quoted strings.
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2536_2081109048.1427144275064
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Tuesday, March 24, 2015 at 9:04:47 AM UTC+13, Dougl=
as Boffey wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px =
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border=
-left-width: 1px; border-left-style: solid;">I, personally, don't like the =
idea of quoted strings used for
<br>identifiers, but, I suppose, that's just a bikeshed.
<br></blockquote><div><br></div><div>I don't know if you were referring to =
the OP or me with that comment but I agree with you and am not suggesting q=
uoted strings.</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" 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 />
------=_Part_2536_2081109048.1427144275064--
------=_Part_2535_2017406612.1427144275064--
.
Author: Douglas Boffey <douglas.boffey@gmail.com>
Date: Mon, 23 Mar 2015 21:43:29 +0000
Raw View
It was in reference to the OP.
On 3/23/15, gmisocpp@gmail.com <gmisocpp@gmail.com> wrote:
>
> On Tuesday, March 24, 2015 at 9:04:47 AM UTC+13, Douglas Boffey wrote:
>>
>> I, personally, don't like the idea of quoted strings used for
>> identifiers, but, I suppose, that's just a bikeshed.
>>
>
> I don't know if you were referring to the OP or me with that comment but I
> agree with you and am not suggesting quoted strings.
>
> --
>
> ---
> 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
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Mon, 23 Mar 2015 23:02:47 +0100
Raw View
You're referring to something like
type_name<int, `foo`>
?
I haven't set my mind on the syntax yet. I used forward ticks since they
aren't used in C++ yet. If that's the only question you have, go ahead
bikeshedding :-)
Here are some options I thought of
type_name<int, `foo`>
type_name<int, $foo> // $ is already used by MSVC
type_name<int, #foo> // Might confuse preprocessor
type_name<int, @foo> // OK?
Personally, I like the forward ticks best, but @foo looks good to me,
too, and I am sure there will be more suggestions :-)
On 2015-03-23 21:04, Douglas Boffey wrote:
> I, personally, don't like the idea of quoted strings used for
> identifiers, but, I suppose, that's just a bikeshed.
>
> On 3/23/15, gmisocpp@gmail.com <gmisocpp@gmail.com> wrote:
>> Hi
>>
>> I think a feature like this would be great.
>> I don't know if the feature should take that form though, but that's to be
>> explored.
>> The solution may be related to work meta data task group are doing I
>> wonder.
>>
>> I'm sure this has come up before somewhere, but I would like to be able to
>> make existing code more readable.
>> I would like to provide the ability for a class like pair, to be able
>> to alias first_name with first and last_name with second.
>> If no name is given, pair should work as normal.
>>
>> std::pair<string first_name, string last_name> name{"bob", "jones"};
>> printf("Hello %s %s\n", name.first_name.c_str(), name.second_name.c_str());
>>
>> But mostly I wish for a feature that would make people use pair and tuple a
>>
>> lot less, that's what I really want!
>>
>> --
>>
>> ---
>> 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
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Tue, 24 Mar 2015 06:34:11 +0100
Raw View
This is a multi-part message in MIME format.
--------------040403000108000600000002
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 23/03/15 18:09, Roland Bock a =C3=A9crit :
> Hi,
>
> here is an idea I first talked about in a workshop at CppCon 2014 and
> recently at the Munich C++ Meetup:
>
>
> In templates we can use types and values as parameters. We cannot
> specify names though.
>
> But wouldn't it be cool to be able to parametrize templates with names? E=
..g.
>
> // ------------------------
> template<typename Type,
> name Name, // New template parameter type
> Type Value>
> struct Foo
> {
> Type Name =3D Value;
> };
> // ------------------------
>
>
> Ok, this may look boring, so how about a tuple with named members?
I'm all for been able to do something like that.
An alternative could be to be able to define some kind of data members=20
indexed by a type (something related to template variables instances).
template<typename Type,
typename Name, // New template parameter type
Type Value>
struct Foo
{
Type _<Name> =3D Value;
};
The use of _ is intended, meaning the data member name is not significant.
>
> // ------------------------
> template<typename... T>
> struct named_tuple
> {
> typename T::type T::name;... // New expansion style
> };
template<typename... T>
struct named_tuple
{
typename T::type _<T::name>;... // New expansion style
};
> // ------------------------
>
> It could be used with
>
> // ------------------------
> template<typename T, name X>
> struct type_name
> {
> using type =3D T;
> using name =3D X;
> };
>
> using my_struct =3D
> named_tuple
> <
> type_name<int, `foo`>,
> type_name<char, `bar`>
> >;
>
> auto ms =3D my_struct{7, 'c'};
> ms.foo =3D 9;
> // ------------------------
// ------------------------
template<typename T, typename X>
struct type_name
{
using type =3D T;
using name =3D X;
};
struct foo {};
struct bar {};
using my_struct =3D
named_tuple
<
type_name<int, foo>,
type_name<char, bar>
>;
auto ms =3D my_struct{7, 'c'};
ms._<foo> =3D 9;
The interface is not so nice, it needs to declare the structs foo and=20
bar and use ms._<foo> instead of ms.foo.
However it doesn't need to introduce a new name keyword and a new kind=20
of symbols.
Another limitation of my alternative is that it doesn't work well with=20
struct. Your example for StructOfArrays would need a struct S indexed by=20
types
structS{
int_<a>;
int_<b>;
int_<c>;
};
template<typenameS,
typename...Ms>
structStructOfArrays
{
std::vector<Ms::type>_<Ms::name>;...// the vectors
// example part of the SOA interface
voidpush_back(constS&_soa_arg)
{
// Assuming N4191, Fold expressions
(_<Ms::name>.push_back(_soa_arg._<Ms::name>,...);
}
};
In some way we can say that your new name is some kind of syntactic=20
sugar of my alternative
`foo`
will expand to
__name::foo
where
namespapce __name {
struct foo {};
}
template < typename Type, name Name>
struct X {
Type Name;
};
to
template < typename Type, typename Name>
struct X {
Type _<Name>;
};
and
ms.foo
to
ms._<__name::foo>
We will need also that the struct
structS{
inta;
intb;
intc;
};
should be equivalent to
structS{
int_<__name::a>;
int_<__name::b>;
int_<__name::c>;
};
and that
structS{
int_<__name::a>;
inta;
};
would report a compile error.
I would try to translate the mixin example:
template <typename Derived>
struct mixin
{
using name =3D __name::check; // name of the mixin // [1]
Derived* _derived;
template <typename T>
bool operator()(const T& t) const // mixin is callable
{
return _derived->_data =3D=3D t;
}
};
template<template< class> class ... Mixin> // Made this variadic for fun
struct MyClass
{
Mixin<MyClass> _<Mixin<MyClass>::name> =3D {this};... \\ [2]
int _data =3D 7;
};
In [1] declare name as been just a tag type.
In [2] we use the Mixin<D>::name type as template of the data member=20
indexed variable _.
Resuming the two approaches could be seen as two sides of the same coin.=20
Your side gives a more friendly syntax, mine is closer to the current=20
language semantic once extended with member data indexed by types, of=20
course.
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/.
--------------040403000108000600000002
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 23/03/15 18:09, Roland Bock a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote cite=3D"mid:551048D2.2070907@eudoxos.de" type=3D"cite">
<pre wrap=3D"">Hi,
here is an idea I first talked about in a workshop at CppCon 2014 and
recently at the Munich C++ Meetup:
In templates we can use types and values as parameters. We cannot
specify names though.
But wouldn't it be cool to be able to parametrize templates with names? E.g=
..
// ------------------------
template<typename Type,=20
name Name, // New template parameter type
Type Value>
struct Foo
{
Type Name =3D Value;
};
// ------------------------
Ok, this may look boring, so how about a tuple with named members?
</pre>
</blockquote>
<br>
I'm all for been able to do something like that.<br>
An alternative could be to be able to define some kind of data
members indexed by a type (something related to template variables
instances).<br>
<br>
<pre wrap=3D"">template<typename Type,=20
typename Name, // New template parameter type
Type Value>
struct Foo
{
Type _<Name> =3D Value;
};
</pre>
<br>
The use of _ is intended, meaning the data member name is not
significant.<br>
<br>
<br>
<blockquote cite=3D"mid:551048D2.2070907@eudoxos.de" type=3D"cite">
<pre wrap=3D"">
// ------------------------
template<typename... T>
struct named_tuple
{
typename T::type T::name;... // New expansion style
};</pre>
</blockquote>
<br>
<pre wrap=3D"">template<typename... T>
struct named_tuple
{
typename T::type _<T::name>;... // New expansion style
};
</pre>
<blockquote cite=3D"mid:551048D2.2070907@eudoxos.de" type=3D"cite">
<pre wrap=3D"">
// ------------------------
It could be used with
// ------------------------
template<typename T, name X>
struct type_name
{
using type =3D T;
using name =3D X;
};
using my_struct =3D=20
named_tuple
<
type_name<int, `foo`>,
type_name<char, `bar`>
>;
auto ms =3D my_struct{7, 'c'};
ms.foo =3D 9;
// ------------------------</pre>
</blockquote>
<br>
<pre wrap=3D"">// ------------------------
template<typename T, typename X>
struct type_name
{
using type =3D T;
using name =3D X;
};
struct foo {};
struct bar {};
using my_struct =3D=20
named_tuple
<
type_name<int, foo>,
type_name<char, bar>
>;
auto ms =3D my_struct{7, 'c'};
ms._<foo> =3D 9;
</pre>
<br>
The interface is not so nice, it needs to declare the structs foo
and bar and use ms._<foo> instead of ms.foo.<br>
<br>
However it doesn't need to introduce a new name keyword and a new
kind of symbols.<br>
<br>
Another limitation of my alternative is that it doesn't work well
with struct. Your example for <span class=3D"crayon-h"></span><span
class=3D"crayon-e">StructOfArrays would need a struct S indexed by
types</span><br>
<br>
<meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8=
">
<div class=3D"crayon-pre" style=3D"font-size: 12px !important;
line-height: 15px !important; -moz-tab-size:4; -o-tab-size:4;
-webkit-tab-size:4; tab-size:4;">
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba2772971485-1"><sp=
an
class=3D"crayon-t">struct</span><span class=3D"crayon-h"> </span>=
<span
class=3D"crayon-e">S</span><span class=3D"crayon-h"> </span><span
class=3D"crayon-sy">{</span></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba2772971485-2"><span class=3D"crayon-h">=C2=
=A0=C2=A0=C2=A0=C2=A0</span><span
class=3D"crayon-t">int</span><span class=3D"crayon-h"> _<</spa=
n><span
class=3D"crayon-v">a></span><span class=3D"crayon-sy">;</span>=
</div>
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba2772971485-3"><sp=
an
class=3D"crayon-h">=C2=A0=C2=A0=C2=A0=C2=A0</span><span class=3D"=
crayon-t">int</span><span
class=3D"crayon-h"> </span><span class=3D"crayon-v"><span
class=3D"crayon-h">_<</span><span class=3D"crayon-v"></span>=
b></span><span
class=3D"crayon-sy">;</span></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba2772971485-4"><span class=3D"crayon-h">=C2=
=A0=C2=A0=C2=A0=C2=A0</span><span
class=3D"crayon-t">int</span><span class=3D"crayon-h"> </span><sp=
an
class=3D"crayon-v"><span class=3D"crayon-h">_<</span><span
class=3D"crayon-v"></span>c></span><span class=3D"crayon-sy"=
>;</span></div>
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba2772971485-5"><sp=
an
class=3D"crayon-sy">}</span><span class=3D"crayon-sy">;</span></d=
iv>
</div>
<br>
<meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8=
">
<div class=3D"crayon-pre" style=3D"font-size: 12px !important;
line-height: 15px !important; -moz-tab-size:4; -o-tab-size:4;
-webkit-tab-size:4; tab-size:4;">
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba9280752556-1"><sp=
an
class=3D"crayon-v">template</span><span class=3D"crayon-o"><</=
span><span
class=3D"crayon-i">typename</span><span class=3D"crayon-h"> </spa=
n><span
class=3D"crayon-v">S</span><span class=3D"crayon-sy">,</span><spa=
n
class=3D"crayon-h"> </span></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba9280752556-2"><span class=3D"crayon-h">=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
</span><span class=3D"crayon-v">typename</span><span
class=3D"crayon-sy">.</span><span class=3D"crayon-sy">.</span><sp=
an
class=3D"crayon-sy">.</span><span class=3D"crayon-h"> </span><spa=
n
class=3D"crayon-e">Ms</span><span class=3D"crayon-o">></span><=
/div>
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba9280752556-3"><sp=
an
class=3D"crayon-t">struct</span><span class=3D"crayon-h"> </span>=
<span
class=3D"crayon-e">StructOfArrays</span></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba9280752556-4"><span class=3D"crayon-sy">{<=
/span></div>
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba9280752556-5"><sp=
an
class=3D"crayon-h">=C2=A0=C2=A0 </span><span class=3D"crayon-v">s=
td</span><span
class=3D"crayon-o">::</span><span class=3D"crayon-v">vector</span=
><span
class=3D"crayon-o"><</span><span class=3D"crayon-v">Ms</span><=
span
class=3D"crayon-o">::</span><span class=3D"crayon-v">type</span><=
span
class=3D"crayon-o">></span><span class=3D"crayon-h"> _<</sp=
an><span
class=3D"crayon-v">Ms</span><span class=3D"crayon-o">::</span><sp=
an
class=3D"crayon-v">name</span><span class=3D"crayon-sy">>;</sp=
an><span
class=3D"crayon-sy">.</span><span class=3D"crayon-sy">.</span><sp=
an
class=3D"crayon-sy">.</span><span class=3D"crayon-h"> </span><spa=
n
class=3D"crayon-c">// the vectors</span></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba9280752556-6">=C2=A0</div>
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba9280752556-7"><sp=
an
class=3D"crayon-h">=C2=A0=C2=A0 </span><span class=3D"crayon-c">/=
/ example
part of the SOA interface</span></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba9280752556-8"><span class=3D"crayon-h">=C2=
=A0=C2=A0 </span><span
class=3D"crayon-t">void</span><span class=3D"crayon-h"> </span><s=
pan
class=3D"crayon-e">push_back</span><span class=3D"crayon-sy">(</s=
pan><span
class=3D"crayon-m">const</span><span class=3D"crayon-h"> </span><=
span
class=3D"crayon-v">S</span><span class=3D"crayon-o">&</span><=
span
class=3D"crayon-h"> </span><span class=3D"crayon-v">_soa_arg</spa=
n><span
class=3D"crayon-sy">)</span></div>
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba9280752556-9"><sp=
an
class=3D"crayon-h">=C2=A0=C2=A0 </span><span class=3D"crayon-sy">=
{</span></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba9280752556-10"><span class=3D"crayon-h">=
=C2=A0=C2=A0=C2=A0=C2=A0
</span><span class=3D"crayon-c">// Assuming N4191, Fold
expressions</span></div>
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba9280752556-11"><s=
pan
class=3D"crayon-h">=C2=A0=C2=A0=C2=A0=C2=A0 </span><span class=3D=
"crayon-sy">(_</span><span
class=3D"crayon-v"><Ms</span><span class=3D"crayon-o">::</span=
><span
class=3D"crayon-v">name</span><span class=3D"crayon-sy">></spa=
n><span
class=3D"crayon-sy">.</span><span class=3D"crayon-e">push_back</s=
pan><span
class=3D"crayon-sy">(</span><span class=3D"crayon-v">_soa_arg</sp=
an><span
class=3D"crayon-sy">.</span><span class=3D"crayon-v">_<Ms</spa=
n><span
class=3D"crayon-o">::</span><span class=3D"crayon-v">name</span>&=
gt;<span
class=3D"crayon-sy">,</span><span class=3D"crayon-sy">.</span><sp=
an
class=3D"crayon-sy">.</span><span class=3D"crayon-sy">.</span><sp=
an
class=3D"crayon-sy">)</span><span class=3D"crayon-sy">;</span></d=
iv>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba9280752556-12"><span class=3D"crayon-h">=
=C2=A0=C2=A0
</span><span class=3D"crayon-sy">}</span></div>
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba9280752556-13"><s=
pan
class=3D"crayon-sy">}</span><span class=3D"crayon-sy">;</span></d=
iv>
</div>
<br>
<br>
In some way we can say that your new name is some kind of syntactic
sugar of my alternative<br>
<br>
`foo`<br>
<br>
will expand to <br>
<br>
__name::foo <br>
<br>
where<br>
<br>
namespapce __name {<br>
=C2=A0=C2=A0=C2=A0 struct foo {}; =C2=A0=C2=A0 <br>
}<br>
<br>
<br>
template < typename Type, name Name><br>
struct X {<br>
=C2=A0=C2=A0=C2=A0 Type Name;<br>
};<br>
<br>
to<br>
<br>
template < typename Type, typename Name><br>
struct X {<br>
=C2=A0=C2=A0=C2=A0 Type <span class=3D"crayon-h">_</span><Name>;<=
br>
};<br>
<br>
and <br>
ms.foo<br>
<br>
to<br>
<br>
ms._<__name::foo><br>
<br>
We will need also that the struct <br>
<br>
<div class=3D"crayon-pre" style=3D"font-size: 12px !important;
line-height: 15px !important; -moz-tab-size:4; -o-tab-size:4;
-webkit-tab-size:4; tab-size:4;">
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba2772971485-1"><sp=
an
class=3D"crayon-t">struct</span><span class=3D"crayon-h"> </span>=
<span
class=3D"crayon-e">S</span><span class=3D"crayon-h"> </span><span
class=3D"crayon-sy">{</span></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba2772971485-2"><span class=3D"crayon-h">=C2=
=A0=C2=A0=C2=A0=C2=A0</span><span
class=3D"crayon-t">int</span><span class=3D"crayon-h"> </span><sp=
an
class=3D"crayon-v">a</span><span class=3D"crayon-sy">;</span></di=
v>
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba2772971485-3"><sp=
an
class=3D"crayon-h">=C2=A0=C2=A0=C2=A0=C2=A0</span><span class=3D"=
crayon-t">int</span><span
class=3D"crayon-h"> </span><span class=3D"crayon-v"><span
class=3D"crayon-v"></span>b</span><span class=3D"crayon-sy">;</=
span></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba2772971485-4"><span class=3D"crayon-h">=C2=
=A0=C2=A0=C2=A0=C2=A0</span><span
class=3D"crayon-t">int</span><span class=3D"crayon-h"> </span><sp=
an
class=3D"crayon-v"><span class=3D"crayon-v"></span>c</span><span
class=3D"crayon-sy">;</span></div>
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba2772971485-5"><sp=
an
class=3D"crayon-sy">}</span><span class=3D"crayon-sy">;</span></d=
iv>
</div>
<br>
should be equivalent to<br>
<br>
<div class=3D"crayon-pre" style=3D"font-size: 12px !important;
line-height: 15px !important; -moz-tab-size:4; -o-tab-size:4;
-webkit-tab-size:4; tab-size:4;">
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba2772971485-1"><sp=
an
class=3D"crayon-t">struct</span><span class=3D"crayon-h"> </span>=
<span
class=3D"crayon-e">S</span><span class=3D"crayon-h"> </span><span
class=3D"crayon-sy">{</span></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba2772971485-2"><span class=3D"crayon-h">=C2=
=A0=C2=A0=C2=A0=C2=A0</span><span
class=3D"crayon-t">int</span><span class=3D"crayon-h"> _<</spa=
n>__name<span
class=3D"crayon-v">::a></span><span class=3D"crayon-sy">;</spa=
n></div>
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba2772971485-3"><sp=
an
class=3D"crayon-h">=C2=A0=C2=A0=C2=A0=C2=A0</span><span class=3D"=
crayon-t">int</span><span
class=3D"crayon-h"> </span><span class=3D"crayon-v"><span
class=3D"crayon-h"><span class=3D"crayon-h">_</span><</span>=
</span>__name<span
class=3D"crayon-v"><span class=3D"crayon-h"><span class=3D"crayon=
-v">::</span></span><span
class=3D"crayon-v"></span>b></span><span class=3D"crayon-sy"=
>;</span></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba2772971485-4"><span class=3D"crayon-h">=C2=
=A0=C2=A0=C2=A0=C2=A0</span><span
class=3D"crayon-t">int</span><span class=3D"crayon-h"> </span><sp=
an
class=3D"crayon-v"><span class=3D"crayon-h"><span class=3D"crayon=
-h">_</span><</span></span>__name<span
class=3D"crayon-v"><span class=3D"crayon-v">::</span>c></span>=
<span
class=3D"crayon-sy">;</span></div>
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba2772971485-5"><sp=
an
class=3D"crayon-sy">}</span><span class=3D"crayon-sy">;</span></d=
iv>
</div>
<br>
<br>
and that <br>
<br>
<div class=3D"crayon-pre" style=3D"font-size: 12px !important;
line-height: 15px !important; -moz-tab-size:4; -o-tab-size:4;
-webkit-tab-size:4; tab-size:4;">
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba2772971485-1"><sp=
an
class=3D"crayon-t">struct</span><span class=3D"crayon-h"> </span>=
<span
class=3D"crayon-e">S</span><span class=3D"crayon-h"> </span><span
class=3D"crayon-sy">{</span></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba2772971485-2"><span class=3D"crayon-h">=C2=
=A0=C2=A0=C2=A0=C2=A0</span><span
class=3D"crayon-t">int</span><span class=3D"crayon-h"> _<</spa=
n>__name<span
class=3D"crayon-v">::a></span><span class=3D"crayon-sy">;</spa=
n></div>
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba2772971485-3"><sp=
an
class=3D"crayon-h">=C2=A0=C2=A0=C2=A0=C2=A0</span><span class=3D"=
crayon-t">int</span><span
class=3D"crayon-h"> a</span><span class=3D"crayon-v"></span><span
class=3D"crayon-sy">;</span></div>
<span class=3D"crayon-sy">}</span><span class=3D"crayon-sy">;</span><=
/div>
<br>
would report a compile error.<br>
<br>
I would try to translate the mixin example:<br>
<br>
template <typename Derived><br>
struct mixin<br>
{<br>
=C2=A0 using name =3D __name::check; // name of the mixin // [1]<br>
=C2=A0 Derived* _derived;<br>
<br>
=C2=A0 template <typename T><br>
=C2=A0 bool operator()(const T& t) const // mixin is callable<br>
=C2=A0 {<br>
=C2=A0=C2=A0=C2=A0 return _derived->_data =3D=3D t;<br>
=C2=A0 }<br>
};<br>
<br>
template<template< class> class ... Mixin> // Made this
variadic for fun<br>
struct MyClass<br>
{<br>
=C2=A0 Mixin<MyClass> _<Mixin<MyClass>::name> =3D
{this};... \\ [2]<br>
=C2=A0 int _data =3D 7;<br>
};<br>
<br>
In [1] declare name as been just a tag type.<br>
In [2] we use the Mixin<D>::name type as template of the data
member indexed variable _.=C2=A0 <br>
<br>
<br>
Resuming the two approaches could be seen as two sides of the same
coin. Your side gives a more friendly syntax, mine is closer to the
current language semantic once extended with member data indexed by
types, of course.<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" 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 />
--------------040403000108000600000002--
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Tue, 24 Mar 2015 06:54:13 +0100
Raw View
On 2015-03-23 20:35, gmisocpp@gmail.com wrote:
> Hi
>
> I think a feature like this would be great.
:-)
> I don't know if the feature should take that form though, but that's
> to be explored.
> The solution may be related to work meta data task group are doing I
> wonder.
Can you give me a link?
>
> I'm sure this has come up before somewhere, but I would like to be
> able to make existing code more readable.
> I would like to provide the ability for a class like pair, to be able
> to alias first_name with first and last_name with second.
> If no name is given, pair should work as normal.
>
> std::pair<string first_name, string last_name> name{"bob", "jones"};
> printf("Hello %s %s\n", name.first_name.c_str(),
> name.second_name.c_str());
>
The pair example is classic, of course. The syntax you are suggesting is
quite nice for pair and tuple, but how would that pan out with the
CRTP/mixin example?
> But mostly I wish for a feature that would make people use pair and
> tuple a lot less, that's what I really want!
We're almost on the same page here. Tuples are great for generic
programming but not necessarily for library users. Tuples with named
members can serve both worlds, though. Ease of use in the generic world
and ease of use for library users due to appropriately named members.
Best,
Roland
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Tue, 24 Mar 2015 10:53:30 +0100
Raw View
This is a multi-part message in MIME format.
--------------080804020707030409060606
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 2015-03-24 06:34, Vicente J. Botet Escriba wrote:
> Le 23/03/15 18:09, Roland Bock a =C3=A9crit :
>> Hi,
>>
>> here is an idea I first talked about in a workshop at CppCon 2014 and
>> recently at the Munich C++ Meetup:
>>
>>
>> In templates we can use types and values as parameters. We cannot
>> specify names though.
>>
>> But wouldn't it be cool to be able to parametrize templates with names? =
E.g.
>>
>> // ------------------------
>> template<typename Type,=20
>> name Name, // New template parameter type
>> Type Value>
>> struct Foo
>> {
>> Type Name =3D Value;
>> };
>> // ------------------------
>>
>>
>> Ok, this may look boring, so how about a tuple with named members?
>
> I'm all for been able to do something like that.
:-)
> An alternative could be to be able to define some kind of data members
> indexed by a type (something related to template variables instances).
>
> template<typename Type,=20
> typename Name, // New template parameter type
> Type Value>
> struct Foo
> {
> Type _<Name> =3D Value;
> };
>
> The use of _ is intended, meaning the data member name is not significant=
..
Ah, ok, it took a while for me to grok that. So _<some_type> would be a
non-static template variable, right?
I can't tell what would be a greater change to the language, but as you
mention yourself, ease of use would be better if we really had names.
> // ------------------------
> template<typename T, typename X>
> struct type_name
> {
> using type =3D T;
> using name =3D X;
> };
>
> struct foo {};
> struct bar {};
>
> using my_struct =3D=20
> named_tuple
> <
> type_name<int, foo>,
> type_name<char, bar>
> >;
>
> auto ms =3D my_struct{7, 'c'};
> ms._<foo> =3D 9;
>
> The interface is not so nice, it needs to declare the structs foo and
> bar and use ms._<foo> instead of ms.foo.
Here's how I would like to use the feature in sqlpp one day:
a) defining tables:
using TabFoo =3D sqlpp::table<`tab_foo`,
int, `id`,
string, `name`
bool, `likesCpp`>;
(slightly simplified, in reality there would be traits like can_be_null
or has_default to be set, too)
b) using tables in code:
auto left =3D TabFoo{}.as<`left`>;
auto right =3D TabFoo{}.as<`right`>
for (row : db(select(left.id, right.id.as<`partnerId`>)
.from(left, right)
.where(left.id > right.id)))
{
std::cout << row.id << "," << row.partnerId << '\n';
}
Much of the elegance would be lost if I had to create an extra type for
each name.
Another really important feature is the ability to compare names.
template<name X>
struct N{};
struct Foo
{
using name =3D `dilbert`;
};
struct Bar
{
using name =3D `dilbert`;
};
static_assert(std::is_same<N<Foo::name>,
N<Bar::name>>::value, "");
If you wanted to achieve the same with types, then you would have some
project wide namespace for all the name-representing types which might
be quite awkward, IMHO.
>
> However it doesn't need to introduce a new name keyword and a new kind
> of symbols.
>
> Another limitation of my alternative is that it doesn't work well with
> struct. Your example for StructOfArrays would need a struct S indexed
> by types
>
> [...]
>
> In some way we can say that your new name is some kind of syntactic
> sugar of my alternative
>
> `foo`
>
> will expand to
>
> __name::foo
>
> where
>
> namespapce __name {
> struct foo {}; =20
> }
>
>
> template < typename Type, name Name>
> struct X {
> Type Name;
> };
>
> to
>
> template < typename Type, typename Name>
> struct X {
> Type _<Name>;
> };
>
> and
> ms.foo
>
> to
>
> ms._<__name::foo>
Comparing ms.foo to ms._<__name::foo> I know what I'd prefer :-)
>
> We will need also that the struct
>
> structS{
> inta;
> intb;
> intc;
> };
>
> should be equivalent to
>
> structS{
> int_<__name::a>;
> int_<__name::b>;
> int_<__name::c>;
> };
>
This seems to be a tough requirement. Wouldn't that mean that all
structs with members of the same type have to be equivalent? Or would
just these non-static template variables have some special ability to
make structs equivalent?
How about
struct S
{
int a;
int b;
};
struct T
{
int _<__name::a>;
int b;
};
Wouldd they also be equivalent?
>
> and that
>
> structS{
> int_<__name::a>;
> inta;
> };
>
> would report a compile error.
How about
structS{
int _<__global_names::a>;
int _<__local_names::a>;
};
I would have assumed from your earlier examples, that this would work
fine. But if the above should give a compile error, then this should
also not compile.
>
> I would try to translate the mixin example:
>
> template <typename Derived>
> struct mixin
> {
> using name =3D __name::check; // name of the mixin // [1]
> Derived* _derived;
>
> template <typename T>
> bool operator()(const T& t) const // mixin is callable
> {
> return _derived->_data =3D=3D t;
> }
> };
>
> template<template< class> class ... Mixin> // Made this variadic for fun
> struct MyClass
> {
> Mixin<MyClass> _<Mixin<MyClass>::name> =3D {this};... \\ [2]
> int _data =3D 7;
> };
>
> In [1] declare name as been just a tag type.
> In [2] we use the Mixin<D>::name type as template of the data member
> indexed variable _.=20
>
>
> Resuming the two approaches could be seen as two sides of the same
> coin. Your side gives a more friendly syntax, mine is closer to the
> current language semantic once extended with member data indexed by
> types, of course.
I really appreciate the effort to mimic the names with the non-static
template member variables. It is a neat idea on its own. I do believe
though that the idea of equivalence of structs as described above adds
quite a bit of complexity.
My "names" idea obviously introduces
* a new keyword, although I guess that could be circumvented since it
is "only" used in the template list. We could probably reuse some
existing keyword.
* some way of specifying names
I understand that especially the latter part is a major change. Ease of
use for library-developers and their users on the other hand is one of
the major goals of the "names" idea.
Cheers,
Roland
--=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/.
--------------080804020707030409060606
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">On 2015-03-24 06:34, Vicente J. Botet
Escriba wrote:<br>
</div>
<blockquote cite=3D"mid:5510F753.8010602@wanadoo.fr" type=3D"cite">
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Ty=
pe">
<div class=3D"moz-cite-prefix">Le 23/03/15 18:09, Roland Bock a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote cite=3D"mid:551048D2.2070907@eudoxos.de" type=3D"cite">
<pre wrap=3D"">Hi,
here is an idea I first talked about in a workshop at CppCon 2014 and
recently at the Munich C++ Meetup:
In templates we can use types and values as parameters. We cannot
specify names though.
But wouldn't it be cool to be able to parametrize templates with names? E.g=
..
// ------------------------
template<typename Type,=20
name Name, // New template parameter type
Type Value>
struct Foo
{
Type Name =3D Value;
};
// ------------------------
Ok, this may look boring, so how about a tuple with named members?
</pre>
</blockquote>
<br>
I'm all for been able to do something like that.<br>
</blockquote>
<br>
:-)<br>
<br>
<blockquote cite=3D"mid:5510F753.8010602@wanadoo.fr" type=3D"cite"> An
alternative could be to be able to define some kind of data
members indexed by a type (something related to template variables
instances).<br>
<br>
<pre wrap=3D"">template<typename Type,=20
typename Name, // New template parameter type
Type Value>
struct Foo
{
Type _<Name> =3D Value;
};
</pre>
<br>
The use of _ is intended, meaning the data member name is not
significant.<br>
</blockquote>
<br>
Ah, ok, it took a while for me to grok that. So _<some_type>
would be a non-static template variable, right?<br>
<br>
I can't tell what would be a greater change to the language, but as
you mention yourself, ease of use would be better if we really had
names.<br>
<br>
<blockquote cite=3D"mid:5510F753.8010602@wanadoo.fr" type=3D"cite">
<pre wrap=3D"">// ------------------------
template<typename T, typename X>
struct type_name
{
using type =3D T;
using name =3D X;
};
struct foo {};
struct bar {};
using my_struct =3D=20
named_tuple
<
type_name<int, foo>,
type_name<char, bar>
>;
auto ms =3D my_struct{7, 'c'};
ms._<foo> =3D 9;
</pre>
<br>
The interface is not so nice, it needs to declare the structs foo
and bar and use ms._<foo> instead of ms.foo.<br>
</blockquote>
<br>
Here's how I would like to use the feature in sqlpp one day:<br>
<br>
a) defining tables:<br>
<br>
<tt>using TabFoo =3D sqlpp::table<`tab_foo`,</tt><tt><br>
</tt><tt>=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=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 int, `id`,</tt><tt><br>
</tt><tt>=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=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 string, `name</tt><tt>`</tt><tt><br>
</tt><tt>=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=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 bool, `likesCpp`>;</tt><tt><br>
</tt><br>
(slightly simplified, in reality there would be traits like
can_be_null or has_default to be set, too)<br>
<br>
b) using tables in code:<br>
<br>
<tt>auto left =3D TabFoo{}.as<`left`>;</tt><tt><br>
</tt><tt>auto right =3D TabFoo{}.as<`right`></tt><tt><br>
</tt><tt><br>
</tt><tt>for (row : db(select(left.id,
right.id.as<`partnerId`>)</tt><tt><br>
</tt><tt>=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 </tt><tt>.from(left, right)</tt><tt><br>
</tt><tt>=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 .where(left.id > right.id)))</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 std::cout << row.id << "," <<
row.partnerId << '\n';</tt><tt><br>
</tt><tt>}</tt><tt><br>
</tt><br>
Much of the elegance would be lost if I had to create an extra type
for each name.<br>
<br>
<br>
Another really important feature is the ability to compare names. <br>
<br>
<tt><tt>template<name X></tt><tt><br>
</tt><tt>struct N{};</tt><br>
<br>
struct Foo</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0=C2=A0 using name =3D `dilbert`;</tt><tt><br>
</tt><tt>};</tt><tt><br>
</tt><tt>struct Bar</tt><tt><br>
</tt><tt>
{</tt><tt><br>
</tt><tt>
=C2=A0=C2=A0=C2=A0 using name =3D `dilbert`;</tt><tt><br>
</tt><tt>
};</tt><tt><br>
</tt><tt><br>
</tt><tt>static_assert(std::is_same<N<Foo::name>, </tt><tt><br=
>
</tt><tt>=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 N<Bar::name>>::value,
"");</tt><br>
<br>
If you wanted to achieve the same with types, then you would have
some project wide namespace for all the name-representing types
which might be quite awkward, IMHO.<br>
<br>
<br>
<blockquote cite=3D"mid:5510F753.8010602@wanadoo.fr" type=3D"cite"> <br=
>
However it doesn't need to introduce a new name keyword and a new
kind of symbols.<br>
<br>
Another limitation of my alternative is that it doesn't work well
with struct. Your example for <span class=3D"crayon-h"></span><span
class=3D"crayon-e">StructOfArrays would need a struct S indexed by
types</span><br>
<br>
<meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf=
-8">
[...]<br>
<br>
In some way we can say that your new name is some kind of
syntactic sugar of my alternative<br>
<br>
`foo`<br>
<br>
will expand to <br>
<br>
__name::foo <br>
<br>
where<br>
<br>
namespapce __name {<br>
=C2=A0=C2=A0=C2=A0 struct foo {}; =C2=A0=C2=A0 <br>
}<br>
<br>
<br>
template < typename Type, name Name><br>
struct X {<br>
=C2=A0=C2=A0=C2=A0 Type Name;<br>
};<br>
<br>
to<br>
<br>
template < typename Type, typename Name><br>
struct X {<br>
=C2=A0=C2=A0=C2=A0 Type <span class=3D"crayon-h">_</span><Name>=
;<br>
};<br>
<br>
and <br>
ms.foo<br>
<br>
to<br>
<br>
ms._<__name::foo><br>
</blockquote>
<br>
Comparing ms.foo to ms._<__name::foo> I know what I'd prefer
:-)<br>
<br>
<blockquote cite=3D"mid:5510F753.8010602@wanadoo.fr" type=3D"cite"> <br=
>
We will need also that the struct <br>
<br>
<div class=3D"crayon-pre" style=3D"font-size: 12px !important;
line-height: 15px !important; -moz-tab-size:4; -o-tab-size:4;
-webkit-tab-size:4; tab-size:4;">
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba2772971485-1"><=
span
class=3D"crayon-t">struct</span><span class=3D"crayon-h"> </spa=
n><span
class=3D"crayon-e">S</span><span class=3D"crayon-h"> </span><sp=
an
class=3D"crayon-sy">{</span></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba2772971485-2"><span class=3D"crayon-h">=
=C2=A0=C2=A0=C2=A0=C2=A0</span><span
class=3D"crayon-t">int</span><span class=3D"crayon-h"> </span><=
span
class=3D"crayon-v">a</span><span class=3D"crayon-sy">;</span></=
div>
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba2772971485-3"><=
span
class=3D"crayon-h">=C2=A0=C2=A0=C2=A0=C2=A0</span><span class=
=3D"crayon-t">int</span><span
class=3D"crayon-h"> </span><span class=3D"crayon-v"><span
class=3D"crayon-v"></span>b</span><span class=3D"crayon-sy">;=
</span></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba2772971485-4"><span class=3D"crayon-h">=
=C2=A0=C2=A0=C2=A0=C2=A0</span><span
class=3D"crayon-t">int</span><span class=3D"crayon-h"> </span><=
span
class=3D"crayon-v"><span class=3D"crayon-v"></span>c</span><spa=
n
class=3D"crayon-sy">;</span></div>
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba2772971485-5"><=
span
class=3D"crayon-sy">}</span><span class=3D"crayon-sy">;</span><=
/div>
</div>
<br>
should be equivalent to<br>
<br>
<div class=3D"crayon-pre" style=3D"font-size: 12px !important;
line-height: 15px !important; -moz-tab-size:4; -o-tab-size:4;
-webkit-tab-size:4; tab-size:4;">
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba2772971485-1"><=
span
class=3D"crayon-t">struct</span><span class=3D"crayon-h"> </spa=
n><span
class=3D"crayon-e">S</span><span class=3D"crayon-h"> </span><sp=
an
class=3D"crayon-sy">{</span></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba2772971485-2"><span class=3D"crayon-h">=
=C2=A0=C2=A0=C2=A0=C2=A0</span><span
class=3D"crayon-t">int</span><span class=3D"crayon-h"> _<</s=
pan>__name<span
class=3D"crayon-v">::a></span><span class=3D"crayon-sy">;</s=
pan></div>
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba2772971485-3"><=
span
class=3D"crayon-h">=C2=A0=C2=A0=C2=A0=C2=A0</span><span class=
=3D"crayon-t">int</span><span
class=3D"crayon-h"> </span><span class=3D"crayon-v"><span
class=3D"crayon-h"><span class=3D"crayon-h">_</span><</spa=
n></span>__name<span
class=3D"crayon-v"><span class=3D"crayon-h"><span
class=3D"crayon-v">::</span></span><span class=3D"crayon-v"=
></span>b></span><span
class=3D"crayon-sy">;</span></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba2772971485-4"><span class=3D"crayon-h">=
=C2=A0=C2=A0=C2=A0=C2=A0</span><span
class=3D"crayon-t">int</span><span class=3D"crayon-h"> </span><=
span
class=3D"crayon-v"><span class=3D"crayon-h"><span
class=3D"crayon-h">_</span><</span></span>__name<span
class=3D"crayon-v"><span class=3D"crayon-v">::</span>c></spa=
n><span
class=3D"crayon-sy">;</span></div>
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba2772971485-5"><=
span
class=3D"crayon-sy">}</span><span class=3D"crayon-sy">;</span><=
/div>
</div>
<br>
</blockquote>
This seems to be a tough requirement. Wouldn't that mean that all
structs with members of the same type have to be equivalent? Or
would just these non-static template variables have some special
ability to make structs equivalent?<br>
<br>
How about<br>
<br>
<tt>struct S</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 int </tt><tt><span class=3D"crayon-h">a</span></t=
t><tt><span
class=3D"crayon-v"></span></tt><tt><span class=3D"crayon-sy">;<br>
=C2=A0=C2=A0 int b;<br>
};<br>
<br>
struct T<br>
{<br>
=C2=A0=C2=A0 </span></tt><span class=3D"crayon-sy"><tt>int </tt><tt=
><span
class=3D"crayon-h">_<</span></tt><tt>__name</tt><tt><span
class=3D"crayon-v">::a></span></tt><tt><span
class=3D"crayon-sy">;<br>
=C2=A0=C2=A0 int b;<br>
</span></tt><tt>};</tt><br>
</span><br>
Wouldd they also be equivalent?<br>
<blockquote cite=3D"mid:5510F753.8010602@wanadoo.fr" type=3D"cite"> <br=
>
and that <br>
<br>
<div class=3D"crayon-pre" style=3D"font-size: 12px !important;
line-height: 15px !important; -moz-tab-size:4; -o-tab-size:4;
-webkit-tab-size:4; tab-size:4;">
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba2772971485-1"><=
span
class=3D"crayon-t">struct</span><span class=3D"crayon-h"> </spa=
n><span
class=3D"crayon-e">S</span><span class=3D"crayon-h"> </span><sp=
an
class=3D"crayon-sy">{</span></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba2772971485-2"><span class=3D"crayon-h">=
=C2=A0=C2=A0=C2=A0=C2=A0</span><span
class=3D"crayon-t">int</span><span class=3D"crayon-h"> _<</s=
pan>__name<span
class=3D"crayon-v">::a></span><span class=3D"crayon-sy">;</s=
pan></div>
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba2772971485-3"><=
span
class=3D"crayon-h">=C2=A0=C2=A0=C2=A0=C2=A0</span><span class=
=3D"crayon-t">int</span><span
class=3D"crayon-h"> a</span><span class=3D"crayon-v"></span><sp=
an
class=3D"crayon-sy">;</span></div>
<span class=3D"crayon-sy">}</span><span class=3D"crayon-sy">;</span=
></div>
<br>
would report a compile error.<br>
</blockquote>
<br>
How about <br>
<br>
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba2772971485-1"><tt><=
span
class=3D"crayon-t">struct</span></tt><tt><span class=3D"crayon-h"=
>
</span></tt><tt><span class=3D"crayon-e">S</span></tt><tt><span
class=3D"crayon-h"> </span></tt><tt><span class=3D"crayon-sy">{<b=
r>
=C2=A0 int </span></tt><tt><span class=3D"crayon-h">_<</span><=
/tt><tt>__global_name</tt><tt><span
class=3D"crayon-v">s::a></span></tt><tt><span
class=3D"crayon-sy">;<br>
=C2=A0 int </span></tt><tt><span class=3D"crayon-sy"></span></tt>=
<tt><span
class=3D"crayon-h">_<</span></tt><tt>__local_name</tt><tt><spa=
n
class=3D"crayon-v">s::a></span></tt><tt><span
class=3D"crayon-sy">;</span></tt></div>
<tt>};</tt><br>
<br>
I would have assumed from your earlier examples, that this would
work fine. But if the above should give a compile error, then this
should also not compile.<br>
<br>
<blockquote cite=3D"mid:5510F753.8010602@wanadoo.fr" type=3D"cite"> <br=
>
I would try to translate the mixin example:<br>
<br>
template <typename Derived><br>
struct mixin<br>
{<br>
=C2=A0 using name =3D __name::check; // name of the mixin // [1]<br>
=C2=A0 Derived* _derived;<br>
<br>
=C2=A0 template <typename T><br>
=C2=A0 bool operator()(const T& t) const // mixin is callable<br>
=C2=A0 {<br>
=C2=A0=C2=A0=C2=A0 return _derived->_data =3D=3D t;<br>
=C2=A0 }<br>
};<br>
<br>
template<template< class> class ... Mixin> // Made
this variadic for fun<br>
struct MyClass<br>
{<br>
=C2=A0 Mixin<MyClass> _<Mixin<MyClass>::name> =3D
{this};... \\ [2]<br>
=C2=A0 int _data =3D 7;<br>
};<br>
<br>
In [1] declare name as been just a tag type.<br>
In [2] we use the Mixin<D>::name type as template of the
data member indexed variable _.=C2=A0 <br>
<br>
<br>
Resuming the two approaches could be seen as two sides of the same
coin. Your side gives a more friendly syntax, mine is closer to
the current language semantic once extended with member data
indexed by types, of course.<br>
</blockquote>
<br>
I really appreciate the effort to mimic the names with the
non-static template member variables. It is a neat idea on its own.
I do believe though that the idea of equivalence of structs as
described above adds quite a bit of complexity.<br>
<br>
My "names" idea obviously introduces <br>
<ul>
<li>a new keyword, although I guess that could be circumvented
since it is "only" used in the template list. We could probably
reuse some existing keyword.<br>
</li>
<li>some way of specifying names</li>
</ul>
<p>I understand that especially the latter part is a major change.
Ease of use for library-developers and their users on the other
hand is one of the major goals of the "names" idea.<br>
</p>
<br>
Cheers,<br>
<br>
Roland<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" 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 />
--------------080804020707030409060606--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Tue, 24 Mar 2015 19:47:59 +0100
Raw View
This is a multi-part message in MIME format.
--------------060807070504010501050208
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 24/03/15 10:53, Roland Bock a =C3=A9crit :
> On 2015-03-24 06:34, Vicente J. Botet Escriba wrote:
>> Le 23/03/15 18:09, Roland Bock a =C3=A9crit :
>>> In templates we can use types and values as parameters. We cannot
>>> specify names though.
>>>
>>> But wouldn't it be cool to be able to parametrize templates with names?=
E.g.
>>>
>>> // ------------------------
>>> template<typename Type,
>>> name Name, // New template parameter type
>>> Type Value>
>>> struct Foo
>>> {
>>> Type Name =3D Value;
>>> };
>>> // ------------------------
>>> =20
>> An alternative could be to be able to define some kind of data=20
>> members indexed by a type (something related to template variables=20
>> instances).
>>
>> template<typename Type,
>> typename Name, // New template parameter type
>> Type Value>
>> struct Foo
>> {
>> Type _<Name> =3D Value;
>> };
>>
>> The use of _ is intended, meaning the data member name is not=20
>> significant.
>
> Ah, ok, it took a while for me to grok that. So _<some_type> would be=20
> a non-static template variable, right?
>
> I can't tell what would be a greater change to the language, but as=20
> you mention yourself, ease of use would be better if we really had names.
I'm not a compiler implementer, but I suspect that easy to implement=20
would be an important factor.
>
>> // ------------------------
>> template<typename T, typename X>
>> struct type_name
>> {
>> using type =3D T;
>> using name =3D X;
>> };
>>
>> struct foo {};
>> struct bar {};
>>
>> using my_struct =3D
>> named_tuple
>> <
>> type_name<int, foo>,
>> type_name<char, bar>
>> >;
>>
>> auto ms =3D my_struct{7, 'c'};
>> ms._<foo> =3D 9;
>>
>> The interface is not so nice, it needs to declare the structs foo and=20
>> bar and use ms._<foo> instead of ms.foo.
>
> Here's how I would like to use the feature in sqlpp one day:
>
> a) defining tables:
>
> using TabFoo =3D sqlpp::table<`tab_foo`,
> int, `id`,
> string, `name`
> bool, `likesCpp`>;
>
> (slightly simplified, in reality there would be traits like=20
> can_be_null or has_default to be set, too)
>
> b) using tables in code:
>
> auto left =3D TabFoo{}.as<`left`>;
> auto right =3D TabFoo{}.as<`right`>
>
> for (row : db(select(left.id, right.id.as<`partnerId`>)
> .from(left, right)
> .where(left.id > right.id)))
> {
> std::cout << row.id << "," << row.partnerId << '\n';
> }
>
> Much of the elegance would be lost if I had to create an extra type=20
> for each name.
Agreed, however I have not said that you must define them. These types=20
could be generated by the compiler, that is be just like your names `foo`.
>
>
> Another really important feature is the ability to compare names.
>
> template<name X>
> struct N{};
>
> struct Foo
> {
> using name =3D `dilbert`;
> };
> struct Bar
> {
> using name =3D `dilbert`;
> };
>
> static_assert(std::is_same<N<Foo::name>,
> N<Bar::name>>::value, "");
>
> If you wanted to achieve the same with types, then you would have some=20
> project wide namespace for all the name-representing types which might=20
> be quite awkward, IMHO.
Right, it is the namespace __name. This IMO is an implementation detail.
>
>> However it doesn't need to introduce a new name keyword and a new=20
>> kind of symbols.
>>
>> Another limitation of my alternative is that it doesn't work well=20
>> with struct. Your example for StructOfArrays would need a struct S=20
>> indexed by types
>>
>> [...]
>>
>> In some way we can say that your new name is some kind of syntactic=20
>> sugar of my alternative
>>
>>
>> and
>> ms.foo
>>
>> to
>>
>> ms._<__name::foo>
>
> Comparing ms.foo to ms._<__name::foo> I know what I'd prefer :-)
Me too. I want just to remove the need for a new kind of "Thing". What I=20
mean is that both could be made equivalent.
>
>>
>> We will need also that the struct
>>
>> structS{
>> inta;
>> intb;
>> intc;
>> };
>>
>> should be equivalent to
>>
>> structS{
>> int_<__name::a>;
>> int_<__name::b>;
>> int_<__name::c>;
>> };
>>
> This seems to be a tough requirement. Wouldn't that mean that all=20
> structs with members of the same type have to be equivalent? Or would=20
> just these non-static template variables have some special ability to=20
> make structs equivalent?
The last.
>
> How about
>
> struct S
> {
> int a;
> int b;
> };
>
> struct T
> {
> int _<__name::a>;
> int b;
> };
>
> Wouldd they also be equivalent?
I would say yes, but I have not think enough about the implications. Do=20
you see a problem?
>>
>> and that
>>
>> structS{
>> int_<__name::a>;
>> inta;
>> };
>>
>> would report a compile error.
>
> How about
>
> structS{
> int _<__global_names::a>;
> int _<__local_names::a>;
> };
>
I don't see the need for global or local namespace for the types=20
representing symbols (names). All of them could/should be on the same=20
__name namespace.
> I would have assumed from your earlier examples, that this would work=20
> fine. But if the above should give a compile error, then this should=20
> also not compile.
>>
>> Resuming the two approaches could be seen as two sides of the same=20
>> coin. Your side gives a more friendly syntax, mine is closer to the=20
>> current language semantic once extended with member data indexed by=20
>> types, of course.
>
> I really appreciate the effort to mimic the names with the non-static=20
> template member variables. It is a neat idea on its own. I do believe=20
> though that the idea of equivalence of structs as described above adds=20
> quite a bit of complexity.
Can you elaborate?
>
> My "names" idea obviously introduces
>
> * a new keyword, although I guess that could be circumvented since
> it is "only" used in the template list. We could probably reuse
> some existing keyword.
> * some way of specifying names
>
> I understand that especially the latter part is a major change. Ease=20
> of use for library-developers and their users on the other hand is one=20
> of the major goals of the "names" idea.
>
Hopping the transformation I have described could make it more probable.
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/.
--------------060807070504010501050208
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 24/03/15 10:53, Roland Bock a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote cite=3D"mid:5511341A.803@eudoxos.de" type=3D"cite">
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Ty=
pe">
<div class=3D"moz-cite-prefix">On 2015-03-24 06:34, Vicente J. Botet
Escriba wrote:<br>
</div>
<blockquote cite=3D"mid:5510F753.8010602@wanadoo.fr" type=3D"cite">
<meta content=3D"text/html; charset=3Dutf-8"
http-equiv=3D"Content-Type">
<div class=3D"moz-cite-prefix">Le 23/03/15 18:09, Roland Bock a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote cite=3D"mid:551048D2.2070907@eudoxos.de" type=3D"cite">
<pre wrap=3D"">In templates we can use types and values as parame=
ters. We cannot
specify names though.
But wouldn't it be cool to be able to parametrize templates with names? E.g=
..
// ------------------------
template<typename Type,=20
name Name, // New template parameter type
Type Value>
struct Foo
{
Type Name =3D Value;
};
// ------------------------
</pre>
</blockquote>
</blockquote>
<blockquote cite=3D"mid:5510F753.8010602@wanadoo.fr" type=3D"cite"> A=
n
alternative could be to be able to define some kind of data
members indexed by a type (something related to template
variables instances).<br>
<br>
<pre wrap=3D"">template<typename Type,=20
typename Name, // New template parameter type
Type Value>
struct Foo
{
Type _<Name> =3D Value;
};
</pre>
<br>
The use of _ is intended, meaning the data member name is not
significant.<br>
</blockquote>
<br>
Ah, ok, it took a while for me to grok that. So _<some_type>
would be a non-static template variable, right?<br>
<br>
I can't tell what would be a greater change to the language, but
as you mention yourself, ease of use would be better if we really
had names.<br>
</blockquote>
I'm not a compiler implementer, but I suspect that easy to implement
would be an important factor.<br>
<blockquote cite=3D"mid:5511341A.803@eudoxos.de" type=3D"cite"> <br>
<blockquote cite=3D"mid:5510F753.8010602@wanadoo.fr" type=3D"cite">
<pre wrap=3D"">// ------------------------
template<typename T, typename X>
struct type_name
{
using type =3D T;
using name =3D X;
};
struct foo {};
struct bar {};
using my_struct =3D=20
named_tuple
<
type_name<int, foo>,
type_name<char, bar>
>;
auto ms =3D my_struct{7, 'c'};
ms._<foo> =3D 9;
</pre>
<br>
The interface is not so nice, it needs to declare the structs
foo and bar and use ms._<foo> instead of ms.foo.<br>
</blockquote>
<br>
Here's how I would like to use the feature in sqlpp one day:<br>
<br>
a) defining tables:<br>
<br>
<tt>using TabFoo =3D sqlpp::table<`tab_foo`,</tt><tt><br>
</tt><tt>=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=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 int, `id`,</tt><tt><br>
</tt><tt>=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=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 string, `name</tt><tt>`</tt><tt><br>
</tt><tt>=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=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 bool, `likesCpp`>;</tt><tt><br>
</tt><br>
(slightly simplified, in reality there would be traits like
can_be_null or has_default to be set, too)<br>
<br>
b) using tables in code:<br>
<br>
<tt>auto left =3D TabFoo{}.as<`left`>;</tt><tt><br>
</tt><tt>auto right =3D TabFoo{}.as<`right`></tt><tt><br>
</tt><tt><br>
</tt><tt>for (row : db(select(left.id,
right.id.as<`partnerId`>)</tt><tt><br>
</tt><tt>=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 </tt><tt>.from(left, right)</tt><tt><br>
</tt><tt>=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 .where(left.id > right.id)))</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 std::cout << row.id << "," <<
row.partnerId << '\n';</tt><tt><br>
</tt><tt>}</tt><tt><br>
</tt><br>
Much of the elegance would be lost if I had to create an extra
type for each name.<br>
</blockquote>
Agreed, however I have not said that you must define them. These
types could be generated by the compiler, that is be just like your
names `foo`.<br>
<blockquote cite=3D"mid:5511341A.803@eudoxos.de" type=3D"cite"> <br>
<br>
Another really important feature is the ability to compare names.
<br>
<br>
<tt><tt>template<name X></tt><tt><br>
</tt><tt>struct N{};</tt><br>
<br>
struct Foo</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0=C2=A0 using name =3D `dilbert`;</tt><tt><br>
</tt><tt>};</tt><tt><br>
</tt><tt>struct Bar</tt><tt><br>
</tt><tt> {</tt><tt><br>
</tt><tt> =C2=A0=C2=A0=C2=A0 using name =3D `dilbert`;</tt><tt><br>
</tt><tt> };</tt><tt><br>
</tt><tt><br>
</tt><tt>static_assert(std::is_same<N<Foo::name>, </tt><tt><=
br>
</tt><tt>=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 N<Bar::name>>::value,
"");</tt><br>
<br>
If you wanted to achieve the same with types, then you would have
some project wide namespace for all the name-representing types
which might be quite awkward, IMHO.<br>
</blockquote>
Right, it is the namespace __name. This IMO is an implementation
detail.<br>
<blockquote cite=3D"mid:5511341A.803@eudoxos.de" type=3D"cite"><br>
<blockquote cite=3D"mid:5510F753.8010602@wanadoo.fr" type=3D"cite">
However it doesn't need to introduce a new name keyword and a
new kind of symbols.<br>
<br>
Another limitation of my alternative is that it doesn't work
well with struct. Your example for <span class=3D"crayon-h"></span>=
<span
class=3D"crayon-e">StructOfArrays would need a struct S indexed
by types</span><br>
<br>
<meta http-equiv=3D"content-type" content=3D"text/html;
charset=3Dutf-8">
[...]<br>
<br>
In some way we can say that your new name is some kind of
syntactic sugar of my alternative<br>
<br>
<br>
and <br>
ms.foo<br>
<br>
to<br>
<br>
ms._<__name::foo><br>
</blockquote>
<br>
Comparing ms.foo to ms._<__name::foo> I know what I'd prefer
:-)<br>
</blockquote>
Me too. I want just to remove the need for a new kind of "Thing".
What I mean is that both could be made equivalent.<br>
<blockquote cite=3D"mid:5511341A.803@eudoxos.de" type=3D"cite"> <br>
<blockquote cite=3D"mid:5510F753.8010602@wanadoo.fr" type=3D"cite"> <=
br>
We will need also that the struct <br>
<br>
<div class=3D"crayon-pre" style=3D"font-size: 12px !important;
line-height: 15px !important; -moz-tab-size:4; -o-tab-size:4;
-webkit-tab-size:4; tab-size:4;">
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba2772971485-1"=
><span
class=3D"crayon-t">struct</span><span class=3D"crayon-h"> </s=
pan><span
class=3D"crayon-e">S</span><span class=3D"crayon-h"> </span><=
span
class=3D"crayon-sy">{</span></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba2772971485-2"><span class=3D"crayon-h"=
>=C2=A0=C2=A0=C2=A0=C2=A0</span><span
class=3D"crayon-t">int</span><span class=3D"crayon-h"> </span=
><span
class=3D"crayon-v">a</span><span class=3D"crayon-sy">;</span>=
</div>
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba2772971485-3"=
><span
class=3D"crayon-h">=C2=A0=C2=A0=C2=A0=C2=A0</span><span class=
=3D"crayon-t">int</span><span
class=3D"crayon-h"> </span><span class=3D"crayon-v"><span
class=3D"crayon-v"></span>b</span><span class=3D"crayon-sy"=
>;</span></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba2772971485-4"><span class=3D"crayon-h"=
>=C2=A0=C2=A0=C2=A0=C2=A0</span><span
class=3D"crayon-t">int</span><span class=3D"crayon-h"> </span=
><span
class=3D"crayon-v"><span class=3D"crayon-v"></span>c</span><s=
pan
class=3D"crayon-sy">;</span></div>
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba2772971485-5"=
><span
class=3D"crayon-sy">}</span><span class=3D"crayon-sy">;</span=
></div>
</div>
<br>
should be equivalent to<br>
<br>
<div class=3D"crayon-pre" style=3D"font-size: 12px !important;
line-height: 15px !important; -moz-tab-size:4; -o-tab-size:4;
-webkit-tab-size:4; tab-size:4;">
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba2772971485-1"=
><span
class=3D"crayon-t">struct</span><span class=3D"crayon-h"> </s=
pan><span
class=3D"crayon-e">S</span><span class=3D"crayon-h"> </span><=
span
class=3D"crayon-sy">{</span></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba2772971485-2"><span class=3D"crayon-h"=
>=C2=A0=C2=A0=C2=A0=C2=A0</span><span
class=3D"crayon-t">int</span><span class=3D"crayon-h"> _<<=
/span>__name<span
class=3D"crayon-v">::a></span><span class=3D"crayon-sy">;<=
/span></div>
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba2772971485-3"=
><span
class=3D"crayon-h">=C2=A0=C2=A0=C2=A0=C2=A0</span><span class=
=3D"crayon-t">int</span><span
class=3D"crayon-h"> </span><span class=3D"crayon-v"><span
class=3D"crayon-h"><span class=3D"crayon-h">_</span><</s=
pan></span>__name<span
class=3D"crayon-v"><span class=3D"crayon-h"><span
class=3D"crayon-v">::</span></span><span
class=3D"crayon-v"></span>b></span><span
class=3D"crayon-sy">;</span></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba2772971485-4"><span class=3D"crayon-h"=
>=C2=A0=C2=A0=C2=A0=C2=A0</span><span
class=3D"crayon-t">int</span><span class=3D"crayon-h"> </span=
><span
class=3D"crayon-v"><span class=3D"crayon-h"><span
class=3D"crayon-h">_</span><</span></span>__name<span
class=3D"crayon-v"><span class=3D"crayon-v">::</span>c></s=
pan><span
class=3D"crayon-sy">;</span></div>
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba2772971485-5"=
><span
class=3D"crayon-sy">}</span><span class=3D"crayon-sy">;</span=
></div>
</div>
<br>
</blockquote>
This seems to be a tough requirement. Wouldn't that mean that all
structs with members of the same type have to be equivalent? Or
would just these non-static template variables have some special
ability to make structs equivalent?<br>
</blockquote>
The last.<br>
<blockquote cite=3D"mid:5511341A.803@eudoxos.de" type=3D"cite"> <br>
How about<br>
<br>
<tt>struct S</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 int </tt><tt><span class=3D"crayon-h">a</span><=
/tt><tt><span
class=3D"crayon-v"></span></tt><tt><span class=3D"crayon-sy">;<br=
>
=C2=A0=C2=A0 int b;<br>
};<br>
<br>
struct T<br>
{<br>
=C2=A0=C2=A0 </span></tt><span class=3D"crayon-sy"><tt>int </tt><=
tt><span
class=3D"crayon-h">_<</span></tt><tt>__name</tt><tt><span
class=3D"crayon-v">::a></span></tt><tt><span
class=3D"crayon-sy">;<br>
=C2=A0=C2=A0 int b;<br>
</span></tt><tt>};</tt><br>
</span><br>
Wouldd they also be equivalent?<br>
</blockquote>
I would say yes, but I have not think enough about the implications.
Do you see a problem?<br>
<blockquote cite=3D"mid:5511341A.803@eudoxos.de" type=3D"cite">
<blockquote cite=3D"mid:5510F753.8010602@wanadoo.fr" type=3D"cite"> <=
br>
and that <br>
<br>
<div class=3D"crayon-pre" style=3D"font-size: 12px !important;
line-height: 15px !important; -moz-tab-size:4; -o-tab-size:4;
-webkit-tab-size:4; tab-size:4;">
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba2772971485-1"=
><span
class=3D"crayon-t">struct</span><span class=3D"crayon-h"> </s=
pan><span
class=3D"crayon-e">S</span><span class=3D"crayon-h"> </span><=
span
class=3D"crayon-sy">{</span></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba2772971485-2"><span class=3D"crayon-h"=
>=C2=A0=C2=A0=C2=A0=C2=A0</span><span
class=3D"crayon-t">int</span><span class=3D"crayon-h"> _<<=
/span>__name<span
class=3D"crayon-v">::a></span><span class=3D"crayon-sy">;<=
/span></div>
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba2772971485-3"=
><span
class=3D"crayon-h">=C2=A0=C2=A0=C2=A0=C2=A0</span><span class=
=3D"crayon-t">int</span><span
class=3D"crayon-h"> a</span><span class=3D"crayon-v"></span><=
span
class=3D"crayon-sy">;</span></div>
<span class=3D"crayon-sy">}</span><span class=3D"crayon-sy">;</sp=
an></div>
<br>
would report a compile error.<br>
</blockquote>
<br>
How about <br>
<br>
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba2772971485-1"><tt=
><span
class=3D"crayon-t">struct</span></tt><tt><span
class=3D"crayon-h"> </span></tt><tt><span class=3D"crayon-e">S<=
/span></tt><tt><span
class=3D"crayon-h"> </span></tt><tt><span class=3D"crayon-sy">{=
<br>
=C2=A0 int </span></tt><tt><span class=3D"crayon-h">_<</span=
></tt><tt>__global_name</tt><tt><span
class=3D"crayon-v">s::a></span></tt><tt><span
class=3D"crayon-sy">;<br>
=C2=A0 int </span></tt><tt><span class=3D"crayon-sy"></span></t=
t><tt><span
class=3D"crayon-h">_<</span></tt><tt>__local_name</tt><tt><s=
pan
class=3D"crayon-v">s::a></span></tt><tt><span
class=3D"crayon-sy">;</span></tt></div>
<tt>};</tt><br>
<br>
</blockquote>
I don't see the need for global or local namespace for the types
representing symbols (names). All of them could/should be on the
same __name namespace.<br>
<blockquote cite=3D"mid:5511341A.803@eudoxos.de" type=3D"cite"> I would
have assumed from your earlier examples, that this would work
fine. But if the above should give a compile error, then this
should also not compile.<br>
<blockquote cite=3D"mid:5510F753.8010602@wanadoo.fr" type=3D"cite"> <=
br>
Resuming the two approaches could be seen as two sides of the
same coin. Your side gives a more friendly syntax, mine is
closer to the current language semantic once extended with
member data indexed by types, of course.<br>
</blockquote>
<br>
I really appreciate the effort to mimic the names with the
non-static template member variables. It is a neat idea on its
own. I do believe though that the idea of equivalence of structs
as described above adds quite a bit of complexity.<br>
</blockquote>
Can you elaborate?<br>
<blockquote cite=3D"mid:5511341A.803@eudoxos.de" type=3D"cite"> <br>
My "names" idea obviously introduces <br>
<ul>
<li>a new keyword, although I guess that could be circumvented
since it is "only" used in the template list. We could
probably reuse some existing keyword.<br>
</li>
<li>some way of specifying names</li>
</ul>
<p>I understand that especially the latter part is a major change.
Ease of use for library-developers and their users on the other
hand is one of the major goals of the "names" idea.<br>
</p>
</blockquote>
Hopping the transformation I have described could make it more
probable.<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" 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 />
--------------060807070504010501050208--
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Tue, 24 Mar 2015 22:23:47 +0100
Raw View
This is a multi-part message in MIME format.
--------------070308070302090800020503
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 2015-03-24 19:47, Vicente J. Botet Escriba wrote:
> Le 24/03/15 10:53, Roland Bock a =C3=A9crit :
>> On 2015-03-24 06:34, Vicente J. Botet Escriba wrote:
>>> Le 23/03/15 18:09, Roland Bock a =C3=A9crit :
>>>> In templates we can use types and values as parameters. We cannot
>>>> specify names though.
>>>>
>>>> But wouldn't it be cool to be able to parametrize templates with names=
? E.g.
>>>>
>>>> // ------------------------
>>>> template<typename Type,=20
>>>> name Name, // New template parameter type
>>>> Type Value>
>>>> struct Foo
>>>> {
>>>> Type Name =3D Value;
>>>> };
>>>> // ------------------------
>>>> =20
>>> An alternative could be to be able to define some kind of data
>>> members indexed by a type (something related to template variables
>>> instances).
>>>
>>> template<typename Type,=20
>>> typename Name, // New template parameter type
>>> Type Value>
>>> struct Foo
>>> {
>>> Type _<Name> =3D Value;
>>> };
>>>
>>> The use of _ is intended, meaning the data member name is not
>>> significant.
>>
>> Ah, ok, it took a while for me to grok that. So _<some_type> would be
>> a non-static template variable, right?
>>
>> I can't tell what would be a greater change to the language, but as
>> you mention yourself, ease of use would be better if we really had names=
..
> I'm not a compiler implementer, but I suspect that easy to implement
> would be an important factor.
You are certainly right that the effort of implementing this would be a
factor. Since I am also not a compiler developer, I have no idea about
the effort of either approach :-)
>>
>> using TabFoo =3D sqlpp::table<`tab_foo`,
>> int, `id`,
>> string, `name`
>> bool, `likesCpp`>;
>>
>> (slightly simplified, in reality there would be traits like
>> can_be_null or has_default to be set, too)
>>
>> b) using tables in code:
>>
>> auto left =3D TabFoo{}.as<`left`>;
>> auto right =3D TabFoo{}.as<`right`>
>>
>> for (row : db(select(left.id, right.id.as<`partnerId`>)
>> .from(left, right)
>> .where(left.id > right.id)))
>> {
>> std::cout << row.id << "," << row.partnerId << '\n';
>> }
>>
>> Much of the elegance would be lost if I had to create an extra type
>> for each name.
> Agreed, however I have not said that you must define them. These types
> could be generated by the compiler, that is be just like your names `foo`=
..
Then I missed something. I thought you're appoach would require
something like
using TabFoo =3D sqlpp::table<`tab_foo`,
int, __name::id,
string, __name::name
bool, __name::likesCpp>;
If the compiler can generate these, then __name would be a special
namespace extra for this purpose?
>
>>
>> Another really important feature is the ability to compare names.
>>
>> template<name X>
>> struct N{};
>>
>> struct Foo
>> {
>> using name =3D `dilbert`;
>> };
>> struct Bar
>> {
>> using name =3D `dilbert`;
>> };
>>
>> static_assert(std::is_same<N<Foo::name>,
>> N<Bar::name>>::value, "");
>>
>> If you wanted to achieve the same with types, then you would have
>> some project wide namespace for all the name-representing types which
>> might be quite awkward, IMHO.
> Right, it is the namespace __name. This IMO is an implementation detail.
Ok, I think I got your idea now.
>>
>>> However it doesn't need to introduce a new name keyword and a new
>>> kind of symbols.
>>>
>>> Another limitation of my alternative is that it doesn't work well
>>> with struct. Your example for StructOfArrays would need a struct S
>>> indexed by types
>>>
>>> [...]
>>>
>>> In some way we can say that your new name is some kind of syntactic
>>> sugar of my alternative
>>>
>>>
>>> and
>>> ms.foo
>>>
>>> to
>>>
>>> ms._<__name::foo>
>>
>> Comparing ms.foo to ms._<__name::foo> I know what I'd prefer :-)
> Me too. I want just to remove the need for a new kind of "Thing". What
> I mean is that both could be made equivalent.
Well, you have two new things if I am not mistaken:
a) a special namespace that lets the compiler generate types
automtically just by mentioning them
b) a non-static template member variable
>>
>>>
>>> We will need also that the struct
>>>
>>> structS{
>>> inta;
>>> intb;
>>> intc;
>>> };
>>>
>>> should be equivalent to
>>>
>>> structS{
>>> int_<__name::a>;
>>> int_<__name::b>;
>>> int_<__name::c>;
>>> };
>>>
>> This seems to be a tough requirement. Wouldn't that mean that all
>> structs with members of the same type have to be equivalent? Or would
>> just these non-static template variables have some special ability to
>> make structs equivalent?
> The last.
This is the third new thing: The non-static template member variables
have an ability unlike anything else. They can turn unrelated structs
into equivalents.
This is the fourth new thing: Equivalence. Obviously the two structs
above are not the same. Their members have totally different names. But
maybe they can be converted to each other with an automatically
generated conversion operator as soon as there are these special members?
>>
>> How about
>>
>> struct S
>> {
>> int a;
>> int b;
>> };
>>
>> struct T
>> {
>> int _<__name::a>;
>> int b;
>> };
>>
>> Wouldd they also be equivalent?
> I would say yes, but I have not think enough about the implications.
> Do you see a problem?
Seems to me that this would imply that
struct S { int b };
struct T { int b };
would be equivalent then too. But that is probably wrong. Please ignore.
>>>
>>> and that
>>>
>>> structS{
>>> int_<__name::a>;
>>> inta;
>>> };
>>>
>>> would report a compile error.
>>
>> How about
>>
>> structS{
>> int _<__global_names::a>;
>> int _<__local_names::a>;
>> };
>>
> I don't see the need for global or local namespace for the types
> representing symbols (names). All of them could/should be on the same
> __name namespace.
Got that.
>> I would have assumed from your earlier examples, that this would work
>> fine. But if the above should give a compile error, then this should
>> also not compile.
>>>
>>> Resuming the two approaches could be seen as two sides of the same
>>> coin. Your side gives a more friendly syntax, mine is closer to the
>>> current language semantic once extended with member data indexed by
>>> types, of course.
>>
>> I really appreciate the effort to mimic the names with the non-static
>> template member variables. It is a neat idea on its own. I do believe
>> though that the idea of equivalence of structs as described above
>> adds quite a bit of complexity.
> Can you elaborate?
As described above, equivalence seems to be kind of a new concept. I
might very well still be misunderstanding something, but I see the
following new things in total:
a) a special namespace that lets the compiler generate types
automtically just by mentioning them
b) a non-static template member variable
c) The non-static template member variables can turn unrelated structs
into equivalents
d) equivalent structs can be converted into each by default (not need to
write a conversion operator)
These do not seem like small changes to me either.
Sorry, if I misinterpreted something.
>>
>> My "names" idea obviously introduces
>>
>> * a new keyword, although I guess that could be circumvented since
>> it is "only" used in the template list. We could probably reuse
>> some existing keyword.
>> * some way of specifying names
>>
>> I understand that especially the latter part is a major change. Ease
>> of use for library-developers and their users on the other hand is
>> one of the major goals of the "names" idea.
>>
> Hopping the transformation I have described could make it more probable.
Yes, I got that and I am thankful for the discussion!
On the other hand, reflection has to deal with names, too. So maybe
names aren't such a huge thing to begin with.
Regards,
Roland
--=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/.
--------------070308070302090800020503
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">On 2015-03-24 19:47, Vicente J. Botet
Escriba wrote:<br>
</div>
<blockquote cite=3D"mid:5511B15F.3050205@wanadoo.fr" type=3D"cite">
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Ty=
pe">
<div class=3D"moz-cite-prefix">Le 24/03/15 10:53, Roland Bock a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote cite=3D"mid:5511341A.803@eudoxos.de" type=3D"cite">
<meta content=3D"text/html; charset=3Dutf-8"
http-equiv=3D"Content-Type">
<div class=3D"moz-cite-prefix">On 2015-03-24 06:34, Vicente J.
Botet Escriba wrote:<br>
</div>
<blockquote cite=3D"mid:5510F753.8010602@wanadoo.fr" type=3D"cite">
<meta content=3D"text/html; charset=3Dutf-8"
http-equiv=3D"Content-Type">
<div class=3D"moz-cite-prefix">Le 23/03/15 18:09, Roland Bock a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote cite=3D"mid:551048D2.2070907@eudoxos.de" type=3D"cite=
">
<pre wrap=3D"">In templates we can use types and values as para=
meters. We cannot
specify names though.
But wouldn't it be cool to be able to parametrize templates with names? E.g=
..
// ------------------------
template<typename Type,=20
name Name, // New template parameter type
Type Value>
struct Foo
{
Type Name =3D Value;
};
// ------------------------
</pre>
</blockquote>
</blockquote>
<blockquote cite=3D"mid:5510F753.8010602@wanadoo.fr" type=3D"cite">
An alternative could be to be able to define some kind of data
members indexed by a type (something related to template
variables instances).<br>
<br>
<pre wrap=3D"">template<typename Type,=20
typename Name, // New template parameter type
Type Value>
struct Foo
{
Type _<Name> =3D Value;
};
</pre>
<br>
The use of _ is intended, meaning the data member name is not
significant.<br>
</blockquote>
<br>
Ah, ok, it took a while for me to grok that. So
_<some_type> would be a non-static template variable,
right?<br>
<br>
I can't tell what would be a greater change to the language, but
as you mention yourself, ease of use would be better if we
really had names.<br>
</blockquote>
I'm not a compiler implementer, but I suspect that easy to
implement would be an important factor.<br>
</blockquote>
<br>
You are certainly right that the effort of implementing this would
be a factor. Since I am also not a compiler developer, I have no
idea about the effort of either approach :-)<br>
<br>
<blockquote cite=3D"mid:5511B15F.3050205@wanadoo.fr" type=3D"cite">
<blockquote cite=3D"mid:5511341A.803@eudoxos.de" type=3D"cite"> <br>
<tt>using TabFoo =3D sqlpp::table<`tab_foo`,</tt><tt><br>
</tt><tt>=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=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 int, `id`,</tt><tt><br>
</tt><tt>=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=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 string, `name</tt><tt>`</tt><tt><br>
</tt><tt>=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=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 bool, `likesCpp`>;</tt><tt><br>
</tt><br>
(slightly simplified, in reality there would be traits like
can_be_null or has_default to be set, too)<br>
<br>
b) using tables in code:<br>
<br>
<tt>auto left =3D TabFoo{}.as<`left`>;</tt><tt><br>
</tt><tt>auto right =3D TabFoo{}.as<`right`></tt><tt><br>
</tt><tt><br>
</tt><tt>for (row : db(select(left.id,
right.id.as<`partnerId`>)</tt><tt><br>
</tt><tt>=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 </tt><tt>.from(left, right)</tt><tt><br>
</tt><tt>=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 .where(left.id > right.id)))</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 std::cout << row.id << "," <&l=
t;
row.partnerId << '\n';</tt><tt><br>
</tt><tt>}</tt><tt><br>
</tt><br>
Much of the elegance would be lost if I had to create an extra
type for each name.<br>
</blockquote>
Agreed, however I have not said that you must define them. These
types could be generated by the compiler, that is be just like
your names `foo`.<br>
</blockquote>
Then I missed something. I thought you're appoach would require
something like<br>
<br>
<tt>using TabFoo =3D sqlpp::table<`tab_foo`,</tt><tt><br>
</tt><tt>=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=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 int, __name::id,</tt><tt><br>
</tt><tt>=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=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 string, __name::name</tt><tt><br>
</tt><tt>=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=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 bool, __name::likesCpp>;</tt><tt><br>
</tt><br>
If the compiler can generate these, then __name would be a special
namespace extra for this purpose?<br>
<br>
<br>
<br>
<blockquote cite=3D"mid:5511B15F.3050205@wanadoo.fr" type=3D"cite"><br>
<blockquote cite=3D"mid:5511341A.803@eudoxos.de" type=3D"cite"> <br>
Another really important feature is the ability to compare
names. <br>
<br>
<tt><tt>template<name X></tt><tt><br>
</tt><tt>struct N{};</tt><br>
<br>
struct Foo</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0=C2=A0 using name =3D `dilbert`;</tt><tt><br>
</tt><tt>};</tt><tt><br>
</tt><tt>struct Bar</tt><tt><br>
</tt><tt> {</tt><tt><br>
</tt><tt> =C2=A0=C2=A0=C2=A0 using name =3D `dilbert`;</tt><tt><br>
</tt><tt> };</tt><tt><br>
</tt><tt><br>
</tt><tt>static_assert(std::is_same<N<Foo::name>, </tt><tt=
><br>
</tt><tt>=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0
N<Bar::name>>::value, "");</tt><br>
<br>
If you wanted to achieve the same with types, then you would
have some project wide namespace for all the name-representing
types which might be quite awkward, IMHO.<br>
</blockquote>
Right, it is the namespace __name. This IMO is an implementation
detail.<br>
</blockquote>
<br>
Ok, I think I got your idea now.<br>
<br>
<blockquote cite=3D"mid:5511B15F.3050205@wanadoo.fr" type=3D"cite">
<blockquote cite=3D"mid:5511341A.803@eudoxos.de" type=3D"cite"><br>
<blockquote cite=3D"mid:5510F753.8010602@wanadoo.fr" type=3D"cite">
However it doesn't need to introduce a new name keyword and a
new kind of symbols.<br>
<br>
Another limitation of my alternative is that it doesn't work
well with struct. Your example for <span class=3D"crayon-h"></spa=
n><span
class=3D"crayon-e">StructOfArrays would need a struct S
indexed by types</span><br>
<br>
<meta http-equiv=3D"content-type" content=3D"text/html;
charset=3Dutf-8">
[...]<br>
<br>
In some way we can say that your new name is some kind of
syntactic sugar of my alternative<br>
<br>
<br>
and <br>
ms.foo<br>
<br>
to<br>
<br>
ms._<__name::foo><br>
</blockquote>
<br>
Comparing ms.foo to ms._<__name::foo> I know what I'd
prefer :-)<br>
</blockquote>
Me too. I want just to remove the need for a new kind of "Thing".
What I mean is that both could be made equivalent.<br>
</blockquote>
Well, you have two new things if I am not mistaken:<br>
<br>
a) a special namespace that lets the compiler generate types
automtically just by mentioning them<br>
b) a non-static template member variable<br>
<br>
<blockquote cite=3D"mid:5511B15F.3050205@wanadoo.fr" type=3D"cite">
<blockquote cite=3D"mid:5511341A.803@eudoxos.de" type=3D"cite"> <br>
<blockquote cite=3D"mid:5510F753.8010602@wanadoo.fr" type=3D"cite">
<br>
We will need also that the struct <br>
<br>
<div class=3D"crayon-pre" style=3D"font-size: 12px !important;
line-height: 15px !important; -moz-tab-size:4;
-o-tab-size:4; -webkit-tab-size:4; tab-size:4;">
<div class=3D"crayon-line"
id=3D"crayon-5510d6b098ba2772971485-1"><span
class=3D"crayon-t">struct</span><span class=3D"crayon-h"> <=
/span><span
class=3D"crayon-e">S</span><span class=3D"crayon-h"> </span=
><span
class=3D"crayon-sy">{</span></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba2772971485-2"><span
class=3D"crayon-h">=C2=A0=C2=A0=C2=A0=C2=A0</span><span cla=
ss=3D"crayon-t">int</span><span
class=3D"crayon-h"> </span><span class=3D"crayon-v">a</span=
><span
class=3D"crayon-sy">;</span></div>
<div class=3D"crayon-line"
id=3D"crayon-5510d6b098ba2772971485-3"><span
class=3D"crayon-h">=C2=A0=C2=A0=C2=A0=C2=A0</span><span cla=
ss=3D"crayon-t">int</span><span
class=3D"crayon-h"> </span><span class=3D"crayon-v"><span
class=3D"crayon-v"></span>b</span><span
class=3D"crayon-sy">;</span></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba2772971485-4"><span
class=3D"crayon-h">=C2=A0=C2=A0=C2=A0=C2=A0</span><span cla=
ss=3D"crayon-t">int</span><span
class=3D"crayon-h"> </span><span class=3D"crayon-v"><span
class=3D"crayon-v"></span>c</span><span
class=3D"crayon-sy">;</span></div>
<div class=3D"crayon-line"
id=3D"crayon-5510d6b098ba2772971485-5"><span
class=3D"crayon-sy">}</span><span class=3D"crayon-sy">;</sp=
an></div>
</div>
<br>
should be equivalent to<br>
<br>
<div class=3D"crayon-pre" style=3D"font-size: 12px !important;
line-height: 15px !important; -moz-tab-size:4;
-o-tab-size:4; -webkit-tab-size:4; tab-size:4;">
<div class=3D"crayon-line"
id=3D"crayon-5510d6b098ba2772971485-1"><span
class=3D"crayon-t">struct</span><span class=3D"crayon-h"> <=
/span><span
class=3D"crayon-e">S</span><span class=3D"crayon-h"> </span=
><span
class=3D"crayon-sy">{</span></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba2772971485-2"><span
class=3D"crayon-h">=C2=A0=C2=A0=C2=A0=C2=A0</span><span cla=
ss=3D"crayon-t">int</span><span
class=3D"crayon-h"> _<</span>__name<span
class=3D"crayon-v">::a></span><span class=3D"crayon-sy">=
;</span></div>
<div class=3D"crayon-line"
id=3D"crayon-5510d6b098ba2772971485-3"><span
class=3D"crayon-h">=C2=A0=C2=A0=C2=A0=C2=A0</span><span cla=
ss=3D"crayon-t">int</span><span
class=3D"crayon-h"> </span><span class=3D"crayon-v"><span
class=3D"crayon-h"><span class=3D"crayon-h">_</span><<=
/span></span>__name<span
class=3D"crayon-v"><span class=3D"crayon-h"><span
class=3D"crayon-v">::</span></span><span
class=3D"crayon-v"></span>b></span><span
class=3D"crayon-sy">;</span></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba2772971485-4"><span
class=3D"crayon-h">=C2=A0=C2=A0=C2=A0=C2=A0</span><span cla=
ss=3D"crayon-t">int</span><span
class=3D"crayon-h"> </span><span class=3D"crayon-v"><span
class=3D"crayon-h"><span class=3D"crayon-h">_</span><<=
/span></span>__name<span
class=3D"crayon-v"><span class=3D"crayon-v">::</span>c><=
/span><span
class=3D"crayon-sy">;</span></div>
<div class=3D"crayon-line"
id=3D"crayon-5510d6b098ba2772971485-5"><span
class=3D"crayon-sy">}</span><span class=3D"crayon-sy">;</sp=
an></div>
</div>
<br>
</blockquote>
This seems to be a tough requirement. Wouldn't that mean that
all structs with members of the same type have to be equivalent?
Or would just these non-static template variables have some
special ability to make structs equivalent?<br>
</blockquote>
The last.<br>
</blockquote>
This is the third new thing: The non-static template member
variables have an ability unlike anything else. They can turn
unrelated structs into equivalents.<br>
<br>
This is the fourth new thing: Equivalence. Obviously the two structs
above are not the same. Their members have totally different names.
But maybe they can be converted to each other with an automatically
generated conversion operator as soon as there are these special
members?<br>
<br>
<blockquote cite=3D"mid:5511B15F.3050205@wanadoo.fr" type=3D"cite">
<blockquote cite=3D"mid:5511341A.803@eudoxos.de" type=3D"cite"> <br>
How about<br>
<br>
<tt>struct S</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 int </tt><tt><span class=3D"crayon-h">a</span=
></tt><tt><span
class=3D"crayon-v"></span></tt><tt><span class=3D"crayon-sy">;<=
br>
=C2=A0=C2=A0 int b;<br>
};<br>
<br>
struct T<br>
{<br>
=C2=A0=C2=A0 </span></tt><span class=3D"crayon-sy"><tt>int </tt=
><tt><span
class=3D"crayon-h">_<</span></tt><tt>__name</tt><tt><span
class=3D"crayon-v">::a></span></tt><tt><span
class=3D"crayon-sy">;<br>
=C2=A0=C2=A0 int b;<br>
</span></tt><tt>};</tt><br>
</span><br>
Wouldd they also be equivalent?<br>
</blockquote>
I would say yes, but I have not think enough about the
implications. Do you see a problem?<br>
</blockquote>
Seems to me that this would imply that <br>
<br>
<tt>struct S { int b };</tt><tt><br>
</tt><tt>struct T { int b };</tt><tt><br>
</tt><br>
would be equivalent then too. But that is probably wrong. Please
ignore.<br>
<br>
<blockquote cite=3D"mid:5511B15F.3050205@wanadoo.fr" type=3D"cite">
<blockquote cite=3D"mid:5511341A.803@eudoxos.de" type=3D"cite">
<blockquote cite=3D"mid:5510F753.8010602@wanadoo.fr" type=3D"cite">
<br>
and that <br>
<br>
<div class=3D"crayon-pre" style=3D"font-size: 12px !important;
line-height: 15px !important; -moz-tab-size:4;
-o-tab-size:4; -webkit-tab-size:4; tab-size:4;">
<div class=3D"crayon-line"
id=3D"crayon-5510d6b098ba2772971485-1"><span
class=3D"crayon-t">struct</span><span class=3D"crayon-h"> <=
/span><span
class=3D"crayon-e">S</span><span class=3D"crayon-h"> </span=
><span
class=3D"crayon-sy">{</span></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba2772971485-2"><span
class=3D"crayon-h">=C2=A0=C2=A0=C2=A0=C2=A0</span><span cla=
ss=3D"crayon-t">int</span><span
class=3D"crayon-h"> _<</span>__name<span
class=3D"crayon-v">::a></span><span class=3D"crayon-sy">=
;</span></div>
<div class=3D"crayon-line"
id=3D"crayon-5510d6b098ba2772971485-3"><span
class=3D"crayon-h">=C2=A0=C2=A0=C2=A0=C2=A0</span><span cla=
ss=3D"crayon-t">int</span><span
class=3D"crayon-h"> a</span><span class=3D"crayon-v"></span=
><span
class=3D"crayon-sy">;</span></div>
<span class=3D"crayon-sy">}</span><span class=3D"crayon-sy">;</=
span></div>
<br>
would report a compile error.<br>
</blockquote>
<br>
How about <br>
<br>
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba2772971485-1"><=
tt><span
class=3D"crayon-t">struct</span></tt><tt><span
class=3D"crayon-h"> </span></tt><tt><span class=3D"crayon-e">=
S</span></tt><tt><span
class=3D"crayon-h"> </span></tt><tt><span class=3D"crayon-sy"=
>{<br>
=C2=A0 int </span></tt><tt><span class=3D"crayon-h">_<</sp=
an></tt><tt>__global_name</tt><tt><span
class=3D"crayon-v">s::a></span></tt><tt><span
class=3D"crayon-sy">;<br>
=C2=A0 int </span></tt><tt><span class=3D"crayon-sy"></span><=
/tt><tt><span
class=3D"crayon-h">_<</span></tt><tt>__local_name</tt><tt>=
<span
class=3D"crayon-v">s::a></span></tt><tt><span
class=3D"crayon-sy">;</span></tt></div>
<tt>};</tt><br>
<br>
</blockquote>
I don't see the need for global or local namespace for the types
representing symbols (names). All of them could/should be on the
same __name namespace.<br>
</blockquote>
<br>
Got that.<br>
<br>
<blockquote cite=3D"mid:5511B15F.3050205@wanadoo.fr" type=3D"cite">
<blockquote cite=3D"mid:5511341A.803@eudoxos.de" type=3D"cite"> I
would have assumed from your earlier examples, that this would
work fine. But if the above should give a compile error, then
this should also not compile.<br>
<blockquote cite=3D"mid:5510F753.8010602@wanadoo.fr" type=3D"cite">
<br>
Resuming the two approaches could be seen as two sides of the
same coin. Your side gives a more friendly syntax, mine is
closer to the current language semantic once extended with
member data indexed by types, of course.<br>
</blockquote>
<br>
I really appreciate the effort to mimic the names with the
non-static template member variables. It is a neat idea on its
own. I do believe though that the idea of equivalence of structs
as described above adds quite a bit of complexity.<br>
</blockquote>
Can you elaborate?<br>
</blockquote>
As described above, equivalence seems to be kind of a new concept. I
might very well still be misunderstanding something, but I see the
following new things in total:<br>
<br>
a) a special namespace that lets the compiler generate types
automtically just by mentioning them<br>
b) a non-static template member variable<br>
c) The non-static template member variables can turn unrelated
structs into equivalents<br>
d) equivalent structs can be converted into each by default (not
need to write a conversion operator)<br>
<br>
These do not seem like small changes to me either.<br>
Sorry, if I misinterpreted something.<br>
<br>
<blockquote cite=3D"mid:5511B15F.3050205@wanadoo.fr" type=3D"cite">
<blockquote cite=3D"mid:5511341A.803@eudoxos.de" type=3D"cite"> <br>
My "names" idea obviously introduces <br>
<ul>
<li>a new keyword, although I guess that could be circumvented
since it is "only" used in the template list. We could
probably reuse some existing keyword.<br>
</li>
<li>some way of specifying names</li>
</ul>
<p>I understand that especially the latter part is a major
change. Ease of use for library-developers and their users on
the other hand is one of the major goals of the "names" idea.<br>
</p>
</blockquote>
Hopping the transformation I have described could make it more
probable.<br>
</blockquote>
<br>
Yes, I got that and I am thankful for the discussion!<br>
<br>
On the other hand, reflection has to deal with names, too. So maybe
names aren't such a huge thing to begin with.<br>
<br>
Regards,<br>
<br>
Roland<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" 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 />
--------------070308070302090800020503--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 25 Mar 2015 04:39:36 +0100
Raw View
This is a multi-part message in MIME format.
--------------090201000604030008040003
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 24/03/15 22:23, Roland Bock a =C3=A9crit :
> On 2015-03-24 19:47, Vicente J. Botet Escriba wrote:
>> Le 24/03/15 10:53, Roland Bock a =C3=A9crit :
>>> On 2015-03-24 06:34, Vicente J. Botet Escriba wrote:
>>>> Le 23/03/15 18:09, Roland Bock a =C3=A9crit :
>>>>> In templates we can use types and values as parameters. We cannot
>>>>> specify names though.
>>>>>
>>>>> But wouldn't it be cool to be able to parametrize templates with name=
s? E.g.
>>>>>
>>>>> // ------------------------
>>>>> template<typename Type,
>>>>> name Name, // New template parameter type
>>>>> Type Value>
>>>>> struct Foo
>>>>> {
>>>>> Type Name =3D Value;
>>>>> };
>>>>> // ------------------------
>>>>> =20
>>>> An alternative could be to be able to define some kind of data=20
>>>> members indexed by a type (something related to template variables=20
>>>> instances).
>>>>
>>>> template<typename Type,
>>>> typename Name, // New template parameter type
>>>> Type Value>
>>>> struct Foo
>>>> {
>>>> Type _<Name> =3D Value;
>>>> };
>>>>
>>>> The use of _ is intended, meaning the data member name is not=20
>>>> significant.
>>>
>>> Ah, ok, it took a while for me to grok that. So _<some_type> would=20
>>> be a non-static template variable, right?
>>>
>>> I can't tell what would be a greater change to the language, but as=20
>>> you mention yourself, ease of use would be better if we really had=20
>>> names.
>> I'm not a compiler implementer, but I suspect that easy to implement=20
>> would be an important factor.
>
> You are certainly right that the effort of implementing this would be=20
> a factor. Since I am also not a compiler developer, I have no idea=20
> about the effort of either approach :-)
>
>>>
>>> using TabFoo =3D sqlpp::table<`tab_foo`,
>>> int, `id`,
>>> string, `name`
>>> bool, `likesCpp`>;
>>>
>>> (slightly simplified, in reality there would be traits like=20
>>> can_be_null or has_default to be set, too)
>>>
>>> b) using tables in code:
>>>
>>> auto left =3D TabFoo{}.as<`left`>;
>>> auto right =3D TabFoo{}.as<`right`>
>>>
>>> for (row : db(select(left.id, right.id.as<`partnerId`>)
>>> .from(left, right)
>>> .where(left.id > right.id)))
>>> {
>>> std::cout << row.id << "," << row.partnerId << '\n';
>>> }
>>>
>>> Much of the elegance would be lost if I had to create an extra type=20
>>> for each name.
>> Agreed, however I have not said that you must define them. These=20
>> types could be generated by the compiler, that is be just like your=20
>> names `foo`.
> Then I missed something. I thought you're appoach would require=20
> something like
>
> using TabFoo =3D sqlpp::table<`tab_foo`,
> int, __name::id,
> string, __name::name
> bool, __name::likesCpp>;
>
> If the compiler can generate these, then __name would be a special=20
> namespace extra for this purpose?
>
>
>
>>
>>>
>>> Another really important feature is the ability to compare names.
>>>
>>> template<name X>
>>> struct N{};
>>>
>>> struct Foo
>>> {
>>> using name =3D `dilbert`;
>>> };
>>> struct Bar
>>> {
>>> using name =3D `dilbert`;
>>> };
>>>
>>> static_assert(std::is_same<N<Foo::name>,
>>> N<Bar::name>>::value, "");
>>>
>>> If you wanted to achieve the same with types, then you would have=20
>>> some project wide namespace for all the name-representing types=20
>>> which might be quite awkward, IMHO.
>> Right, it is the namespace __name. This IMO is an implementation detail.
>
> Ok, I think I got your idea now.
>
>>>
>>>> However it doesn't need to introduce a new name keyword and a new=20
>>>> kind of symbols.
>>>>
>>>> Another limitation of my alternative is that it doesn't work well=20
>>>> with struct. Your example for StructOfArrays would need a struct S=20
>>>> indexed by types
>>>>
>>>> [...]
>>>>
>>>> In some way we can say that your new name is some kind of syntactic=20
>>>> sugar of my alternative
>>>>
>>>>
>>>> and
>>>> ms.foo
>>>>
>>>> to
>>>>
>>>> ms._<__name::foo>
>>>
>>> Comparing ms.foo to ms._<__name::foo> I know what I'd prefer :-)
>> Me too. I want just to remove the need for a new kind of "Thing".=20
>> What I mean is that both could be made equivalent.
> Well, you have two new things if I am not mistaken:
>
> a) a special namespace that lets the compiler generate types=20
> automtically just by mentioning them
> b) a non-static template member variable
>
>>>
>>>>
>>>> We will need also that the struct
>>>>
>>>> structS{
>>>> inta;
>>>> intb;
>>>> intc;
>>>> };
>>>>
>>>> should be equivalent to
>>>>
>>>> structS{
>>>> int_<__name::a>;
>>>> int_<__name::b>;
>>>> int_<__name::c>;
>>>> };
>>>>
>>> This seems to be a tough requirement. Wouldn't that mean that all=20
>>> structs with members of the same type have to be equivalent? Or=20
>>> would just these non-static template variables have some special=20
>>> ability to make structs equivalent?
>> The last.
> This is the third new thing: The non-static template member variables=20
> have an ability unlike anything else. They can turn unrelated structs=20
> into equivalents.
>
> This is the fourth new thing: Equivalence. Obviously the two structs=20
> above are not the same. Their members have totally different names.=20
> But maybe they can be converted to each other with an automatically=20
> generated conversion operator as soon as there are these special members?
>
My bad. I didn't thought too much about that. I don't want to introduce=20
any equivalence. Let say that _<_name::a> is a way to name the data=20
member a.
Declaring
structS{
inta;
};
structS{
int_<__name::a>;
};
would result on a compile error as S is declared twice.
>
>
>>> I would have assumed from your earlier examples, that this would=20
>>> work fine. But if the above should give a compile error, then this=20
>>> should also not compile.
>>>>
>>>> Resuming the two approaches could be seen as two sides of the same=20
>>>> coin. Your side gives a more friendly syntax, mine is closer to the=20
>>>> current language semantic once extended with member data indexed by=20
>>>> types, of course.
>>>
>>> I really appreciate the effort to mimic the names with the=20
>>> non-static template member variables. It is a neat idea on its own.=20
>>> I do believe though that the idea of equivalence of structs as=20
>>> described above adds quite a bit of complexity.
>> Can you elaborate?
> As described above, equivalence seems to be kind of a new concept. I=20
> might very well still be misunderstanding something, but I see the=20
> following new things in total:
>
> a) a special namespace that lets the compiler generate types=20
> automtically just by mentioning them
granted
> b) a non-static template member variable
A generator for a member variable names from a special kind of type=20
would define it better. This is already a major change.
> c) The non-static template member variables can turn unrelated structs=20
> into equivalents
I don't think we need the equivalence relation.
> d) equivalent structs can be converted into each by default (not need=20
> to write a conversion operator)
I don't think this is needed.
>
> These do not seem like small changes to me either.
Granted, even if the equivalence relation is not needed.
> Sorry, if I misinterpreted something.
>
>>>
>>> My "names" idea obviously introduces
>>>
>>> * a new keyword, although I guess that could be circumvented since
>>> it is "only" used in the template list. We could probably reuse
>>> some existing keyword.
>>> * some way of specifying names
>>>
>>> I understand that especially the latter part is a major change. Ease=20
>>> of use for library-developers and their users on the other hand is=20
>>> one of the major goals of the "names" idea.
>>>
>> Hopping the transformation I have described could make it more probable.
>
> Yes, I got that and I am thankful for the discussion!
>
Just I want to say that the alternative I've proposed is not better than=20
yours. It was in some way another way to say the same thing and it is=20
not simpler. At the semantic level there is not a big difference and=20
yours is much user friendly. So go ahead
Sorry for the distraction.
> On the other hand, reflection has to deal with names, too. So maybe=20
> names aren't such a huge thing to begin with.
>
>
Sure, having a way to generate/refer to data member names would help any=20
reflection library.
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/.
--------------090201000604030008040003
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 24/03/15 22:23, Roland Bock a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote cite=3D"mid:5511D5E3.50701@eudoxos.de" type=3D"cite">
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Ty=
pe">
<div class=3D"moz-cite-prefix">On 2015-03-24 19:47, Vicente J. Botet
Escriba wrote:<br>
</div>
<blockquote cite=3D"mid:5511B15F.3050205@wanadoo.fr" type=3D"cite">
<meta content=3D"text/html; charset=3Dutf-8"
http-equiv=3D"Content-Type">
<div class=3D"moz-cite-prefix">Le 24/03/15 10:53, Roland Bock a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote cite=3D"mid:5511341A.803@eudoxos.de" type=3D"cite">
<meta content=3D"text/html; charset=3Dutf-8"
http-equiv=3D"Content-Type">
<div class=3D"moz-cite-prefix">On 2015-03-24 06:34, Vicente J.
Botet Escriba wrote:<br>
</div>
<blockquote cite=3D"mid:5510F753.8010602@wanadoo.fr" type=3D"cite=
">
<meta content=3D"text/html; charset=3Dutf-8"
http-equiv=3D"Content-Type">
<div class=3D"moz-cite-prefix">Le 23/03/15 18:09, Roland Bock
a =C3=A9crit=C2=A0:<br>
</div>
<blockquote cite=3D"mid:551048D2.2070907@eudoxos.de"
type=3D"cite">
<pre wrap=3D"">In templates we can use types and values as pa=
rameters. We cannot
specify names though.
But wouldn't it be cool to be able to parametrize templates with names? E.g=
..
// ------------------------
template<typename Type,=20
name Name, // New template parameter type
Type Value>
struct Foo
{
Type Name =3D Value;
};
// ------------------------
</pre>
</blockquote>
</blockquote>
<blockquote cite=3D"mid:5510F753.8010602@wanadoo.fr" type=3D"cite=
">
An alternative could be to be able to define some kind of
data members indexed by a type (something related to
template variables instances).<br>
<br>
<pre wrap=3D"">template<typename Type,=20
typename Name, // New template parameter type
Type Value>
struct Foo
{
Type _<Name> =3D Value;
};
</pre>
<br>
The use of _ is intended, meaning the data member name is
not significant.<br>
</blockquote>
<br>
Ah, ok, it took a while for me to grok that. So
_<some_type> would be a non-static template variable,
right?<br>
<br>
I can't tell what would be a greater change to the language,
but as you mention yourself, ease of use would be better if we
really had names.<br>
</blockquote>
I'm not a compiler implementer, but I suspect that easy to
implement would be an important factor.<br>
</blockquote>
<br>
You are certainly right that the effort of implementing this would
be a factor. Since I am also not a compiler developer, I have no
idea about the effort of either approach :-)<br>
<br>
<blockquote cite=3D"mid:5511B15F.3050205@wanadoo.fr" type=3D"cite">
<blockquote cite=3D"mid:5511341A.803@eudoxos.de" type=3D"cite"> <br=
>
<tt>using TabFoo =3D sqlpp::table<`tab_foo`,</tt><tt><br>
</tt><tt>=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=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 int, `id`,</tt><tt><br>
</tt><tt>=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=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 string, `name</tt><tt>`</tt><tt><br>
</tt><tt>=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=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 bool, `likesCpp`>;</tt><tt><br>
</tt><br>
(slightly simplified, in reality there would be traits like
can_be_null or has_default to be set, too)<br>
<br>
b) using tables in code:<br>
<br>
<tt>auto left =3D TabFoo{}.as<`left`>;</tt><tt><br>
</tt><tt>auto right =3D TabFoo{}.as<`right`></tt><tt><br>
</tt><tt><br>
</tt><tt>for (row : db(select(left.id,
right.id.as<`partnerId`>)</tt><tt><br>
</tt><tt>=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 </tt><tt>.from(left, right)</tt><tt><br>
</tt><tt>=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 .where(left.id > right.id)))</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 std::cout << row.id << "," <=
<
row.partnerId << '\n';</tt><tt><br>
</tt><tt>}</tt><tt><br>
</tt><br>
Much of the elegance would be lost if I had to create an extra
type for each name.<br>
</blockquote>
Agreed, however I have not said that you must define them. These
types could be generated by the compiler, that is be just like
your names `foo`.<br>
</blockquote>
Then I missed something. I thought you're appoach would require
something like<br>
<br>
<tt>using TabFoo =3D sqlpp::table<`tab_foo`,</tt><tt><br>
</tt><tt>=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=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 int, __name::id,</tt><tt><br>
</tt><tt>=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=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 string, __name::name</tt><tt><br>
</tt><tt>=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=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 bool, __name::likesCpp>;</tt><tt><br>
</tt><br>
If the compiler can generate these, then __name would be a special
namespace extra for this purpose?<br>
<br>
<br>
<br>
<blockquote cite=3D"mid:5511B15F.3050205@wanadoo.fr" type=3D"cite"><b=
r>
<blockquote cite=3D"mid:5511341A.803@eudoxos.de" type=3D"cite"> <br=
>
Another really important feature is the ability to compare
names. <br>
<br>
<tt><tt>template<name X></tt><tt><br>
</tt><tt>struct N{};</tt><br>
<br>
struct Foo</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0=C2=A0 using name =3D `dilbert`;</tt><tt><br=
>
</tt><tt>};</tt><tt><br>
</tt><tt>struct Bar</tt><tt><br>
</tt><tt> {</tt><tt><br>
</tt><tt> =C2=A0=C2=A0=C2=A0 using name =3D `dilbert`;</tt><tt><b=
r>
</tt><tt> };</tt><tt><br>
</tt><tt><br>
</tt><tt>static_assert(std::is_same<N<Foo::name>, </tt><=
tt><br>
</tt><tt>=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0
N<Bar::name>>::value, "");</tt><br>
<br>
If you wanted to achieve the same with types, then you would
have some project wide namespace for all the name-representing
types which might be quite awkward, IMHO.<br>
</blockquote>
Right, it is the namespace __name. This IMO is an implementation
detail.<br>
</blockquote>
<br>
Ok, I think I got your idea now.<br>
<br>
<blockquote cite=3D"mid:5511B15F.3050205@wanadoo.fr" type=3D"cite">
<blockquote cite=3D"mid:5511341A.803@eudoxos.de" type=3D"cite"><br>
<blockquote cite=3D"mid:5510F753.8010602@wanadoo.fr" type=3D"cite=
">
However it doesn't need to introduce a new name keyword and
a new kind of symbols.<br>
<br>
Another limitation of my alternative is that it doesn't work
well with struct. Your example for <span class=3D"crayon-h"></s=
pan><span
class=3D"crayon-e">StructOfArrays would need a struct S
indexed by types</span><br>
<br>
<meta http-equiv=3D"content-type" content=3D"text/html;
charset=3Dutf-8">
[...]<br>
<br>
In some way we can say that your new name is some kind of
syntactic sugar of my alternative<br>
<br>
<br>
and <br>
ms.foo<br>
<br>
to<br>
<br>
ms._<__name::foo><br>
</blockquote>
<br>
Comparing ms.foo to ms._<__name::foo> I know what I'd
prefer :-)<br>
</blockquote>
Me too. I want just to remove the need for a new kind of
"Thing". What I mean is that both could be made equivalent.<br>
</blockquote>
Well, you have two new things if I am not mistaken:<br>
<br>
a) a special namespace that lets the compiler generate types
automtically just by mentioning them<br>
b) a non-static template member variable<br>
<br>
<blockquote cite=3D"mid:5511B15F.3050205@wanadoo.fr" type=3D"cite">
<blockquote cite=3D"mid:5511341A.803@eudoxos.de" type=3D"cite"> <br=
>
<blockquote cite=3D"mid:5510F753.8010602@wanadoo.fr" type=3D"cite=
">
<br>
We will need also that the struct <br>
<br>
<div class=3D"crayon-pre" style=3D"font-size: 12px !important;
line-height: 15px !important; -moz-tab-size:4;
-o-tab-size:4; -webkit-tab-size:4; tab-size:4;">
<div class=3D"crayon-line"
id=3D"crayon-5510d6b098ba2772971485-1"><span
class=3D"crayon-t">struct</span><span class=3D"crayon-h">
</span><span class=3D"crayon-e">S</span><span
class=3D"crayon-h"> </span><span class=3D"crayon-sy">{</s=
pan></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba2772971485-2"><span
class=3D"crayon-h">=C2=A0=C2=A0=C2=A0=C2=A0</span><span c=
lass=3D"crayon-t">int</span><span
class=3D"crayon-h"> </span><span class=3D"crayon-v">a</sp=
an><span
class=3D"crayon-sy">;</span></div>
<div class=3D"crayon-line"
id=3D"crayon-5510d6b098ba2772971485-3"><span
class=3D"crayon-h">=C2=A0=C2=A0=C2=A0=C2=A0</span><span c=
lass=3D"crayon-t">int</span><span
class=3D"crayon-h"> </span><span class=3D"crayon-v"><span
class=3D"crayon-v"></span>b</span><span
class=3D"crayon-sy">;</span></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba2772971485-4"><span
class=3D"crayon-h">=C2=A0=C2=A0=C2=A0=C2=A0</span><span c=
lass=3D"crayon-t">int</span><span
class=3D"crayon-h"> </span><span class=3D"crayon-v"><span
class=3D"crayon-v"></span>c</span><span
class=3D"crayon-sy">;</span></div>
<div class=3D"crayon-line"
id=3D"crayon-5510d6b098ba2772971485-5"><span
class=3D"crayon-sy">}</span><span class=3D"crayon-sy">;</=
span></div>
</div>
<br>
should be equivalent to<br>
<br>
<div class=3D"crayon-pre" style=3D"font-size: 12px !important;
line-height: 15px !important; -moz-tab-size:4;
-o-tab-size:4; -webkit-tab-size:4; tab-size:4;">
<div class=3D"crayon-line"
id=3D"crayon-5510d6b098ba2772971485-1"><span
class=3D"crayon-t">struct</span><span class=3D"crayon-h">
</span><span class=3D"crayon-e">S</span><span
class=3D"crayon-h"> </span><span class=3D"crayon-sy">{</s=
pan></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba2772971485-2"><span
class=3D"crayon-h">=C2=A0=C2=A0=C2=A0=C2=A0</span><span c=
lass=3D"crayon-t">int</span><span
class=3D"crayon-h"> _<</span>__name<span
class=3D"crayon-v">::a></span><span class=3D"crayon-sy=
">;</span></div>
<div class=3D"crayon-line"
id=3D"crayon-5510d6b098ba2772971485-3"><span
class=3D"crayon-h">=C2=A0=C2=A0=C2=A0=C2=A0</span><span c=
lass=3D"crayon-t">int</span><span
class=3D"crayon-h"> </span><span class=3D"crayon-v"><span
class=3D"crayon-h"><span class=3D"crayon-h">_</span><=
;</span></span>__name<span
class=3D"crayon-v"><span class=3D"crayon-h"><span
class=3D"crayon-v">::</span></span><span
class=3D"crayon-v"></span>b></span><span
class=3D"crayon-sy">;</span></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba2772971485-4"><span
class=3D"crayon-h">=C2=A0=C2=A0=C2=A0=C2=A0</span><span c=
lass=3D"crayon-t">int</span><span
class=3D"crayon-h"> </span><span class=3D"crayon-v"><span
class=3D"crayon-h"><span class=3D"crayon-h">_</span><=
;</span></span>__name<span
class=3D"crayon-v"><span class=3D"crayon-v">::</span>c>=
;</span><span
class=3D"crayon-sy">;</span></div>
<div class=3D"crayon-line"
id=3D"crayon-5510d6b098ba2772971485-5"><span
class=3D"crayon-sy">}</span><span class=3D"crayon-sy">;</=
span></div>
</div>
<br>
</blockquote>
This seems to be a tough requirement. Wouldn't that mean that
all structs with members of the same type have to be
equivalent? Or would just these non-static template variables
have some special ability to make structs equivalent?<br>
</blockquote>
The last.<br>
</blockquote>
This is the third new thing: The non-static template member
variables have an ability unlike anything else. They can turn
unrelated structs into equivalents.<br>
<br>
This is the fourth new thing: Equivalence. Obviously the two
structs above are not the same. Their members have totally
different names. But maybe they can be converted to each other
with an automatically generated conversion operator as soon as
there are these special members?<br>
<br>
</blockquote>
My bad. I didn't thought too much about that. I don't want to
introduce any equivalence. Let say that _<_name::a> is a way
to name the data member a. <br>
<br>
Declaring<br>
<br>
<div class=3D"crayon-pre" style=3D"font-size: 12px !important;
line-height: 15px !important; -moz-tab-size:4; -o-tab-size:4;
-webkit-tab-size:4; tab-size:4;">
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba2772971485-1"><sp=
an
class=3D"crayon-t">struct</span><span class=3D"crayon-h"> </span>=
<span
class=3D"crayon-e">S</span><span class=3D"crayon-h"> </span><span
class=3D"crayon-sy">{</span></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba2772971485-2"><span class=3D"crayon-h">=C2=
=A0=C2=A0=C2=A0=C2=A0</span><span
class=3D"crayon-t">int</span><span class=3D"crayon-h"> </span><sp=
an
class=3D"crayon-v">a</span><span class=3D"crayon-sy">;</span></di=
v>
<span class=3D"crayon-sy">}</span><span class=3D"crayon-sy">;</span> =
</div>
<span class=3D"crayon-t">struct</span><span class=3D"crayon-h"> </span>=
<span
class=3D"crayon-e">S</span><span class=3D"crayon-h"> </span><span
class=3D"crayon-sy">{</span>
<div class=3D"crayon-pre" style=3D"font-size: 12px !important;
line-height: 15px !important; -moz-tab-size:4; -o-tab-size:4;
-webkit-tab-size:4; tab-size:4;">
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba2772971485-2"><span class=3D"crayon-h">=C2=
=A0=C2=A0=C2=A0=C2=A0</span><span
class=3D"crayon-t">int</span><span class=3D"crayon-h"> _<</spa=
n>__name<span
class=3D"crayon-v">::a></span><span class=3D"crayon-sy">;</spa=
n></div>
<span class=3D"crayon-sy">}</span><span class=3D"crayon-sy">;</span> =
</div>
<br>
would result on a compile error as S is declared twice. <br>
<blockquote cite=3D"mid:5511D5E3.50701@eudoxos.de" type=3D"cite"> <br>
<br>
<blockquote cite=3D"mid:5511B15F.3050205@wanadoo.fr" type=3D"cite">
<blockquote cite=3D"mid:5511341A.803@eudoxos.de" type=3D"cite"> I
would have assumed from your earlier examples, that this would
work fine. But if the above should give a compile error, then
this should also not compile.<br>
<blockquote cite=3D"mid:5510F753.8010602@wanadoo.fr" type=3D"cite=
">
<br>
Resuming the two approaches could be seen as two sides of
the same coin. Your side gives a more friendly syntax, mine
is closer to the current language semantic once extended
with member data indexed by types, of course.<br>
</blockquote>
<br>
I really appreciate the effort to mimic the names with the
non-static template member variables. It is a neat idea on its
own. I do believe though that the idea of equivalence of
structs as described above adds quite a bit of complexity.<br>
</blockquote>
Can you elaborate?<br>
</blockquote>
As described above, equivalence seems to be kind of a new concept.
I might very well still be misunderstanding something, but I see
the following new things in total:<br>
<br>
a) a special namespace that lets the compiler generate types
automtically just by mentioning them<br>
</blockquote>
granted<br>
<blockquote cite=3D"mid:5511D5E3.50701@eudoxos.de" type=3D"cite"> b) a
non-static template member variable<br>
</blockquote>
A generator for a member variable names from a special kind of type
would define it better. This is already a major change.<br>
<blockquote cite=3D"mid:5511D5E3.50701@eudoxos.de" type=3D"cite"> c) Th=
e
non-static template member variables can turn unrelated structs
into equivalents<br>
</blockquote>
I don't think we need the equivalence relation.<br>
<blockquote cite=3D"mid:5511D5E3.50701@eudoxos.de" type=3D"cite"> d)
equivalent structs can be converted into each by default (not need
to write a conversion operator)<br>
</blockquote>
I don't think this is needed.<br>
<blockquote cite=3D"mid:5511D5E3.50701@eudoxos.de" type=3D"cite"> <br>
These do not seem like small changes to me either.<br>
</blockquote>
Granted, even if the equivalence relation is not needed.<br>
<blockquote cite=3D"mid:5511D5E3.50701@eudoxos.de" type=3D"cite"> Sorry=
,
if I misinterpreted something.<br>
</blockquote>
<br>
<blockquote cite=3D"mid:5511D5E3.50701@eudoxos.de" type=3D"cite"> <br>
<blockquote cite=3D"mid:5511B15F.3050205@wanadoo.fr" type=3D"cite">
<blockquote cite=3D"mid:5511341A.803@eudoxos.de" type=3D"cite"> <br=
>
My "names" idea obviously introduces <br>
<ul>
<li>a new keyword, although I guess that could be
circumvented since it is "only" used in the template list.
We could probably reuse some existing keyword.<br>
</li>
<li>some way of specifying names</li>
</ul>
<p>I understand that especially the latter part is a major
change. Ease of use for library-developers and their users
on the other hand is one of the major goals of the "names"
idea.<br>
</p>
</blockquote>
Hopping the transformation I have described could make it more
probable.<br>
</blockquote>
<br>
Yes, I got that and I am thankful for the discussion!<br>
<br>
</blockquote>
Just I want to say that the alternative I've proposed is not better
than yours. It was in some way another way to say the same thing and
it is not simpler. At the semantic level there is not a big
difference and yours is much user friendly. So go ahead<br>
Sorry for the distraction.<br>
<br>
<blockquote cite=3D"mid:5511D5E3.50701@eudoxos.de" type=3D"cite"> On th=
e
other hand, reflection has to deal with names, too. So maybe names
aren't such a huge thing to begin with.<br>
<br>
<br>
</blockquote>
Sure, having a way to generate/refer to data member names would help
any reflection library. <br>
<br>
Vicente<br>
<br>
<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" 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 />
--------------090201000604030008040003--
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Wed, 25 Mar 2015 07:28:54 +0100
Raw View
This is a multi-part message in MIME format.
--------------010304090306040401090806
Content-Type: text/plain; charset=UTF-8
On 2015-03-25 04:39, Vicente J. Botet Escriba wrote:
> My bad. I didn't thought too much about that. I don't want to
> introduce any equivalence. Let say that _<_name::a> is a way to name
> the data member a.
>
> Declaring
>
> structS{
> inta;
> };
> structS{
> int_<__name::a>;
> };
>
> would result on a compile error as S is declared twice.
Got it. So basically it would be difference in notation:
My proposal is
template<name X>
struct T
{
int X;
};
auto t = T<`sample`>{7};
t.sample = 42;
This would require
* name literals
* name keyword in templates (or re-using an existing one)
You're suggesting an alternative way by saying
template<typename X>
struct T
{
int _<X>;
};
auto t = T<__name::sample>{};
assert(&t._<__name::sample> == &t.sample);
This would require
* A special namespace, e.g. __name, which has the feature that
typenames inside this namespace can be used in
* a special construct that is interpreted like a member name
So the approaches are almost the same:
* a name keyword in the template parameter list vs. a special __name
namespace
* a name literal vs a special construct that iterprets types from the
special namespace
They would even work the same for something I haven't mentioned yet, but
came up quickly in the discussion at CppCon: concatenation of names
In order to avoid name clashes in the constructor, concatenation might
be helpful:
template<name X>
struct T
{
int X;
T(int X`arg`):X(X`arg`){}
};
This ensures that the argument name in the constructor can never
conflict with X.
Same would work for your approach if the naming construct were variadic:
template<typename X>
struct T
{
int _<X>;
T(int _<X, __name::_arg>):X(_<X, __name::_arg>){}
};
>>> Hopping the transformation I have described could make it more probable.
>>
>> Yes, I got that and I am thankful for the discussion!
>>
> Just I want to say that the alternative I've proposed is not better
> than yours. It was in some way another way to say the same thing and
> it is not simpler. At the semantic level there is not a big difference
> and yours is much user friendly. So go ahead
> Sorry for the distraction.
No worries, it was quite interesting to see the type idea develop :-)
Best,
Roland
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
--------------010304090306040401090806
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">On 2015-03-25 04:39, Vicente J. Botet
Escriba wrote:<br>
</div>
<blockquote cite=3D"mid:55122DF8.6080001@wanadoo.fr" type=3D"cite">
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Ty=
pe">
My bad. I didn't thought too much about that. I don't want to
introduce any equivalence. Let say that _<_name::a> is a way
to name the data member a. <br>
<br>
Declaring<br>
<br>
<div class=3D"crayon-pre" style=3D"font-size: 12px !important;
line-height: 15px !important; -moz-tab-size:4; -o-tab-size:4;
-webkit-tab-size:4; tab-size:4;">
<div class=3D"crayon-line" id=3D"crayon-5510d6b098ba2772971485-1"><=
span
class=3D"crayon-t">struct</span><span class=3D"crayon-h"> </spa=
n><span
class=3D"crayon-e">S</span><span class=3D"crayon-h"> </span><sp=
an
class=3D"crayon-sy">{</span></div>
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba2772971485-2"><span class=3D"crayon-h">=
=C2=A0=C2=A0=C2=A0=C2=A0</span><span
class=3D"crayon-t">int</span><span class=3D"crayon-h"> </span><=
span
class=3D"crayon-v">a</span><span class=3D"crayon-sy">;</span></=
div>
<span class=3D"crayon-sy">}</span><span class=3D"crayon-sy">;</span=
>
</div>
<span class=3D"crayon-t">struct</span><span class=3D"crayon-h"> </spa=
n><span
class=3D"crayon-e">S</span><span class=3D"crayon-h"> </span><span
class=3D"crayon-sy">{</span>
<div class=3D"crayon-pre" style=3D"font-size: 12px !important;
line-height: 15px !important; -moz-tab-size:4; -o-tab-size:4;
-webkit-tab-size:4; tab-size:4;">
<div class=3D"crayon-line crayon-striped-line"
id=3D"crayon-5510d6b098ba2772971485-2"><span class=3D"crayon-h">=
=C2=A0=C2=A0=C2=A0=C2=A0</span><span
class=3D"crayon-t">int</span><span class=3D"crayon-h"> _<</s=
pan>__name<span
class=3D"crayon-v">::a></span><span class=3D"crayon-sy">;</s=
pan></div>
<span class=3D"crayon-sy">}</span><span class=3D"crayon-sy">;</span=
>
</div>
<br>
would result on a compile error as S is declared twice. <br>
</blockquote>
<br>
Got it. So basically it would be difference in notation:<br>
<br>
My proposal is<br>
<br>
<tt>template<name X></tt><tt><br>
</tt><tt>struct T</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 int X;</tt><tt><br>
</tt><tt>};</tt><tt><br>
</tt><tt>auto t =3D T<`sample`>{7};</tt><tt><br>
</tt><tt>t.sample =3D 42;</tt><br>
<br>
This would require<br>
<ul>
<li>name literals</li>
<li>name keyword in templates (or re-using an existing one)</li>
</ul>
<p><br>
</p>
<p>You're suggesting an alternative way by saying<br>
</p>
<br>
<tt>template<typename X></tt><tt><br>
</tt><tt>struct T</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0=C2=A0 int _<X>;</tt><tt><br>
</tt><tt>};</tt><tt><br>
</tt><tt>auto t =3D T<__name::sample>{};</tt><tt><br>
</tt><tt>assert(&t._<__name::sample> =3D=3D &t.sample);</=
tt><br>
<br>
This would require<br>
<ul>
<li>A special namespace, e.g. __name, which has the feature that
typenames inside this namespace can be used in <br>
</li>
<li>a special construct that is interpreted like a member name</li>
</ul>
<p><br>
So the approaches are almost the same:<br>
</p>
<ul>
<li>a name keyword in the template parameter list vs. a special
__name namespace</li>
<li>a name literal vs a special construct that iterprets types
from the special namespace</li>
</ul>
<p>They would even work the same for something I haven't mentioned
yet, but came up quickly in the discussion at CppCon:
concatenation of names<br>
</p>
<p>In order to avoid name clashes in the constructor, concatenation
might be helpful:<br>
</p>
<p><tt>template<name X></tt><tt><br>
</tt><tt>struct T</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 int X;<br>
=C2=A0=C2=A0 T(int X`arg`):X(X`arg`){}<br>
};</tt><br>
</p>
This ensures that the argument name in the constructor can never
conflict with X.<br>
<br>
Same would work for your approach if the naming construct were
variadic:<br>
<p><tt>template<typename X></tt><tt><br>
</tt><tt>struct T</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 int _<X>;<br>
=C2=A0=C2=A0 T(int _<X, __name::_arg>):X(</tt><tt><tt>_<X,
__name::_arg></tt>){}<br>
};</tt><br>
</p>
<br>
<blockquote cite=3D"mid:55122DF8.6080001@wanadoo.fr" type=3D"cite">
<blockquote cite=3D"mid:5511D5E3.50701@eudoxos.de" type=3D"cite">
<blockquote cite=3D"mid:5511B15F.3050205@wanadoo.fr" type=3D"cite">
<blockquote cite=3D"mid:5511341A.803@eudoxos.de" type=3D"cite"> <=
/blockquote>
Hopping the transformation I have described could make it more
probable.<br>
</blockquote>
<br>
Yes, I got that and I am thankful for the discussion!<br>
<br>
</blockquote>
Just I want to say that the alternative I've proposed is not
better than yours. It was in some way another way to say the same
thing and it is not simpler. At the semantic level there is not a
big difference and yours is much user friendly. So go ahead<br>
Sorry for the distraction.<br>
</blockquote>
<br>
No worries, it was quite interesting to see the type idea develop
:-)<br>
<br>
Best,<br>
<br>
Roland<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" 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 />
--------------010304090306040401090806--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Wed, 25 Mar 2015 11:04:58 -0400
Raw View
On 2015-03-24 17:23, Roland Bock wrote:
> This is the third new thing: The non-static template member variables
> have an ability unlike anything else. They can turn unrelated structs
> into equivalents.
>
> This is the fourth new thing: Equivalence. Obviously the two structs
> above are not the same. Their members have totally different names. But
> maybe they can be converted to each other with an automatically
> generated conversion operator as soon as there are these special members?
I was thinking about this some, and how my "optimal outcome" of such a
feature would be for the std::map::iterator::operator->() type to
*finally* have members "key" and "value" instead of the obnoxious
"first" and "second". (Well, "in addition to", technically, since of
course we need to be backwards compatible.)
For compatibility, this would also need to implicitly convert to - or
more likely, be polymorphic with - a std::pair with the "usual" names.
(I think this is possible by subclassing the 'normal' pair and using
expression aliases to provide the 'renamed' members. Actually, come to
think of it, that doesn't even need this proposal, although it would be
interesting for std::map to use a flavor of std::pair using this idea,
if only for the sake of having such a std::pair that is implicitly
compatible with the generic version.)
Point being... I think the "right" implementation for equivalence is to
have a generic version and a version with user-defined names, with the
latter subclassing the former. This allows implicitly using the latter
as the former, but requires a static_cast to go the other direction,
which seems like TRRTD. Mind, a static_cast from an A to a B, where A
and B are different (both conceptually and in the typesystem), but have
the same structure (e.g. both are pair<int, double>), would be allowable
and permit "conversion" from A to B, whether or not such a conversion
makes conceptual sense.
Additionally...
> Seems to me that this would imply that
>
> struct S { int b };
> struct T { int b };
>
> would be equivalent then too. But that is probably wrong. Please ignore.
....it means this doesn't happen, since the equivalence is through
polymorphism (which isn't present above... although, similarly, you can
already "meaningfully" reinterpret_cast between T* and S* today).
--
Matthew
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Wed, 25 Mar 2015 18:36:01 +0100
Raw View
On 2015-03-25 16:04, Matthew Woehlke wrote:
> On 2015-03-24 17:23, Roland Bock wrote:
>> This is the third new thing: The non-static template member variables
>> have an ability unlike anything else. They can turn unrelated structs
>> into equivalents.
>>
>> This is the fourth new thing: Equivalence. Obviously the two structs
>> above are not the same. Their members have totally different names. But
>> maybe they can be converted to each other with an automatically
>> generated conversion operator as soon as there are these special members?
> I was thinking about this some, and how my "optimal outcome" of such a
> feature would be for the std::map::iterator::operator->() type to
> *finally* have members "key" and "value" instead of the obnoxious
> "first" and "second". (Well, "in addition to", technically, since of
> course we need to be backwards compatible.)
"In addition" is a nice idea. Do we (plan to) have aliases for members?
We have aliases for types and templates...
If we had aliases for members, then pair could get two new optional
template parameters:
template<typename T1, typename T2,
name N1 = `first`, name N2 = `second`>
struct pair
{
T1 first|N1; // Inventing syntax here...
T2 second|N2; // duplicates to be ignored
//...
};
And the value_type of a map could then be defined to
using value_type = std::pair<Key, T, `key`, `value`>;
This would give you backwards compatibility (you could still call the
members `first` and `second`) and you could also call the members `key`
and `value`.
Yeah, I'd love that :-)
> For compatibility, this would also need to implicitly convert to - or
> more likely, be polymorphic with - a std::pair with the "usual" names.
> (I think this is possible by subclassing the 'normal' pair and using
> expression aliases to provide the 'renamed' members.
Could you show how you would do that?
> Actually, come to
> think of it, that doesn't even need this proposal, although it would be
> interesting for std::map to use a flavor of std::pair using this idea,
> if only for the sake of having such a std::pair that is implicitly
> compatible with the generic version.)
See above :-)
Cheers,
Roland
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Wed, 25 Mar 2015 17:13:26 -0400
Raw View
On 2015-03-25 13:36, Roland Bock wrote:
> On 2015-03-25 16:04, Matthew Woehlke wrote:
>> On 2015-03-24 17:23, Roland Bock wrote:
>>> This is the third new thing: The non-static template member variables
>>> have an ability unlike anything else. They can turn unrelated structs
>>> into equivalents.
>>>
>>> This is the fourth new thing: Equivalence. Obviously the two structs
>>> above are not the same. Their members have totally different names. But
>>> maybe they can be converted to each other with an automatically
>>> generated conversion operator as soon as there are these special members?
>> I was thinking about this some, and how my "optimal outcome" of such a
>> feature would be for the std::map::iterator::operator->() type to
>> *finally* have members "key" and "value" instead of the obnoxious
>> "first" and "second". (Well, "in addition to", technically, since of
>> course we need to be backwards compatible.)
>
> "In addition" is a nice idea. Do we (plan to) have aliases for members?
> We have aliases for types and templates...
This would probably need to use the 'expression aliases' feature that
keeps popping up. (Another reason to actually get that into the language...)
> If we had aliases for members, then pair could get two new optional
> template parameters:
>
> template<typename T1, typename T2,
> name N1 = `first`, name N2 = `second`>
> struct pair
> {
> T1 first|N1; // Inventing syntax here...
> T2 second|N2; // duplicates to be ignored
> //...
> };
>
> And the value_type of a map could then be defined to
>
> using value_type = std::pair<Key, T, `key`, `value`>;
>
> This would give you backwards compatibility (you could still call the
> members `first` and `second`) and you could also call the members `key`
> and `value`.
The problem here is with what I was talking about in the last mail; it
*must* (for compatibility) implicitly convert to a std::pair with the
default names. That's why I was thinking subclassing. (Also because I'm
not sure how to write the members / aliases so that they are omitted if
the default names are used. Subclassing would solve that problem by
simply declaring that you only use the subclass if you use other names,
and since you can implicitly convert to the base class, you get the
required source compatibility.)
Otherwise, yes, that's the idea :-).
>> For compatibility, this would also need to implicitly convert to - or
>> more likely, be polymorphic with - a std::pair with the "usual" names.
>> (I think this is possible by subclassing the 'normal' pair and using
>> expression aliases to provide the 'renamed' members.
>
> Could you show how you would do that?
template <typename T1, typename T2, name N1, name N2>
struct named_pair : pair<T1, T2>
{
using constexpr N1 = first; // note: this is an expression alias
using constexpr N2 = second;
};
Now, a named_pair<A, B, `key`, `value`> is implicitly convertible (both
copy and reference) to a pair<A, B>, since the latter is a base class of
the former, but given such a critter 'i', you can write 'i.value' to
access the member 'pair<A, B>::second'.
>> Actually, come to think of it, that doesn't even need this
>> proposal, although it would be interesting for std::map to use a
>> flavor of std::pair using this idea, if only for the sake of having
>> such a std::pair that is implicitly compatible with the generic
>> version.)
>
> See above :-)
Without this proposal (but still requiring expression aliases), you
could write:
// within map<KeyType, ValueType>
struct node : pair<KeyType, ValueType>
{
using constexpr key = first;
using constexpr value = second;
};
However, being able to express the map's node type like:
// within map<KeyType, ValueType>
using node = named_pair<KeyType, ValueType, `key`, `value`>
....would be a good use case for your feature, both to ensure that it
works, and to avoid a completely local structure in std::map.
--
Matthew
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Thu, 26 Mar 2015 07:28:37 +0100
Raw View
On 2015-03-25 22:13, Matthew Woehlke wrote:
> On 2015-03-25 13:36, Roland Bock wrote:
>> On 2015-03-25 16:04, Matthew Woehlke wrote:
>>> On 2015-03-24 17:23, Roland Bock wrote:
>>>> This is the third new thing: The non-static template member variables
>>>> have an ability unlike anything else. They can turn unrelated structs
>>>> into equivalents.
>>>>
>>>> This is the fourth new thing: Equivalence. Obviously the two structs
>>>> above are not the same. Their members have totally different names. But
>>>> maybe they can be converted to each other with an automatically
>>>> generated conversion operator as soon as there are these special members?
>>> I was thinking about this some, and how my "optimal outcome" of such a
>>> feature would be for the std::map::iterator::operator->() type to
>>> *finally* have members "key" and "value" instead of the obnoxious
>>> "first" and "second". (Well, "in addition to", technically, since of
>>> course we need to be backwards compatible.)
>> "In addition" is a nice idea. Do we (plan to) have aliases for members?
>> We have aliases for types and templates...
> This would probably need to use the 'expression aliases' feature that
> keeps popping up. (Another reason to actually get that into the language...)
Missed those, but yes, it would be a very nice feature :-)
>
>> If we had aliases for members, then pair could get two new optional
>> template parameters:
>>
>> template<typename T1, typename T2,
>> name N1 = `first`, name N2 = `second`>
>> struct pair
>> {
>> T1 first|N1; // Inventing syntax here...
>> T2 second|N2; // duplicates to be ignored
>> //...
>> };
>>
>> And the value_type of a map could then be defined to
>>
>> using value_type = std::pair<Key, T, `key`, `value`>;
>>
>> This would give you backwards compatibility (you could still call the
>> members `first` and `second`) and you could also call the members `key`
>> and `value`.
> The problem here is with what I was talking about in the last mail; it
> *must* (for compatibility) implicitly convert to a std::pair with the
> default names.
Rules for implicit conversion tend to take me by surprise, so I am
probably missing something, but wouldn't it be sufficient if named_pair
had conversion operators in both directions?
template<typename T1, typename T2, name N1, name N2>
struct named_pair
{
T1 N1;
T2 N2;
named_pair(const pair<T1,T2>&);
named_pair(pair<T1,T2>&&);
operator pair<T1, T2>&()
{
return reinterpret_cast<pair<T1,T2>&>(*this);
}
operator const pair<T1, T2>&() const;
};
std::pair could also have templated conversion operators in both directions.
template<typename T1, typename T2>
struct pair
{
T1 first;
T2 second;
template<name N1, name N2>
named_pair(const named_pair<T1,T2,N1,N2>&);
template<name N1, name N2>
named_pair(pair<T1,T2,N1,N2>&&);
template<name N1, name N2>
operator pair<T1, T2,N1,N2>&()
{
return reinterpret_cast<pair<T1,T2,N1,N2>&>(*this);
}
template<name N1, name N2>
operator const pair<T1,T2,N1,N2>&() const;
};
> That's why I was thinking subclassing. (Also because I'm
> not sure how to write the members / aliases so that they are omitted if
> the default names are used. Subclassing would solve that problem by
> simply declaring that you only use the subclass if you use other names,
> and since you can implicitly convert to the base class, you get the
> required source compatibility.)
>
> Otherwise, yes, that's the idea :-).
>
>>> For compatibility, this would also need to implicitly convert to - or
>>> more likely, be polymorphic with - a std::pair with the "usual" names.
>>> (I think this is possible by subclassing the 'normal' pair and using
>>> expression aliases to provide the 'renamed' members.
>> Could you show how you would do that?
> template <typename T1, typename T2, name N1, name N2>
> struct named_pair : pair<T1, T2>
> {
> using constexpr N1 = first; // note: this is an expression alias
> using constexpr N2 = second;
> };
>
> Now, a named_pair<A, B, `key`, `value`> is implicitly convertible (both
> copy and reference) to a pair<A, B>, since the latter is a base class of
> the former, but given such a critter 'i', you can write 'i.value' to
> access the member 'pair<A, B>::second'.
>
>>> Actually, come to think of it, that doesn't even need this
>>> proposal, although it would be interesting for std::map to use a
>>> flavor of std::pair using this idea, if only for the sake of having
>>> such a std::pair that is implicitly compatible with the generic
>>> version.)
>> See above :-)
> Without this proposal (but still requiring expression aliases), you
> could write:
>
> // within map<KeyType, ValueType>
> struct node : pair<KeyType, ValueType>
> {
> using constexpr key = first;
> using constexpr value = second;
> };
>
>
> However, being able to express the map's node type like:
>
> // within map<KeyType, ValueType>
> using node = named_pair<KeyType, ValueType, `key`, `value`>
>
> ...would be a good use case for your feature, both to ensure that it
> works, and to avoid a completely local structure in std::map.
>
It would be a nice use case if we had expression aliases, too :-)
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Thu, 26 Mar 2015 11:16:20 -0400
Raw View
On 2015-03-26 02:28, Roland Bock wrote:
> On 2015-03-25 22:13, Matthew Woehlke wrote:
>> it *must* (for compatibility) implicitly convert to a std::pair
>> with the default names.
>
> Rules for implicit conversion tend to take me by surprise, so I am
> probably missing something, but wouldn't it be sufficient if named_pair
> had conversion operators in both directions?
>
> template<typename T1, typename T2, name N1, name N2>
> struct named_pair
> {
> T1 N1;
> T2 N2;
>
> named_pair(const pair<T1,T2>&);
> named_pair(pair<T1,T2>&&);
>
> operator pair<T1, T2>&()
> {
> return reinterpret_cast<pair<T1,T2>&>(*this);
> }
> operator const pair<T1, T2>&() const;
> };
Hmm... yes, I wasn't thinking of a conversion-to-reference that did a
reinterpret_cast. To me that's rather ugly, though :-). However, you
still need to have both the specific and default names, at least for a
flavor that std::map would use. (Maybe this is an argument for std::map
to *not* use the feature, so that the explicitly named version has
*only* the specified names. On the plus side, this means it doesn't need
expression aliases. On the down side, it means you can't compatibly
replace an existing pair with a named_pair.)
>> However, being able to express the map's node type like:
>>
>> // within map<KeyType, ValueType>
>> using node = named_pair<KeyType, ValueType, `key`, `value`>
>>
>> ...would be a good use case for your feature, both to ensure that it
>> works, and to avoid a completely local structure in std::map.
>>
> It would be a nice use case if we had expression aliases, too :-)
True enough :-).
Hmm, I wonder if anyone has thought before about starting a wiki of
features people have requested. It would be a good place to keep track
of things that have come up before, and what general reaction they got.
(I think the reaction to expression aliases has been neutral to
positive, but I'm also thinking about things like properties and
especially explicit non-initialization that have been shot down *hard*
before, but keep coming back anyway.) Bonus points for tracking pending
proposals...
--
Matthew
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Thu, 26 Mar 2015 16:54:30 +0100
Raw View
On 2015-03-26 16:16, Matthew Woehlke wrote:
> On 2015-03-26 02:28, Roland Bock wrote:
>> On 2015-03-25 22:13, Matthew Woehlke wrote:
>>> it *must* (for compatibility) implicitly convert to a std::pair
>>> with the default names.
>> Rules for implicit conversion tend to take me by surprise, so I am
>> probably missing something, but wouldn't it be sufficient if named_pair
>> had conversion operators in both directions?
>>
>> template<typename T1, typename T2, name N1, name N2>
>> struct named_pair
>> {
>> T1 N1;
>> T2 N2;
>>
>> named_pair(const pair<T1,T2>&);
>> named_pair(pair<T1,T2>&&);
>>
>> operator pair<T1, T2>&()
>> {
>> return reinterpret_cast<pair<T1,T2>&>(*this);
>> }
>> operator const pair<T1, T2>&() const;
>> };
> Hmm... yes, I wasn't thinking of a conversion-to-reference that did a
> reinterpret_cast. To me that's rather ugly, though :-).
reinterpret_cast was your idea ;-)
And yes, it would be code that would be marked as
"don't try this at home, kids!"
> However, you
> still need to have both the specific and default names, at least for a
> flavor that std::map would use. (Maybe this is an argument for std::map
> to *not* use the feature, so that the explicitly named version has
> *only* the specified names. On the plus side, this means it doesn't need
> expression aliases. On the down side, it means you can't compatibly
> replace an existing pair with a named_pair.)
Hmm. I thought that named pair would be using expression aliases to
allow access to each element via both names:
template<typename T1, typename T2,
name N1 = `first`, name N2 = `second`>
struct named_pair
{
T1 first|N1; // This member would be named both first/N1
T2 second|N2; // duplicates are to be ignored
//...
};
Thus, if N1 == `first`, then that member would just be called first. If
N1 == `key`, then you could use both `first` and `key` to address the
first member.
If we had expression aliases, that is, of course :-)
>
>>> However, being able to express the map's node type like:
>>>
>>> // within map<KeyType, ValueType>
>>> using node = named_pair<KeyType, ValueType, `key`, `value`>
>>>
>>> ...would be a good use case for your feature, both to ensure that it
>>> works, and to avoid a completely local structure in std::map.
>>>
>> It would be a nice use case if we had expression aliases, too :-)
> True enough :-).
>
> Hmm, I wonder if anyone has thought before about starting a wiki of
> features people have requested. It would be a good place to keep track
> of things that have come up before, and what general reaction they got.
> (I think the reaction to expression aliases has been neutral to
> positive, but I'm also thinking about things like properties and
> especially explicit non-initialization that have been shot down *hard*
> before, but keep coming back anyway.) Bonus points for tracking pending
> proposals...
>
That is a wonderful idea. It would also make for lovely talks at
conferences: "An overview of pending proposals", "CRRSP: Curiously
recurring and rejected standard proposals", ...
I would vote for wiki and talks without hesitation.
Cheers,
Roland
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Thu, 26 Mar 2015 12:25:13 -0400
Raw View
On 2015-03-26 11:54, Roland Bock wrote:
> On 2015-03-26 16:16, Matthew Woehlke wrote:
>> On 2015-03-26 02:28, Roland Bock wrote:
>>> On 2015-03-25 22:13, Matthew Woehlke wrote:
>>>> it *must* (for compatibility) implicitly convert to a std::pair
>>>> with the default names.
>>> Rules for implicit conversion tend to take me by surprise, so I am
>>> probably missing something, but wouldn't it be sufficient if named_pair
>>> had conversion operators in both directions?
>>>
>>> template<typename T1, typename T2, name N1, name N2>
>>> struct named_pair
>>> {
>>> T1 N1;
>>> T2 N2;
>>> =20
>>> named_pair(const pair<T1,T2>&);
>>> named_pair(pair<T1,T2>&&);
>>>
>>> operator pair<T1, T2>&()
>>> {
>>> return reinterpret_cast<pair<T1,T2>&>(*this);
>>> }
>>> operator const pair<T1, T2>&() const;
>>> };
>> Hmm... yes, I wasn't thinking of a conversion-to-reference that did a
>> reinterpret_cast. To me that's rather ugly, though :-).
> reinterpret_cast was your idea ;-)
>=20
> And yes, it would be code that would be marked as
> "don't try this at home, kids!"
Heh... touch=C3=A9 :-). That *was* rather for the case of coercing one
named_pair into an "unrelated" one with the same structure, but I
suppose you can argue this qualifies :-).
> Hmm. I thought that named pair would be using expression aliases to
> allow access to each element via both names:
>=20
> template<typename T1, typename T2,
> name N1 =3D `first`, name N2 =3D `second`>
> struct named_pair
> {
> T1 first|N1; // This member would be named both first/N1
> T2 second|N2; // duplicates are to be ignored
> //...
> };
>=20
> Thus, if N1 =3D=3D `first`, then that member would just be called first. =
If
> N1 =3D=3D `key`, then you could use both `first` and `key` to address the
> first member.
The problem with that is that you need to specialize for the case where
the default names are used, or you'll have identifier collisions. That's
why I like the subclass approach; you can use the base class for the
case that you only care about the default names, and just require that
the subclass must provide different names for all templated names. And
you get the convenience that using the default names actually *is* just
the old, non-template-names version of the class, and the implicit
conversion to the same is free because it's just an upcast.
>> Hmm, I wonder if anyone has thought before about starting a wiki of
>> features people have requested [...] that have been shot down=20
>> *hard* before, but keep coming back anyway.
>
> "CRRSP: Curiously recurring and rejected standard proposals", ...
:-D
--=20
Matthew
--=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/.
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Thu, 26 Mar 2015 17:49:52 +0100
Raw View
On 2015-03-26 17:25, Matthew Woehlke wrote:
>>>> Rules for implicit conversion tend to take me by surprise, so I am
>>>> probably missing something, but wouldn't it be sufficient if named_pai=
r
>>>> had conversion operators in both directions?
>>>>
>>>> template<typename T1, typename T2, name N1, name N2>
>>>> struct named_pair
>>>> {
>>>> T1 N1;
>>>> T2 N2;
>>>> =20
>>>> named_pair(const pair<T1,T2>&);
>>>> named_pair(pair<T1,T2>&&);
>>>>
>>>> operator pair<T1, T2>&()
>>>> {
>>>> return reinterpret_cast<pair<T1,T2>&>(*this);
>>>> }
>>>> operator const pair<T1, T2>&() const;
>>>> };
>>> Hmm... yes, I wasn't thinking of a conversion-to-reference that did a
>>> reinterpret_cast. To me that's rather ugly, though :-).
>> reinterpret_cast was your idea ;-)
>>
>> And yes, it would be code that would be marked as
>> "don't try this at home, kids!"
> Heh... touch=C3=A9 :-). That *was* rather for the case of coercing one
> named_pair into an "unrelated" one with the same structure, but I
> suppose you can argue this qualifies :-).
:-)
>> Hmm. I thought that named pair would be using expression aliases to
>> allow access to each element via both names:
>>
>> template<typename T1, typename T2,
>> name N1 =3D `first`, name N2 =3D `second`>
>> struct named_pair
>> {
>> T1 first|N1; // This member would be named both first/N1
>> T2 second|N2; // duplicates are to be ignored
>> //...
>> };
>>
>> Thus, if N1 =3D=3D `first`, then that member would just be called first.=
If
>> N1 =3D=3D `key`, then you could use both `first` and `key` to address th=
e
>> first member.
> The problem with that is that you need to specialize for the case where
> the default names are used, or you'll have identifier collisions.
It depends on how expression aliases work. I would argue that it should
handle collisions gracefully. If you insist on calling something `first`
which already is called `first`, then that's ok. It does not have to
create a compiler error.
> That's
> why I like the subclass approach; you can use the base class for the
> case that you only care about the default names, and just require that
> the subclass must provide different names for all templated names. And
> you get the convenience that using the default names actually *is* just
> the old, non-template-names version of the class, and the implicit
> conversion to the same is free because it's just an upcast.
The only thing I could currently say against that is: I am not a big fan
of inheritance. That's why I would try to avoid it.
On the other hand, I am not a big fan of reinterpret_cast either...
>>> Hmm, I wonder if anyone has thought before about starting a wiki of
>>> features people have requested [...] that have been shot down=20
>>> *hard* before, but keep coming back anyway.
>> "CRRSP: Curiously recurring and rejected standard proposals", ...
> :-D
I was quite sincere, btw, it could be a lovely talk! I would very much
like to hear it.
Roland
--=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/.
.
Author: Dejan Milosavljevic <dmilos@gmail.com>
Date: Fri, 27 Mar 2015 16:23:32 -0700 (PDT)
Raw View
------=_Part_1059_1312248832.1427498612376
Content-Type: multipart/alternative;
boundary="----=_Part_1060_309064734.1427498612377"
------=_Part_1060_309064734.1427498612377
Content-Type: text/plain; charset=UTF-8
What about this model:
#define Foo(Type,Name) \
struct \
{ \
Type Name; \
}
typedef Foo(int,test1) First;
typedef Foo(float,test2) Second;
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1060_309064734.1427498612377
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><font face=3D"arial,sans-serif">What about this model=
:</font></div><div><font face=3D"courier new,monospace"><br></font></div><d=
iv><font face=3D"courier new,monospace">#define Foo(Type,Name) &=
nbsp; \<br> struct &nbs=
p; &=
nbsp; \<br> { &n=
bsp;  =
; \<br> Type Name; &nb=
sp; \<br> }</font></d=
iv><div><font face=3D"courier new,monospace"><br></font></div><div><font fa=
ce=3D"courier new,monospace">typedef Foo(int,test1) First;</font></div><div=
><font face=3D"courier new,monospace">typedef Foo(float,test2) Second;</fon=
t></div><p><font face=3D"Courier New"><br></font></p><div><font face=3D"Cou=
rier New"><br></font></div><div><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" 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 />
------=_Part_1060_309064734.1427498612377--
------=_Part_1059_1312248832.1427498612376--
.
Author: Dejan Milosavljevic <dmilos@gmail.com>
Date: Sat, 28 Mar 2015 02:08:06 -0700 (PDT)
Raw View
------=_Part_85_1028236921.1427533686024
Content-Type: multipart/alternative;
boundary="----=_Part_86_777023838.1427533686024"
------=_Part_86_777023838.1427533686024
Content-Type: text/plain; charset=UTF-8
Rp;and Bock >Do we (plan to) have aliases for members?
Thumbs up for that!!!
And member functions too.
Here is another syntax approach for that.
As consequence we have injection of alias in class.
struct A
{
int a_public;
protected:
int a_protected;
private:
int a_private;
};
struct B : A
{
using b_public = a_public; //!< OK: a_public is public
using b_protected = a_protected; //!< OK: a_protected is protected and
this b_protected remain protected
using b_private = a_private; //!< error: visibility rules
};
using B::x_public = B::a_public ; //!< OK: a_public is public
using B::x_protected = B::b_protected; //!< error: visibility rules
using B::x_private = B::b_private ; //!< error: visibility rules
using y = B::b_public; //!< error: scope change.
int main( int argc, char *argv[] )
{
B b;
b.x_protected; //!< error: it is protected even if declared in public scope
using my_map = std::map<int,int>;
my_map m;
// may_pair is injected in std::map<int,int>.
using my_map::my_pair = my_pair::my_map::value_type;
using my_map::my_pair::key = my_pair::my_map::value_type::first;
using my_map::my_pair::data = my_pair::my_map::value_type::second;
for( auto const& i : m )
{
i.data = 10;
std::cout << i.key;
}
return EXIT_SUCCESS;
}
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_86_777023838.1427533686024
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><br></div><div>Rp;and Bock >Do we (plan to) have a=
liases for members? </div><div>Thumbs up for that!!!</div><div><br></div><d=
iv>And member functions too.</div><div><br></div><div><br></div><div>Here i=
s another syntax approach for that.</div><div><div>As consequence we have&n=
bsp;injection of alias in class.</div></div><div><br></div><div><font face=
=3D"courier new,monospace">struct A<br>{<br> int a_public=
;<br>protected:<br> int a_protected;<br>private:<br> =
; int a_private;<br>};</font></div><div><font face=3D"courier n=
ew,monospace">struct B : A<br>{<br> using b_public &=
nbsp; =3D a_public; //!< OK: a_public is p=
ublic<br> using b_protected =3D a_protected; //!<=
; OK: a_protected is protected and this b_protected remain protected<b=
r> using b_private =3D a_private; =
//!< error: visibility rules<br>};</font></div><div><font face=3D=
"courier new,monospace">using B::x_public =3D B::a_=
public ; //!< OK: a_public is public</font></div=
><div><font face=3D"courier new,monospace">using B::x_protected =3D B=
::b_protected; //!< error: visibility rules<br>using B::x_pr=
ivate =3D B::b_private ; //!< error:=
visibility rules</font></div><div><font face=3D"Courier New"><br></font></=
div><div><font face=3D"courier new,monospace">using y =3D B::b_public; =
; //!< error: scope change.</font></div><div><font face=3D"Courier=
New"><br></font></div><div><font face=3D"courier new,monospace">int main( =
int argc, char *argv[] )<br> {</font></div><div> <font fac=
e=3D"Courier New">B b;</font></div><div><font face=3D"Courier New"> b.=
x_protected; //!< error: it is protected even if declared in public scop=
e</font><font face=3D"Courier New"></font></div><div><font face=3D"courier =
new,monospace"><br></font><font face=3D"courier new,monospace"> using=
my_map =3D std::map<int,int>;<br> my_map m;</font></div><div><=
font face=3D"Courier New"> // may_pair is injected in std::map<int=
,int>.</font></div><div><font face=3D"courier new,monospace"> usin=
g my_map::my_pair =3D my_pair::my_map::value_type;</font></div><div><font f=
ace=3D"courier new,monospace"> using my_map::my_pair::key =3D m=
y_pair::my_map::value_type::first;<br> using my_map::my_pair::data =
=3D my_pair::my_map::value_type::second;</font></div><div><font face=3D"cou=
rier new,monospace"> for( auto const& i : m )<br> {<br>&nbs=
p; i.data =3D 10;</font></div><div><font face=3D"co=
urier new,monospace"> std::cout <<=
i.key; <br> }</font></div><div><font face=3D"courier new,monosp=
ace"> return EXIT_SUCCESS;<br> }</font><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" 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 />
------=_Part_86_777023838.1427533686024--
------=_Part_85_1028236921.1427533686024--
.
Author: Dejan Milosavljevic <dmilos@gmail.com>
Date: Sat, 28 Mar 2015 02:10:54 -0700 (PDT)
Raw View
------=_Part_1635_1759722615.1427533854899
Content-Type: multipart/alternative;
boundary="----=_Part_1636_513203821.1427533854899"
------=_Part_1636_513203821.1427533854899
Content-Type: text/plain; charset=UTF-8
Roland Bock > Do we (plan to) have aliases for members?
Thumbs up for that!!!
And member functions too.
Here is another syntax approach for that.
As consequence we have injection of alias in class.
struct A
{
int a_public;
protected:
int a_protected;
private:
int a_private;
};
struct B : A
{
using b_public = a_public; //!< OK: a_public is public
using b_protected = a_protected; //!< OK: a_protected is protected and
this b_protected remain protected
using b_private = a_private; //!< error: visibility rules
};
using B::x_public = B::a_public ; //!< OK: a_public is public
using B::x_protected = B::b_protected; //!< error: visibility rules
using B::x_private = B::b_private ; //!< error: visibility rules
using y = B::b_public; //!< error: scope change.
int main( int argc, char *argv[] )
{
B b;
b.x_protected; //!< error: it is protected even if declared in public scope
using my_map = std::map<int,int>;
my_map m;
// may_pair is injected in std::map<int,int>.
using my_map::my_pair = my_pair::my_map::value_type;
using my_map::my_pair::key = my_pair::my_map::value_type::first;
using my_map::my_pair::data = my_pair::my_map::value_type::second;
for( auto const& i : m )
{
i.data = 10;
std::cout << i.key;
}
return EXIT_SUCCESS;
}
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1636_513203821.1427533854899
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Roland Bock > Do we (plan to) have aliases for mem=
bers? </div><div>Thumbs up for that!!!</div><div><br></div><div>And member =
functions too.</div><div><br></div><div><br></div><div>Here is another synt=
ax approach for that.</div><div><div>As consequence we have injection =
of alias in class.</div></div><div><br></div><div><font face=3D"courier new=
,monospace">struct A<br>{<br> int a_public;<br>protected:=
<br> int a_protected;<br>private:<br> i=
nt a_private;<br>};</font></div><div><font face=3D"courier new,monospace">s=
truct B : A<br>{<br> using b_public &nbs=
p; =3D a_public; //!< OK: a_public is public<br> =
using b_protected =3D a_protected; //!< OK: a_protect=
ed is protected and this b_protected remain protected<br> &=
nbsp; using b_private =3D a_private; //!< =
error: visibility rules<br>};</font></div><div><font face=3D"courier new,mo=
nospace">using B::x_public =3D B::a_public &nb=
sp; ; //!< OK: a_public is public</font></div><div><font fac=
e=3D"courier new,monospace">using B::x_protected =3D B::b_protected;&=
nbsp; //!< error: visibility rules<br>using B::x_private &nbs=
p; =3D B::b_private ; //!< error: visibility rul=
es</font></div><div><font face=3D"Courier New"><br></font></div><div><font =
face=3D"courier new,monospace">using y =3D B::b_public; //!<=
error: scope change.</font></div><div><font face=3D"Courier New"><br></fon=
t></div><div><font face=3D"courier new,monospace">int main( int argc, char =
*argv[] )<br> {</font></div><div> <font face=3D"Courier Ne=
w">B b;</font></div><div><font face=3D"Courier New"> b.x_protected; //=
!< error: it is protected even if declared in public scope</font><font f=
ace=3D"Courier New"></font></div><div><font face=3D"courier new,monospace">=
<br></font><font face=3D"courier new,monospace"> using my_map =3D std=
::map<int,int>;<br> my_map m;</font></div><div><font face=3D"Co=
urier New"> // may_pair is injected in std::map<int,int>.</font=
></div><div><font face=3D"courier new,monospace"> using my_map::my_pa=
ir =3D my_pair::my_map::value_type;</font></div><div><font face=3D"courier =
new,monospace"> using my_map::my_pair::key =3D my_pair::my_map:=
:value_type::<wbr>first;<br> using my_map::my_pair::data =3D my_pair:=
:my_map::value_type::<wbr>second;</font></div><div><font face=3D"courier ne=
w,monospace"> for( auto const& i : m )<br> {<br>  =
; i.data =3D 10;</font></div><div><font face=3D"courier n=
ew,monospace"> std::cout << i.key;=
<br> }</font></div><div><font face=3D"courier new,monospace">&n=
bsp; return EXIT_SUCCESS;<br> }</font><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" 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 />
------=_Part_1636_513203821.1427533854899--
------=_Part_1635_1759722615.1427533854899--
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Sat, 28 Mar 2015 10:40:25 +0100
Raw View
This is a multi-part message in MIME format.
--------------090803040606070200050504
Content-Type: text/plain; charset=UTF-8
On 2015-03-28 00:23, Dejan Milosavljevic wrote:
> What about this model:
>
> #define Foo(Type,Name) \
> struct \
> { \
> Type Name; \
> }
>
> typedef Foo(int,test1) First;
> typedef Foo(float,test2) Second;
>
For which aspect of the discussion would you use that?
To give you a (simplified) example of one of the use cases I have in
mind for names:
template<typename... Columns>
auto select(Columns&&... cs)
{
return result_row<
result_field<typename Column::type, Column::name>...>
{cs...}
}
result_field then is a struct with members of appropriate types and names.
This cannot be done with the macro you're suggesting, because
a) the names depend on the argument types
b) the parameter pack is expanded after the preprocessor has done its work.
Best,
Roland
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
--------------090803040606070200050504
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">On 2015-03-28 00:23, Dejan
Milosavljevic wrote:<br>
</div>
<blockquote
cite=3D"mid:076c1a89-69f9-4130-bc26-97c49d8a2c67@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div><font face=3D"arial,sans-serif">What about this model:</font><=
/div>
<div><font face=3D"courier new,monospace"><br>
</font></div>
<div><font face=3D"courier new,monospace">#define
Foo(Type,Name)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \<br>
=C2=A0struct=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \<br>
=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 \<br>
=C2=A0=C2=A0=C2=A0 Type Name;=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 \<br>
=C2=A0 }</font></div>
<div><font face=3D"courier new,monospace"><br>
</font></div>
<div><font face=3D"courier new,monospace">typedef Foo(int,test1)
First;</font></div>
<div><font face=3D"courier new,monospace">typedef Foo(float,test2)
Second;</font></div>
<br>
</div>
</blockquote>
<font face=3D"Courier New">For which aspect of the discussion would
you use that?<br>
<br>
To give you a (simplified) example of one of the use cases I have
in mind for names:<br>
<br>
</font><tt>template<typename</tt><tt>... Columns></tt><tt><br>
</tt><tt>auto select(Columns&&... cs)</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 return resu</tt><tt>lt_row<</tt><tt><br>
</tt><tt>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 r=
esult_field<typename Column::type,
Column::name</tt><tt>></tt><tt>...><br>
</tt><tt>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </tt><tt>{cs...}</tt><tt>=
<br>
</tt><tt>}</tt><font face=3D"Courier New"><br>
<br>
result_field then is a struct with members of appropriate types
and names.<br>
<br>
This cannot be done with the macro you're suggesting, because <br>
<br>
a) the names depend on the argument types<br>
b) the parameter pack is expanded after the preprocessor has done
its work.<br>
<br>
Best,<br>
<br>
Roland<br>
</font>
</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" 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 />
--------------090803040606070200050504--
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Sat, 28 Mar 2015 10:50:37 +0100
Raw View
This is a multi-part message in MIME format.
--------------000104020607060209030105
Content-Type: text/plain; charset=UTF-8
On 2015-03-28 10:08, Dejan Milosavljevic wrote:
>
> Rp;and Bock >Do we (plan to) have aliases for members?
> Thumbs up for that!!!
>
> And member functions too.
It would be a nice use case for names, indeed :-)
>
>
> Here is another syntax approach for that.
> As consequence we have injection of alias in class.
>
> struct A
> {
> int a_public;
> protected:
> int a_protected;
> private:
> int a_private;
> };
> struct B : A
> {
> using b_public = a_public; //!< OK: a_public is public
> using b_protected = a_protected; //!< OK: a_protected is
> protected and this b_protected remain protected
> using b_private = a_private; //!< error: visibility rules
> };
> using B::x_public = B::a_public ; //!< OK: a_public is public
> using B::x_protected = B::b_protected; //!< error: visibility rules
> using B::x_private = B::b_private ; //!< error: visibility rules
>
> using y = B::b_public; //!< error: scope change.
>
> int main( int argc, char *argv[] )
> {
> B b;
> b.x_protected; //!< error: it is protected even if declared in public
> scope
>
> using my_map = std::map<int,int>;
> my_map m;
> // may_pair is injected in std::map<int,int>.
> using my_map::my_pair = my_pair::my_map::value_type;
> using my_map::my_pair::key = my_pair::my_map::value_type::first;
> using my_map::my_pair::data = my_pair::my_map::value_type::second;
> for( auto const& i : m )
> {
> i.data = 10;
> std::cout << i.key;
> }
> return EXIT_SUCCESS;
> }
IF we had expression aliases, then something like this would certainly
work. The question would then be: How could map use this feature so that
a) you could use key/data or key/value in new code, while old code still
works
b) you do not have to declare those aliases for every loop you write
Regards,
Roland
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
--------------000104020607060209030105
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">On 2015-03-28 10:08, Dejan
Milosavljevic wrote:<br>
</div>
<blockquote
cite=3D"mid:941cf948-3d42-4bf0-8887-b3f5db8e5e69@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div><br>
</div>
<div>Rp;and Bock >Do we (plan to) have aliases for members? </di=
v>
<div>Thumbs up for that!!!</div>
<div><br>
</div>
<div>And member functions too.</div>
</div>
</blockquote>
<br>
It would be a nice use case for names, indeed :-)<br>
<br>
<blockquote
cite=3D"mid:941cf948-3d42-4bf0-8887-b3f5db8e5e69@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div><br>
</div>
<div><br>
</div>
<div>Here is another syntax approach for that.</div>
<div>
<div>As consequence we have=C2=A0injection of alias in class.</di=
v>
</div>
<div><br>
</div>
<div><font face=3D"courier new,monospace">struct A<br>
{<br>
=C2=A0=C2=A0=C2=A0 int a_public;<br>
protected:<br>
=C2=A0=C2=A0=C2=A0 int a_protected;<br>
private:<br>
=C2=A0=C2=A0=C2=A0 int a_private;<br>
};</font></div>
<div><font face=3D"courier new,monospace">struct B : A<br>
{<br>
=C2=A0=C2=A0=C2=A0 using b_public=C2=A0=C2=A0=C2=A0=C2=A0 =3D a=
_public;=C2=A0=C2=A0=C2=A0 //!< OK: a_public
is public<br>
=C2=A0=C2=A0=C2=A0 using b_protected=C2=A0 =3D a_protected; //!=
< OK:
a_protected is protected=C2=A0and this b_protected remain
protected<br>
=C2=A0=C2=A0=C2=A0 using b_private=C2=A0=C2=A0=C2=A0 =3D a_priv=
ate;=C2=A0=C2=A0 //!< error:
visibility rules<br>
};</font></div>
<div><font face=3D"courier new,monospace">using B::x_public=C2=A0=
=C2=A0=C2=A0=C2=A0 =3D
B::a_public=C2=A0=C2=A0 ;=C2=A0=C2=A0 //!< OK: a_public is p=
ublic</font></div>
<div><font face=3D"courier new,monospace">using B::x_protected=C2=
=A0 =3D
B::b_protected;=C2=A0=C2=A0 //!< error: visibility rules<br>
using B::x_private=C2=A0=C2=A0=C2=A0 =3D B::b_private=C2=A0 ;=
=C2=A0=C2=A0 //!< error:
visibility rules</font></div>
<div><font face=3D"Courier New"><br>
</font></div>
<div><font face=3D"courier new,monospace">using y =3D B::b_public;=
=C2=A0=C2=A0
//!< error: scope change.</font></div>
<div><font face=3D"Courier New"><br>
</font></div>
<div><font face=3D"courier new,monospace">int main( int argc, char
*argv[] )<br>
=C2=A0{</font></div>
<div>=C2=A0=C2=A0 <font face=3D"Courier New">B b;</font></div>
<div><font face=3D"Courier New">=C2=A0b.x_protected; //!< error:=
it
is protected even if declared in public scope</font></div>
<div><font face=3D"courier new,monospace"><br>
</font><font face=3D"courier new,monospace">=C2=A0 using my_map =
=3D
std::map<int,int>;<br>
=C2=A0 my_map m;</font></div>
<div><font face=3D"Courier New">=C2=A0 // may_pair is injected in
std::map<int,int>.</font></div>
<div><font face=3D"courier new,monospace">=C2=A0 using my_map::my_p=
air
=3D my_pair::my_map::value_type;</font></div>
<div><font face=3D"courier new,monospace">=C2=A0 using
my_map::my_pair::key=C2=A0 =3D my_pair::my_map::value_type::fir=
st;<br>
=C2=A0 using my_map::my_pair::data =3D
my_pair::my_map::value_type::second;</font></div>
<div><font face=3D"courier new,monospace">=C2=A0 for( auto const&am=
p; i
: m )<br>
=C2=A0 {<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 i.data =3D 10;</font></div>
<div><font face=3D"courier new,monospace">=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0std::cout <<
i.key;=C2=A0<br>
=C2=A0 }</font></div>
<div><font face=3D"courier new,monospace">=C2=A0 return EXIT_SUCCES=
S;<br>
=C2=A0}</font><br>
</div>
</div>
</blockquote>
<br>
IF we had expression aliases, then something like this would
certainly work. The question would then be: How could map use this
feature so that <br>
<br>
a) you could use key/data or key/value in new code, while old code
still works<br>
b) you do not have to declare those aliases for every loop you write<br=
>
<br>
Regards,<br>
<br>
Roland<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" 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 />
--------------000104020607060209030105--
.
Author: Dejan Milosavljevic <dmilos@gmail.com>
Date: Sat, 28 Mar 2015 03:19:46 -0700 (PDT)
Raw View
------=_Part_1863_835713773.1427537986483
Content-Type: multipart/alternative;
boundary="----=_Part_1864_1298331431.1427537986483"
------=_Part_1864_1298331431.1427537986483
Content-Type: text/plain; charset=UTF-8
> This cannot be done with the macro you're suggesting, ...
Agree. Using macro is not elegant solution. That was idea on first thought.
> a) you could use key/data or key/value in new code, while old code still
works
Injection of member/expression alias to class.
> b) you do not have to declare those aliases for every loop you write
Unfortunately this is must. Access control and scope control will apply
anyway.
Question is how broad visibility we want.
Class A and B demonstrate wide visibility.
std::map<...> demonstrate loop-only visibility.
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1864_1298331431.1427537986483
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><font face=3D"arial,sans-serif">> This cannot be d=
one with the macro you're suggesting, ...</font></div><div><font face=3D"ar=
ial,sans-serif">Agree. Using macro is not elegant solution. That was idea o=
n first thought.</font></div><div><br></div><div><br></div><div>> a) you=
could use key/data or key/value in new code, while old code still works=
</div><div><br></div><div>Injection of member/expression alias to class. </=
div><div><br></div><p><font face=3D"arial,sans-serif">> b) you do not ha=
ve to declare those aliases for every loop you write</font></p><div><font f=
ace=3D"arial,sans-serif">Unfortunately this is must. Access control an=
d scope control will apply anyway.</font></div><div>Question is h=
ow broad visibility we want.</div><div>Class <font face=3D"courier new,mono=
space">A</font> and <font face=3D"courier new,monospace">B</font> demonstra=
te wide visibility.</div><div> <font face=3D"courier new,monospace">st=
d::map<...></font> demonstrate loop-only visibility.</div><div><br>
=20
</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" 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 />
------=_Part_1864_1298331431.1427537986483--
------=_Part_1863_835713773.1427537986483--
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Sat, 28 Mar 2015 13:05:52 +0100
Raw View
This is a multi-part message in MIME format.
--------------050305020000080403020205
Content-Type: text/plain; charset=UTF-8
On 2015-03-28 11:19, Dejan Milosavljevic wrote:
> > This cannot be done with the macro you're suggesting, ...
> Agree. Using macro is not elegant solution. That was idea on first
> thought.
>
>
> > a) you could use key/data or key/value in new code, while old code
> still works
>
> Injection of member/expression alias to class.
>
> > b) you do not have to declare those aliases for every loop you write
>
> Unfortunately this is must. Access control and scope control will
> apply anyway.
> Question is how broad visibility we want.
> Class A and B demonstrate wide visibility.
> std::map<...> demonstrate loop-only visibility.
With the sub-class approach (named_pair: public pair) suggested by
Matthew or the implicit conversion operators (named_pair<->pair)
suggested by me, these aliases could be introduced by the map already.
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
--------------050305020000080403020205
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">On 2015-03-28 11:19, Dejan
Milosavljevic wrote:<br>
</div>
<blockquote
cite=3D"mid:0bd501e6-a9e2-4e04-9c92-c5ce7f3e5ebf@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div><font face=3D"arial,sans-serif">> This cannot be done with
the macro you're suggesting, ...</font></div>
<div><font face=3D"arial,sans-serif">Agree. Using macro is not
elegant solution. That was idea on first thought.</font></div>
<div><br>
</div>
<div><br>
</div>
<div>> a) you could use key/data or key/value in new code,
while old code still works</div>
<div><br>
</div>
<div>Injection of member/expression alias to class. </div>
<div><br>
</div>
<p><font face=3D"arial,sans-serif">> b) you do not have to
declare those aliases for every loop you write</font></p>
<div><font face=3D"arial,sans-serif">Unfortunately this is
must.=C2=A0Access control and=C2=A0scope=C2=A0control will appl=
y anyway.</font></div>
<div>Question is how broad visibility we want.</div>
<div>Class <font face=3D"courier new,monospace">A</font> and <font
face=3D"courier new,monospace">B</font> demonstrate wide
visibility.</div>
<div>=C2=A0<font face=3D"courier new,monospace">std::map<...>=
</font>
demonstrate loop-only visibility.</div>
</div>
</blockquote>
<br>
With the sub-class approach (named_pair: public pair) suggested by
Matthew or the implicit conversion operators
(named_pair<->pair) suggested by me, these aliases could be
introduced by the map already.<br>
<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" 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 />
--------------050305020000080403020205--
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 29 Mar 2015 10:57:37 +0800
Raw View
--Apple-Mail=_43F8A87D-3253-4451-9659-DCD441669E88
Content-Type: text/plain; charset=UTF-8
There is an existing workaround, just for the sake of argument.
extern struct key_tag {} key;
extern struct value_tag {} value;
template< typename first_t, typename second_t >
first_t & operator ->* ( std::pair< first_t, second_t > & p, key_tag )
{ return p.first; }
template< typename first_t, typename second_t >
second_t & operator ->* ( std::pair< first_t, second_t > & p, value_tag )
{ return p.second; }
std::map< int, std::string > m { { 1, "hello" }, { 2, "world" } };
int k = (*m.begin())->*key;
std::string v = (*m.begin())->*value;
Add overloads for const.
I wonder, would it do any real harm to add drill-down behavior to operator->* to match operator->? It should use operator-> to drill down until either a pointer type LHS or an operator->* overload is found.
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
--Apple-Mail=_43F8A87D-3253-4451-9659-DCD441669E88
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dus-ascii"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode=
: space; -webkit-line-break: after-white-space;" class=3D"">There is an exi=
sting workaround, just for the sake of argument.<br class=3D""><div class=
=3D""><br class=3D""></div><div class=3D""><font face=3D"Courier" class=3D"=
">extern struct key_tag {} key;</font></div><div class=3D""><div class=3D""=
><font face=3D"Courier" class=3D"">extern struct value_tag {} value;</font>=
</div></div><div class=3D""><font face=3D"Courier" class=3D""><br class=3D"=
"></font></div><div class=3D""><font face=3D"Courier" class=3D"">template&l=
t; typename first_t, typename second_t ></font></div><div class=3D""><fo=
nt face=3D"Courier" class=3D"">first_t & operator ->* ( std::pair<=
; first_t, second_t > & p, key_tag )</font></div><div class=3D""><fo=
nt face=3D"Courier" class=3D""> { return p.first; }</font></div=
><div class=3D""><font face=3D"Courier" class=3D""><br class=3D""></font></=
div><div class=3D""><div class=3D""><font face=3D"Courier" class=3D"">templ=
ate< typename first_t, typename second_t ></font></div><div class=3D"=
"><font face=3D"Courier" class=3D"">second_t & operator ->* ( std::p=
air< first_t, second_t > & p, value_tag )</font></div><div class=
=3D""><font face=3D"Courier" class=3D""> { return p.second; }</=
font></div><div class=3D""><font face=3D"Courier" class=3D""><br class=3D""=
></font></div></div><div class=3D""><font face=3D"Courier" class=3D"">std::=
map< int, std::string > m { { 1, "hello" }, { 2, "world" } };</font><=
/div><div class=3D""><font face=3D"Courier" class=3D"">int k =3D (*m.begin(=
))->*key;</font></div><div class=3D""><div class=3D""><font face=3D"Cour=
ier" class=3D"">std::string v =3D (*m.begin())->*value;</font></div></di=
v><div class=3D""><br class=3D""></div><div class=3D"">Add overloads for <f=
ont face=3D"Courier" class=3D"">const</font>.</div><div class=3D""><br clas=
s=3D""></div><div class=3D"">I wonder, would it do any real harm to add dri=
ll-down behavior to <font face=3D"Courier" class=3D"">operator->*</font>=
to match <font face=3D"Courier" class=3D"">operator-></font>? It should=
use <font face=3D"Courier" class=3D"">operator-></font> to drill down u=
ntil either a pointer type LHS or an <font face=3D"Courier" class=3D"">oper=
ator->*</font> overload is found.</div></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" 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 />
--Apple-Mail=_43F8A87D-3253-4451-9659-DCD441669E88--
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Sun, 29 Mar 2015 12:52:54 +0200
Raw View
This is a multi-part message in MIME format.
--------------020104000509050002030507
Content-Type: text/plain; charset=UTF-8
On 2015-03-29 04:57, David Krauss wrote:
> There is an existing workaround, just for the sake of argument.
>
> extern struct key_tag {} key;
> extern struct value_tag {} value;
>
> template< typename first_t, typename second_t >
> first_t & operator ->* ( std::pair< first_t, second_t > & p, key_tag )
> { return p.first; }
>
> template< typename first_t, typename second_t >
> second_t & operator ->* ( std::pair< first_t, second_t > & p, value_tag )
> { return p.second; }
>
> std::map< int, std::string > m { { 1, "hello" }, { 2, "world" } };
> int k = (*m.begin())->*key;
> std::string v = (*m.begin())->*value;
>
> Add overloads for const.
Nice! Overloading pointer to member always takes me by surprise. This
reminds me of a proposal to overload operator.()...
Looks a bit weird though, when key/value are living in a separate namespace:
for (entry : m)
{
int k = entry->*project::key;
std::string v = entry->*project::value;
}
>
> I wonder, would it do any real harm to add drill-down behavior to
> operator->* to match operator->? It should use operator-> to drill
> down until either a pointer type LHS or an operator->* overload is found.
>
Can't think of any harm it might do, but I am certainly not the most
qualified person to reason about this ;-)
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
--------------020104000509050002030507
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">On 2015-03-29 04:57, David Krauss
wrote:<br>
</div>
<blockquote
cite=3D"mid:6C89B70F-AEBA-43FA-9F41-A3BEB0B8261A@gmail.com"
type=3D"cite">
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf=
-8">
There is an existing workaround, just for the sake of argument.<br
class=3D"">
<div class=3D""><br class=3D"">
</div>
<div class=3D""><font class=3D"" face=3D"Courier">extern struct key_t=
ag
{} key;</font></div>
<div class=3D"">
<div class=3D""><font class=3D"" face=3D"Courier">extern struct
value_tag {} value;</font></div>
</div>
<div class=3D""><font class=3D"" face=3D"Courier"><br class=3D"">
</font></div>
<div class=3D""><font class=3D"" face=3D"Courier">template< typena=
me
first_t, typename second_t ></font></div>
<div class=3D""><font class=3D"" face=3D"Courier">first_t & opera=
tor
->* ( std::pair< first_t, second_t > & p, key_tag
)</font></div>
<div class=3D""><font class=3D"" face=3D"Courier">=C2=A0 =C2=A0{ retu=
rn p.first; }</font></div>
<div class=3D""><font class=3D"" face=3D"Courier"><br class=3D"">
</font></div>
<div class=3D"">
<div class=3D""><font class=3D"" face=3D"Courier">template<
typename first_t, typename second_t ></font></div>
<div class=3D""><font class=3D"" face=3D"Courier">second_t &
operator ->* ( std::pair< first_t, second_t > &
p, value_tag )</font></div>
<div class=3D""><font class=3D"" face=3D"Courier">=C2=A0 =C2=A0{ re=
turn
p.second; }</font></div>
<div class=3D""><font class=3D"" face=3D"Courier"><br class=3D"">
</font></div>
</div>
<div class=3D""><font class=3D"" face=3D"Courier">std::map< int,
std::string > m { { 1, "hello" }, { 2, "world" } };</font></di=
v>
<div class=3D""><font class=3D"" face=3D"Courier">int k =3D
(*m.begin())->*key;</font></div>
<div class=3D"">
<div class=3D""><font class=3D"" face=3D"Courier">std::string v =3D
(*m.begin())->*value;</font></div>
</div>
<div class=3D""><br class=3D"">
</div>
<div class=3D"">Add overloads for <font class=3D"" face=3D"Courier">c=
onst</font>.</div>
</blockquote>
<br>
Nice! Overloading pointer to member always takes me by surprise.
This reminds me of a proposal to overload <tt>operator.()</tt>...<br>
<br>
Looks a bit weird though, when key/value are living in a separate
namespace:<br>
<br>
<tt>=C2=A0 for (entry : m)</tt><tt><br>
</tt><tt>=C2=A0 {</tt><tt><br>
</tt><tt>=C2=A0=C2=A0=C2=A0 int k =3D entry->*project::key;</tt><tt>=
<br>
</tt><tt>=C2=A0=C2=A0=C2=A0 std::string v =3D entry->*project::value=
;</tt><tt><br>
</tt><tt>=C2=A0 }</tt><tt><br>
</tt><br>
<br>
<blockquote
cite=3D"mid:6C89B70F-AEBA-43FA-9F41-A3BEB0B8261A@gmail.com"
type=3D"cite">
<div class=3D""><br class=3D"">
</div>
<div class=3D"">I wonder, would it do any real harm to add
drill-down behavior to <font class=3D"" face=3D"Courier">operator-&=
gt;*</font>
to match <font class=3D"" face=3D"Courier">operator-></font>? It
should use <font class=3D"" face=3D"Courier">operator-></font>
to drill down until either a pointer type LHS or an <font
class=3D"" face=3D"Courier">operator->*</font> overload is
found.</div>
<br>
</blockquote>
<br>
Can't think of any harm it might do, but I am certainly not the most
qualified person to reason about this ;-)<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" 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 />
--------------020104000509050002030507--
.
Author: gmisocpp@gmail.com
Date: Sun, 29 Mar 2015 14:06:01 -0700 (PDT)
Raw View
------=_Part_3501_1099383598.1427663162000
Content-Type: multipart/alternative;
boundary="----=_Part_3502_390832798.1427663162000"
------=_Part_3502_390832798.1427663162000
Content-Type: text/plain; charset=UTF-8
Way back at the start of this thread I suggested this syntax:
std::pair<string first_name, string last_name> name{"bob", "jones"};
printf("Hello %s %s\n", name.first_name.c_str(), name.second_name.c_str());
This syntax provides a local alias that gets replaced with whatever names
the template actually uses.
The idea didn't seem to get much traction but it seems to be a simple
solution at least for the example problem I provided with it, to avoid
first and second.
Does it not solve that problem and what the OP wanted too? What's the
problem with it?
To elaborate: In my example, the problem is that first and second create
unreadable code. 90% of the time when I see pair, I can and do replace it
with a simple struct. I sometimes can do that with tuple too, but I do risk
introducing incompatibility when I do this.
But if we could provide the alias syntax I suggest, the code would expands
to exactly the original pair code. Pair continues to use the names it wants
to use and I could continue using pair and not introduce new
types and allow quick refactoring with no risk of breakage. (I think.)
One potential issue I see is that the underlying type (pair in this case)
could later introduce new names matching any aliases given. i.e. in the
example, imagine the issues If pair introduce a real first_name and
last_name later. If this happens, the new real first_name and
last_name names are inaccessible because the aliases would hide the new
fields by mapping to the original first and last fields not the new ones.
Existing code would still work which is good, but the situation wouldn't be
tenable going forward as the reader wouldn't be easily sure without
checking what intent the was and so the code would appear a little
ambiguous but the real problem would be the new code might want the
access the hidden fields. But if the compiler would emit a warning it
would encourage people to fix those issues as they arrive so code clarity
is maintained. But this only happens in the assumedly rare event of a clash
and a compatible fix is always possible i.e. go back to referring to the
original names if you need them and refer to the new names if that's what
you need. Hopefully people cam following this, but I think it makes sense.
People may have other suggestions for tweaking the concept here. But what's
wrong with the basic idea?
If this is useful, but not solving the OP's problem, I can start this idea
in a new thread. But it appears to solve the OP's problem to my mind and at
least the real example of a problem I gave. I am trying to follow the OP's
solution path and that seems more complicated but it may solve their
problem better and other different ones. I'm not sure if it solves this
example?
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_3502_390832798.1427663162000
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><br></div><div>Way back at the start of this thr=
ead I suggested this syntax:</div><div><br></div><div>std::pair<string f=
irst_name, string last_name> name{"bob", "jones"};</div><div>printf("Hel=
lo %s %s\n", name.first_name.c_str(), name.second_name.c_str());</div><div>=
<br></div><div>This syntax provides a local alias that gets replaced with w=
hatever names the template actually uses.</div><div>The idea didn't se=
em to get much traction but it seems to be a simple solution at least for t=
he example problem I provided with it, to avoid first and second.</div><div=
>Does it not solve that problem and what the OP wanted too? What's the=
problem with it?</div><div><br></div><div>To elaborate: In my&nb=
sp;example, the problem is that first and second create unreadable code. 90=
% of the time when I see pair, I can and do replace it with a simple struct=
.. I sometimes can do that with tuple too, but I do risk introducing incompa=
tibility when I do this.</div><div><br></div><div>But if we could provide&n=
bsp;the alias syntax I suggest, the code would expands to exactl=
y the original pair code. Pair continues to use the names it=
wants to use and I could continue using pair and not introd=
uce new types and allow quick refactoring with no risk of breakag=
e. (I think.)</div><div><br></div><div>One potential issue I see is that&nb=
sp;the underlying type (pair in this case) could later introduce new n=
ames matching any aliases given. i.e. in the example, i=
magine the issues If pair introduce a real first_name and last_name later. =
If this happens, the new real first_name and last_name names=
are inaccessible because the aliases would hide the new fields b=
y mapping to the original first and last fields not the new ones.</div><div=
><br></div><div>Existing code would still work which is good, but the =
situation wouldn't be tenable going forward as the reader wouldn't be =
easily sure without checking what intent the was and so the code would appe=
ar a little ambiguous but the real problem would be the new code =
might want the access the hidden fields. But if the compiler woul=
d emit a warning it would encourage people to fix those issu=
es as they arrive so code clarity is maintained. But this only happens in t=
he assumedly rare event of a clash and a compatible fix is always possible =
i.e. go back to referring to the original names if you need them and refer =
to the new names if that's what you need. Hopefully people cam followi=
ng this, but I think it makes sense.</div><div><br></div><div>People may ha=
ve other suggestions for tweaking the concept here. But what's wrong with t=
he basic idea?</div><div><br></div><div>If this is useful, but not solving =
the OP's problem, I can start this idea in a new thread. But it appears to =
solve the OP's problem to my mind and at least the real example of a proble=
m I gave. I am trying to follow the OP's solution path and that s=
eems more complicated but it may solve their problem better and other diffe=
rent ones. I'm not sure if it solves this example?</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" 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 />
------=_Part_3502_390832798.1427663162000--
------=_Part_3501_1099383598.1427663162000--
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Mon, 30 Mar 2015 08:20:45 +0200
Raw View
On 2015-03-29 23:06, gmisocpp@gmail.com wrote:
>
> Way back at the start of this thread I suggested this syntax:
>
> std::pair<string first_name, string last_name> name{"bob", "jones"};
> printf("Hello %s %s\n", name.first_name.c_str(),
> name.second_name.c_str());
>
> This syntax provides a local alias that gets replaced with whatever
> names the template actually uses.
> The idea didn't seem to get much traction but it seems to be a simple
> solution at least for the example problem I provided with it, to avoid
> first and second.
> Does it not solve that problem and what the OP wanted too? What's the
> problem with it?
Hi,
Here are some problems I see with the syntax you provided:
It seems like types and names in your syntax would have to come in pairs
if a name is specified at all. And it seems kind of obvious where to
apply the names in case of std::pair. But what if there were templates
like these:
template<typename A>
struct foo
{
A first;
A second;
};
auto x = foo<int hello>{7,8};
x.hello;// is that first or second or both?
template<typename A>
struct bar
{
const std::shared_ptr<A> first;
};
auto y = bar<int, hello>{};
y.hello; is that even available? decltype(first) != A
Or take a look at a tuple implementation of your choice and then try to
apply the type-name pairs to the tuple elements.
I therefore believe that we need to be able to specify types and names
independently.
Another question would be:
How do you transport names that you cannot specify in the way your
example suggests?
See for instance the CRTP example in my blog post.
http://cpp.eudoxos.de/dreaming-of-names/
The name is specified in the "mixin" and it is not used as a template
parameter.
Or try to create a named_tuple (see blog post) with your syntax,
including the comparison operators.
Regards,
Roland
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Mon, 30 Mar 2015 11:24:50 -0400
Raw View
On 2015-03-28 05:08, Dejan Milosavljevic wrote:
> Rp;and Bock >Do we (plan to) have aliases for members?
> Thumbs up for that!!!
>
> And member functions too.
You can "already" alias member functions using an inline trampoline. I
*think* expression aliases would allow a slightly less verbose syntax if
you can have a "member" of "unbound member function" type, although
these might still be ugly. (Not a bad idea to call these out in an
expression alias proposal.)
> struct A
> {
> int a_public;
> protected:
> int a_protected;
> private:
> int a_private;
> };
> struct B : A
> {
> using b_public = a_public; //!< OK: a_public is public
> using b_protected = a_protected; //!< OK: a_protected is protected and
> this b_protected remain protected
Er... you declared b_protected as public; I would expect it to be
public... (Fiddling with access protections, especially public-const,
protected-mutable, is one of the intended use cases of expression
aliases. Also, what you suggest is contrary to 'using a_protected;'.)
> using b_private = a_private; //!< error: visibility rules
> };
--
Matthew
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Mon, 30 Mar 2015 12:26:15 -0400
Raw View
On 2015-03-29 17:06, gmisocpp@gmail.com wrote:
> One potential issue I see is that the underlying type (pair in this case)
> could later introduce new names matching any aliases given. i.e. in the
> example, imagine the issues If pair introduce a real first_name and
> last_name later. If this happens, the new real first_name and
> last_name names are inaccessible because the aliases would hide the new
> fields by mapping to the original first and last fields not the new ones.
(Oh, look; another reason for the subclass approach :-).)
// as in your example, syntax bikeshed elided
auto p = named_pair<...>;
p.first_name; // really std::pair::first
p.std::pair::first_name;
No problem there :-). (I can still invent problematic scenarios, but
let's be realistic: this is *std::pair* we're talking about. The chances
of its layout changing are effectively nil.)
> People may have other suggestions for tweaking the concept here. But what's
> wrong with the basic idea?
Roland pointed out the obvious issue already, so I won't rehash (except
to say I agree with him that we "need" to be able to support use cases
other than the trivial one).
That said, as much as std::pair is an obvious use case, let's keep in
mind that what we're trying to address is ways to inject identifiers
into a template. Ideally that would not be restricted to member
variables, but to any identifier (certainly also member *functions*,
maybe even other things like enum values?).
--
Matthew
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Mon, 30 Mar 2015 21:16:51 +0200
Raw View
On 2015-03-30 18:26, Matthew Woehlke wrote:
> On 2015-03-29 17:06, gmisocpp@gmail.com wrote:
>> One potential issue I see is that the underlying type (pair in this case)
>> could later introduce new names matching any aliases given. i.e. in the
>> example, imagine the issues If pair introduce a real first_name and
>> last_name later. If this happens, the new real first_name and
>> last_name names are inaccessible because the aliases would hide the new
>> fields by mapping to the original first and last fields not the new ones.
> (Oh, look; another reason for the subclass approach :-).)
:-)
>
> That said, as much as std::pair is an obvious use case, let's keep in
> mind that what we're trying to address is ways to inject identifiers
> into a template. Ideally that would not be restricted to member
> variables, but to any identifier (certainly also member *functions*,
> maybe even other things like enum values?).
>
My thoughts exactly. Any identifier, really. Although I must admit that
I haven't come up with a compelling /simple/ use case for functions or
enum values or type names.
Maybe I can simplify examples from sqlpp11: WHERE and HAVING clauses,
for instance, are almost identical except for the names of data members
and functions.
I'd be interested in other use cases, of course.
Regards,
Roland
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Mon, 30 Mar 2015 16:45:30 -0400
Raw View
On 2015-03-30 15:16, Roland Bock wrote:
> On 2015-03-30 18:26, Matthew Woehlke wrote:
>> That said, as much as std::pair is an obvious use case, let's keep in
>> mind that what we're trying to address is ways to inject identifiers
>> into a template. Ideally that would not be restricted to member
>> variables, but to any identifier (certainly also member *functions*,
>> maybe even other things like enum values?).
>
> My thoughts exactly. Any identifier, really. Although I must admit that
> I haven't come up with a compelling /simple/ use case for functions or
> enum values or type names.
Likewise :-). I was going to say something along those lines, but after
a non-trivial time thinking about it, was unable to come up with any
practical example where giving e.g. the *name* of a function to be used
in the implementation of some method would be useful but giving the
function itself would not be possible.
So, naturally, the moment I started writing this reply, I came up with
something like:
// FUNC is an identifier template argument
void templateMethod()
{
if (...) FUNC(x);
else if (...) FUNC(x, y);
else FUNC(a, b);
}
That is, where the template wants to call several overloads of something
with the same name, where 'something' is not (necessarily) a functor.
(If the method in question were itself templated, such that the function
type is non known to the outer template, that would be another use case.)
Note: I don't think we should allow type names unless you can explain
how that would differ from what we already have :-).
--
Matthew
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Tue, 31 Mar 2015 09:09:21 +0200
Raw View
This is a multi-part message in MIME format.
--------------000307090005070608060608
Content-Type: text/plain; charset=UTF-8
On 2015-03-30 22:45, Matthew Woehlke wrote:
> On 2015-03-30 15:16, Roland Bock wrote:
>> On 2015-03-30 18:26, Matthew Woehlke wrote:
>>> That said, as much as std::pair is an obvious use case, let's keep in
>>> mind that what we're trying to address is ways to inject identifiers
>>> into a template. Ideally that would not be restricted to member
>>> variables, but to any identifier (certainly also member *functions*,
>>> maybe even other things like enum values?).
>> My thoughts exactly. Any identifier, really. Although I must admit that
>> I haven't come up with a compelling /simple/ use case for functions or
>> enum values or type names.
> Likewise :-). I was going to say something along those lines, but after
> a non-trivial time thinking about it, was unable to come up with any
> practical example where giving e.g. the *name* of a function to be used
> in the implementation of some method would be useful but giving the
> function itself would not be possible.
>
> So, naturally, the moment I started writing this reply, I came up with
> something like:
>
> // FUNC is an identifier template argument
> void templateMethod()
> {
> if (...) FUNC(x);
> else if (...) FUNC(x, y);
> else FUNC(a, b);
> }
>
> That is, where the template wants to call several overloads of something
> with the same name, where 'something' is not (necessarily) a functor.
> (If the method in question were itself templated, such that the function
> type is non known to the outer template, that would be another use case.)
Good thinking! I actually encountered the second example (template
function) not too long ago and ended up writing wrapper types, if I
recall correctly...
>
> Note: I don't think we should allow type names unless you can explain
> how that would differ from what we already have :-).
>
What we have is
struct foo
{
using bar= int;
struct baz {};
}
The names bar and baz are fixed here.
If we could inject identifiers, then why not allow something like this:
template<name X, name Y>
struct sample
{
using X = int;
struct Y {};
};
As mentioned above, I don't have a use case for this yet, but it would
seem like an unnecessary restriction to not allow it.
I would /not/ allow the following though:
template<name X>
struct X {};
As you wrote, we have the mechanisms for that already.
Regards,
Roland
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
--------------000307090005070608060608
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">On 2015-03-30 22:45, Matthew Woehlke
wrote:<br>
</div>
<blockquote cite=3D"mid:mfcclb$uas$1@ger.gmane.org" type=3D"cite">
<pre wrap=3D"">On 2015-03-30 15:16, Roland Bock wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">On 2015-03-30 18:26, Matthew Woehlke wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">That said, as much as std::pair is an obvious use =
case, let's keep in
mind that what we're trying to address is ways to inject identifiers
into a template. Ideally that would not be restricted to member
variables, but to any identifier (certainly also member *functions*,
maybe even other things like enum values?).
</pre>
</blockquote>
<pre wrap=3D"">
My thoughts exactly. Any identifier, really. Although I must admit that
I haven't come up with a compelling /simple/ use case for functions or
enum values or type names.
</pre>
</blockquote>
<pre wrap=3D"">
Likewise :-). I was going to say something along those lines, but after
a non-trivial time thinking about it, was unable to come up with any
practical example where giving e.g. the *name* of a function to be used
in the implementation of some method would be useful but giving the
function itself would not be possible.
So, naturally, the moment I started writing this reply, I came up with
something like:
// FUNC is an identifier template argument
void templateMethod()
{
if (...) FUNC(x);
else if (...) FUNC(x, y);
else FUNC(a, b);
}
That is, where the template wants to call several overloads of something
with the same name, where 'something' is not (necessarily) a functor.
(If the method in question were itself templated, such that the function
type is non known to the outer template, that would be another use case.)</=
pre>
</blockquote>
Good thinking! I actually encountered the second example (template
function) not too long ago and ended up writing wrapper types, if I
recall correctly...<br>
<br>
<blockquote cite=3D"mid:mfcclb$uas$1@ger.gmane.org" type=3D"cite">
<pre wrap=3D"">
Note: I don't think we should allow type names unless you can explain
how that would differ from what we already have :-).
</pre>
</blockquote>
What we have is <br>
<br>
<tt>struct foo</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 using </tt><tt>bar</tt><tt> =3D int;</tt><tt><br>
=C2=A0=C2=A0 <br>
=C2=A0=C2=A0 struct baz {};<br>
</tt><tt>}</tt><tt><br>
</tt><br>
The names bar and baz are fixed here.<br>
<br>
If we could inject identifiers, then why not allow something like
this:<br>
<br>
<tt>template<name X, name Y></tt><tt><br>
</tt><tt>struct sample</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 using X =3D int;<br>
<br>
=C2=A0=C2=A0 struct Y {};<br>
</tt><tt></tt><tt>};</tt><br>
<br>
As mentioned above, I don't have a use case for this yet, but it
would seem like an unnecessary restriction to not allow it.<br>
<br>
<br>
I would <i>not</i> allow the following though:<br>
<br>
<tt>template<name X></tt><tt><br>
</tt><tt>struct X {};</tt><br>
<br>
As you wrote, we have the mechanisms for that already.<br>
<br>
<br>
Regards,<br>
<br>
Roland<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" 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 />
--------------000307090005070608060608--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Tue, 31 Mar 2015 10:15:35 -0400
Raw View
On 2015-03-31 03:09, Roland Bock wrote:
> On 2015-03-30 22:45, Matthew Woehlke wrote:
>> Note: I don't think we should allow type names unless you can explain
>> how that would differ from what we already have :-).
>
> What we have is
>
> struct foo
> {
> using bar= int;
>
> struct baz {};
> }
>
> The names bar and baz are fixed here.
>
> If we could inject identifiers, then why not allow something like this:
>
> template<name X, name Y>
> struct sample
> {
> using X = int;
>
> struct Y {};
> };
Ah. Yes, that seems reasonable. I was thinking of something like:
template <name X> struct sample { X member; };
I think the appropriate clarification here is, a 'name' may be used to
*introduce a new typename*. It may *not* be used to name an existing
type (because that would be redundant with 'typename'). Possibly with an
exception to the latter if the typename was previously introduced by the
template.
> I would /not/ allow the following though:
>
> template<name X>
> struct X {};
>
> As you wrote, we have the mechanisms for that already.
Actually I *wasn't* thinking about that, but that... does indeed seem a
bit strange. And we can achieve the same thing with 'using' already, so
I agree, I don't think we *need* to allow that. (That said, I'd be okay
not expressly forbidding it, either, as it might actually be more
implementation effort to forbid :-).)
--
Matthew
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Tue, 31 Mar 2015 17:55:50 +0200
Raw View
On 2015-03-31 16:15, Matthew Woehlke wrote:
> On 2015-03-31 03:09, Roland Bock wrote:
>> On 2015-03-30 22:45, Matthew Woehlke wrote:
>>> Note: I don't think we should allow type names unless you can explain
>>> how that would differ from what we already have :-).
>> What we have is
>>
>> struct foo
>> {
>> using bar= int;
>>
>> struct baz {};
>> }
>>
>> The names bar and baz are fixed here.
>>
>> If we could inject identifiers, then why not allow something like this:
>>
>> template<name X, name Y>
>> struct sample
>> {
>> using X = int;
>>
>> struct Y {};
>> };
> Ah. Yes, that seems reasonable. I was thinking of something like:
>
> template <name X> struct sample { X member; };
>
> I think the appropriate clarification here is, a 'name' may be used to
> *introduce a new typename*. It may *not* be used to name an existing
> type (because that would be redundant with 'typename'). Possibly with an
> exception to the latter if the typename was previously introduced by the
> template.
Actually, not having any clue how the whole thing would be implemented
in a compiler, I would follow your statement below: If it is easier to
implement allowing this construct, then why not, even if it seems a bit
weird.
>> I would /not/ allow the following though:
>>
>> template<name X>
>> struct X {};
>>
>> As you wrote, we have the mechanisms for that already.
> Actually I *wasn't* thinking about that, but that... does indeed seem a
> bit strange. And we can achieve the same thing with 'using' already, so
> I agree, I don't think we *need* to allow that. (That said, I'd be okay
> not expressly forbidding it, either, as it might actually be more
> implementation effort to forbid :-).)
>
Agreed :-)
Cheers,
Roland
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Tue, 31 Mar 2015 12:16:47 -0400
Raw View
On 2015-03-31 11:55, Roland Bock wrote:
> On 2015-03-31 16:15, Matthew Woehlke wrote:
>> I was thinking of something like:
>>
>> template <name X> struct sample { X member; };
>>
>> I think the appropriate clarification here is, a 'name' may be used to
>> *introduce a new typename*. It may *not* be used to name an existing
>> type (because that would be redundant with 'typename'). Possibly with an
>> exception to the latter if the typename was previously introduced by the
>> template.
>
> Actually, not having any clue how the whole thing would be implemented
> in a compiler, I would follow your statement below: If it is easier to
> implement allowing this construct, then why not, even if it seems a bit
> weird.
Sure; I can agree with that, though in the same vein I would leave it
"implementation defined" and not require it to be supported.
Related: is the name required to be unqualified? In the original case
(naming a member), it would be, but in the other cases it could be
qualified (or even include template arguments). Possibly we don't want
to try to support that in the first pass, however.
--
Matthew
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Tue, 31 Mar 2015 19:03:45 +0200
Raw View
On 2015-03-31 18:16, Matthew Woehlke wrote:
> On 2015-03-31 11:55, Roland Bock wrote:
>> On 2015-03-31 16:15, Matthew Woehlke wrote:
>>> I was thinking of something like:
>>>
>>> template <name X> struct sample { X member; };
>>>
>>> I think the appropriate clarification here is, a 'name' may be used to
>>> *introduce a new typename*. It may *not* be used to name an existing
>>> type (because that would be redundant with 'typename'). Possibly with an
>>> exception to the latter if the typename was previously introduced by the
>>> template.
>> Actually, not having any clue how the whole thing would be implemented
>> in a compiler, I would follow your statement below: If it is easier to
>> implement allowing this construct, then why not, even if it seems a bit
>> weird.
> Sure; I can agree with that, though in the same vein I would leave it
> "implementation defined" and not require it to be supported.
>
> Related: is the name required to be unqualified? In the original case
> (naming a member), it would be, but in the other cases it could be
> qualified (or even include template arguments). Possibly we don't want
> to try to support that in the first pass, however.
>
Can you elaborate? What would be a qualified name?
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Tue, 31 Mar 2015 13:24:42 -0400
Raw View
On 2015-03-31 13:03, Roland Bock wrote:
> On 2015-03-31 18:16, Matthew Woehlke wrote:
>> Related: is the name required to be unqualified? In the original case
>> (naming a member), it would be, but in the other cases it could be
>> qualified (or even include template arguments). Possibly we don't want
>> to try to support that in the first pass, however.
>
> Can you elaborate? What would be a qualified name?
A::B, or even ::B. Consider the previous example of giving a function
name; it may be the case that you need to namespace-qualify the name.
(For obvious reasons, it is an error to give a qualified name if the use
of the name is to define a new identifier.)
--
Matthew
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Tue, 31 Mar 2015 21:05:50 +0200
Raw View
This is a multi-part message in MIME format.
--------------030307080602000907040008
Content-Type: text/plain; charset=UTF-8
On 2015-03-31 19:24, Matthew Woehlke wrote:
> On 2015-03-31 13:03, Roland Bock wrote:
>> On 2015-03-31 18:16, Matthew Woehlke wrote:
>>> Related: is the name required to be unqualified? In the original case
>>> (naming a member), it would be, but in the other cases it could be
>>> qualified (or even include template arguments). Possibly we don't want
>>> to try to support that in the first pass, however.
>> Can you elaborate? What would be a qualified name?
> A::B, or even ::B. Consider the previous example of giving a function
> name; it may be the case that you need to namespace-qualify the name.
> (For obvious reasons, it is an error to give a qualified name if the use
> of the name is to define a new identifier.)
>
>
Right.
So I would assume that this works:
template<name A, name B>
struct sample
{
using type = A::B;
};
auto x = typename sample<`std`, `string`>::type{};
But I guess we should /not/ aim for this:
template<name A>
struct sample
{
using type = A
};
auto x = typename sample<`std::string`>::type{};
We should probably leave that to somebody in X+3, where
X = (the year when names become standard)
;-)
Best,
Roland
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
--------------030307080602000907040008
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">On 2015-03-31 19:24, Matthew Woehlke
wrote:<br>
</div>
<blockquote cite=3D"mid:mfel8q$a90$1@ger.gmane.org" type=3D"cite">
<pre wrap=3D"">On 2015-03-31 13:03, Roland Bock wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">On 2015-03-31 18:16, Matthew Woehlke wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">Related: is the name required to be unqualified? I=
n the original case
(naming a member), it would be, but in the other cases it could be
qualified (or even include template arguments). Possibly we don't want
to try to support that in the first pass, however.
</pre>
</blockquote>
<pre wrap=3D"">
Can you elaborate? What would be a qualified name?
</pre>
</blockquote>
<pre wrap=3D"">
A::B, or even ::B. Consider the previous example of giving a function
name; it may be the case that you need to namespace-qualify the name.
(For obvious reasons, it is an error to give a qualified name if the use
of the name is to define a new identifier.)
</pre>
</blockquote>
Right.<br>
<br>
So I would assume that this works:<br>
<br>
<tt>template<name A, name B></tt><tt><br>
</tt><tt>struct sample</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 using type =3D A::B;</tt><tt><br>
</tt><tt>};</tt><tt><br>
</tt><tt>auto x =3D typename sample<`std`, `string`>::type{};</tt=
><tt><br>
</tt><br>
<br>
But I guess we should <i>not</i> aim for this: <br>
<br>
<tt>template<name A></tt><tt><br>
</tt><tt>struct sample</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 using type =3D A</tt><tt><br>
</tt><tt>};</tt><tt><br>
</tt><tt>auto x =3D typename sample<`std::string`>::type{};</tt><=
br>
<br>
We should probably leave that to somebody in X+3, where <br>
<br>
X =3D (the year when names become standard) <br>
<br>
;-)<br>
<br>
Best,<br>
<br>
Roland<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" 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 />
--------------030307080602000907040008--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 31 Mar 2015 12:15:13 -0700
Raw View
On Tuesday 31 March 2015 21:05:50 Roland Bock wrote:
> template<name A, name B>
Please note that this syntax will conflict with a concept of type "name".
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Tue, 31 Mar 2015 15:36:45 -0400
Raw View
On 2015-03-31 15:05, Roland Bock wrote:
> On 2015-03-31 19:24, Matthew Woehlke wrote:
>> On 2015-03-31 13:03, Roland Bock wrote:
>>> On 2015-03-31 18:16, Matthew Woehlke wrote:
>>>> Related: is the name required to be unqualified? In the original case
>>>> (naming a member), it would be, but in the other cases it could be
>>>> qualified (or even include template arguments). Possibly we don't want
>>>> to try to support that in the first pass, however.
>>> Can you elaborate? What would be a qualified name?
>> A::B, or even ::B. Consider the previous example of giving a function
>> name; it may be the case that you need to namespace-qualify the name.
>> (For obvious reasons, it is an error to give a qualified name if the use
>> of the name is to define a new identifier.)
>
> Right.
>
> So I would assume that this works:
>
> template<name A, name B>
> struct sample
> {
> using type = A::B;
> };
> auto x = typename sample<`std`, `string`>::type{};
I would hope that works, iff 'name' can be used anywhere 'typename' can
be used.
> But I guess we should /not/ aim for this:
>
> template<name A>
> struct sample
> {
> using type = A
> };
> auto x = typename sample<`std::string`>::type{};
I would disagree here, although I don't consider this a good example.
Rather, I would argue that this should work:
template <name Operator, typename Args...>
auto sample(Args... args) { return Operator(args); }
auto x = sample<my_sum>(3, 5); // I think we both agree this is okay
auto y = sample<std::max>(3, 5); // I think this should also be okay
auto z = sample<std::min>(data);
It seems unnecessarily restrictive if we're going to be serious about
supporting a 'name' in other than member declarations to prohibit
qualified names.
--
Matthew
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Tue, 31 Mar 2015 21:48:17 +0200
Raw View
On 2015-03-31 21:15, Thiago Macieira wrote:
> On Tuesday 31 March 2015 21:05:50 Roland Bock wrote:
>> template<name A, name B>
> Please note that this syntax will conflict with a concept of type "name".
I am aware of that, but I haven't found a better syntax yet and it
currently seems to work well in explaining the idea :-)
To avoid the conflict, either "name" becomes a keyword at least inside
the template parameter list (and cannot be used as a concept) or it has
to be declared in a different way.
Suggestions welcome :-)
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Tue, 31 Mar 2015 21:48:45 +0200
Raw View
On 2015-03-31 21:36, Matthew Woehlke wrote:
> On 2015-03-31 15:05, Roland Bock wrote:
>> On 2015-03-31 19:24, Matthew Woehlke wrote:
>>> On 2015-03-31 13:03, Roland Bock wrote:
>>>> On 2015-03-31 18:16, Matthew Woehlke wrote:
>>>>> Related: is the name required to be unqualified? In the original case
>>>>> (naming a member), it would be, but in the other cases it could be
>>>>> qualified (or even include template arguments). Possibly we don't want
>>>>> to try to support that in the first pass, however.
>>>> Can you elaborate? What would be a qualified name?
>>> A::B, or even ::B. Consider the previous example of giving a function
>>> name; it may be the case that you need to namespace-qualify the name.
>>> (For obvious reasons, it is an error to give a qualified name if the use
>>> of the name is to define a new identifier.)
>> Right.
>>
>> So I would assume that this works:
>>
>> template<name A, name B>
>> struct sample
>> {
>> using type = A::B;
>> };
>> auto x = typename sample<`std`, `string`>::type{};
> I would hope that works, iff 'name' can be used anywhere 'typename' can
> be used.
>
>> But I guess we should /not/ aim for this:
>>
>> template<name A>
>> struct sample
>> {
>> using type = A
>> };
>> auto x = typename sample<`std::string`>::type{};
> I would disagree here, although I don't consider this a good example.
> Rather, I would argue that this should work:
>
> template <name Operator, typename Args...>
> auto sample(Args... args) { return Operator(args); }
>
> auto x = sample<my_sum>(3, 5); // I think we both agree this is okay
> auto y = sample<std::max>(3, 5); // I think this should also be okay
> auto z = sample<std::min>(data);
>
> It seems unnecessarily restrictive if we're going to be serious about
> supporting a 'name' in other than member declarations to prohibit
> qualified names.
>
I should probably call it a night and stop writing mails when tired...
You are right, of course, your example is quite convincing.
Interesting that you don't use forward ticks or other markers to
indicate a name. How would you write names outside of template parameter
lists? E.g.
struct sample
{
using my_name = `sample`;
};
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Alex B <devalexb@gmail.com>
Date: Tue, 31 Mar 2015 12:58:08 -0700 (PDT)
Raw View
------=_Part_3124_966818384.1427831888122
Content-Type: multipart/alternative;
boundary="----=_Part_3125_1455306686.1427831888122"
------=_Part_3125_1455306686.1427831888122
Content-Type: text/plain; charset=UTF-8
I'm not sure if the idea floated around, but why not use some kind of
compile time string instead of backticks or the *name* keyword?
template <typename T, __CompileTimeString s>
struct X
{
T __name(s);
};
X<int, "value"> var;
var.value = 0;
What __CompileTimeString precisely is would be to determine (are there any
proposals about compile-time strings in the reflection group?).
Operator *__name* (bikeshed) would convert a compile time string to an
actual name.
Combine this + compile time strings + other cool reflection features and we
get something really powerful.
On Tuesday, March 31, 2015 at 3:48:48 PM UTC-4, Roland Bock wrote:
> On 2015-03-31 21:36, Matthew Woehlke wrote:
> > On 2015-03-31 15:05, Roland Bock wrote:
> >> On 2015-03-31 19:24, Matthew Woehlke wrote:
> >>> On 2015-03-31 13:03, Roland Bock wrote:
> >>>> On 2015-03-31 18:16, Matthew Woehlke wrote:
> >>>>> Related: is the name required to be unqualified? In the original
> case
> >>>>> (naming a member), it would be, but in the other cases it could be
> >>>>> qualified (or even include template arguments). Possibly we don't
> want
> >>>>> to try to support that in the first pass, however.
> >>>> Can you elaborate? What would be a qualified name?
> >>> A::B, or even ::B. Consider the previous example of giving a function
> >>> name; it may be the case that you need to namespace-qualify the name.
> >>> (For obvious reasons, it is an error to give a qualified name if the
> use
> >>> of the name is to define a new identifier.)
> >> Right.
> >>
> >> So I would assume that this works:
> >>
> >> template<name A, name B>
> >> struct sample
> >> {
> >> using type = A::B;
> >> };
> >> auto x = typename sample<`std`, `string`>::type{};
> > I would hope that works, iff 'name' can be used anywhere 'typename' can
> > be used.
> >
> >> But I guess we should /not/ aim for this:
> >>
> >> template<name A>
> >> struct sample
> >> {
> >> using type = A
> >> };
> >> auto x = typename sample<`std::string`>::type{};
> > I would disagree here, although I don't consider this a good example.
> > Rather, I would argue that this should work:
> >
> > template <name Operator, typename Args...>
> > auto sample(Args... args) { return Operator(args); }
> >
> > auto x = sample<my_sum>(3, 5); // I think we both agree this is okay
> > auto y = sample<std::max>(3, 5); // I think this should also be okay
> > auto z = sample<std::min>(data);
> >
> > It seems unnecessarily restrictive if we're going to be serious about
> > supporting a 'name' in other than member declarations to prohibit
> > qualified names.
> >
> I should probably call it a night and stop writing mails when tired...
>
> You are right, of course, your example is quite convincing.
>
> Interesting that you don't use forward ticks or other markers to
> indicate a name. How would you write names outside of template parameter
> lists? E.g.
>
> struct sample
> {
> using my_name = `sample`;
> };
>
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_3125_1455306686.1427831888122
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I'm not sure if the idea floated around, but why not =
use some kind of compile time string instead of backticks or the <strong>na=
me</strong> keyword?</div><div> </div><div class=3D"prettyprint" style=
=3D"border: 1px solid rgb(187, 187, 187); -ms-word-wrap: break-word; backgr=
ound-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"=
subprettyprint"><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0=
, 136);">template</span><span class=3D"styled-by-prettify" style=3D"color: =
rgb(0, 0, 0);"> </span><span class=3D"styled-by-prettify" style=3D"color: r=
gb(102, 102, 0);"><</span><span class=3D"styled-by-prettify" style=3D"co=
lor: rgb(0, 0, 136);">typename</span><span class=3D"styled-by-prettify" sty=
le=3D"color: rgb(0, 0, 0);"> T</span><span class=3D"styled-by-prettify" sty=
le=3D"color: rgb(102, 102, 0);">,</span><span class=3D"styled-by-prettify" =
style=3D"color: rgb(0, 0, 0);"> __CompileTimeString s</span><span class=3D"=
styled-by-prettify" style=3D"color: rgb(102, 102, 0);">></span><span cla=
ss=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"><br></span><span c=
lass=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 136);">struct</span><=
span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> X<br></sp=
an><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">{<=
/span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"><br=
> T __name</span><span class=3D"styled-by-prettify" style=3D"co=
lor: rgb(102, 102, 0);">(</span><span class=3D"styled-by-prettify" style=3D=
"color: rgb(0, 0, 0);">s</span><span class=3D"styled-by-prettify" style=3D"=
color: rgb(102, 102, 0);">);</span><span class=3D"styled-by-prettify" style=
=3D"color: rgb(0, 0, 0);"><br></span><span class=3D"styled-by-prettify" sty=
le=3D"color: rgb(102, 102, 0);">};</span><span class=3D"styled-by-prettify"=
style=3D"color: rgb(0, 0, 0);"><br> <br>X</span><span class=3D"styled=
-by-prettify" style=3D"color: rgb(102, 102, 0);"><</span><span class=3D"=
styled-by-prettify" style=3D"color: rgb(0, 0, 136);">int</span><span class=
=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">,</span><span cl=
ass=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> </span><span cla=
ss=3D"styled-by-prettify" style=3D"color: rgb(0, 136, 0);">"value"</span><s=
pan class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">></s=
pan><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> </sp=
an><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 136);">var<=
/span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);"=
>;</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);">=
<br></span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 136=
);">var</span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 1=
02, 0);">.</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, =
0, 0);">value </span><span class=3D"styled-by-prettify" style=3D"color: rgb=
(102, 102, 0);">=3D</span><span class=3D"styled-by-prettify" style=3D"color=
: rgb(0, 0, 0);"> </span><span class=3D"styled-by-prettify" style=3D"color:=
rgb(0, 102, 102);">0</span><span class=3D"styled-by-prettify" style=3D"col=
or: rgb(102, 102, 0);">;</span></div></code></div><div><br></div><div> =
;</div><div> </div><div>What __CompileTimeString precisely is would be=
to determine (are there any proposals about compile-time strings in the re=
flection group?).</div><div>Operator <strong>__name</strong> (bikeshed) wou=
ld convert a compile time string to an actual name.</div><div> </div><=
div>Combine this + compile time strings + other cool reflection features an=
d we get something really powerful.</div><div><br>On Tuesday, March 31, 201=
5 at 3:48:48 PM UTC-4, Roland Bock wrote:</div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-co=
lor: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"=
>On 2015-03-31 21:36, Matthew Woehlke wrote:
<br>> On 2015-03-31 15:05, Roland Bock wrote:
<br>>> On 2015-03-31 19:24, Matthew Woehlke wrote:
<br>>>> On 2015-03-31 13:03, Roland Bock wrote:
<br>>>>> On 2015-03-31 18:16, Matthew Woehlke wrote:
<br>>>>>> Related: is the name required to be unqualified? I=
n the original case
<br>>>>>> (naming a member), it would be, but in the other c=
ases it could be
<br>>>>>> qualified (or even include template arguments). Po=
ssibly we don't want
<br>>>>>> to try to support that in the first pass, however.
<br>>>>> Can you elaborate? What would be a qualified name?
<br>>>> A::B, or even ::B. Consider the previous example of giving=
a function
<br>>>> name; it may be the case that you need to namespace-qualif=
y the name.
<br>>>> (For obvious reasons, it is an error to give a qualified n=
ame if the use
<br>>>> of the name is to define a new identifier.)
<br>>> Right.
<br>>>
<br>>> So I would assume that this works:
<br>>>
<br>>> template<name A, name B>
<br>>> struct sample
<br>>> {
<br>>> using type =3D A::B;
<br>>> };
<br>>> auto x =3D typename sample<`std`, `string`>::type{};
<br>> I would hope that works, iff 'name' can be used anywhere 'typename=
' can
<br>> be used.
<br>>
<br>>> But I guess we should /not/ aim for this:
<br>>>
<br>>> template<name A>
<br>>> struct sample
<br>>> {
<br>>> using type =3D A
<br>>> };
<br>>> auto x =3D typename sample<`std::string`>::type{};
<br>> I would disagree here, although I don't consider this a good examp=
le.
<br>> Rather, I would argue that this should work:
<br>>
<br>> template <name Operator, typename Args...>
<br>> auto sample(Args... args) { return Operator(args); }
<br>>
<br>> auto x =3D sample<my_sum>(3, 5); // I think we both a=
gree this is okay
<br>> auto y =3D sample<std::max>(3, 5); // I think this sh=
ould also be okay
<br>> auto z =3D sample<std::min>(data);
<br>>
<br>> It seems unnecessarily restrictive if we're going to be serious ab=
out
<br>> supporting a 'name' in other than member declarations to prohibit
<br>> qualified names.
<br>>
<br>I should probably call it a night and stop writing mails when tired...
<br>
<br>You are right, of course, your example is quite convincing.
<br>
<br>Interesting that you don't use forward ticks or other markers to
<br>indicate a name. How would you write names outside of template paramete=
r
<br>lists? E.g.
<br>
<br>struct sample
<br>{
<br> using my_name =3D `sample`;
<br>};
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
------=_Part_3125_1455306686.1427831888122--
------=_Part_3124_966818384.1427831888122--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Tue, 31 Mar 2015 16:14:29 -0400
Raw View
On 2015-03-31 15:48, Roland Bock wrote:
> Interesting that you don't use forward ticks or other markers to
> indicate a name.
That's *at least* part laziness :-)... and an opinion that the little
syntax bits aren't nailed down yet. Don't read too much into it :-).
> How would you write names outside of template parameter
> lists? E.g.
>
> struct sample
> {
> using my_name = `sample`;
> };
That's an interesting point, although I don't entirely follow the
example. How would you subsequently use 'my_name'? I guess as a template
parameter? (IOW, I guess you are proposing something a little like, but
not entirely the same as, a string literal?)
--
Matthew
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Tue, 31 Mar 2015 13:57:36 -0700
Raw View
--001a11c3086431e71505129bd9a6
Content-Type: text/plain; charset=UTF-8
On Tue, Mar 31, 2015 at 12:58 PM, Alex B <devalexb@gmail.com> wrote:
> I'm not sure if the idea floated around, but why not use some kind of
> compile time string instead of backticks or the *name* keyword?
>
> template <typename T, __CompileTimeString s>
> struct X
> {
> T __name(s);
> };
>
> X<int, "value"> var;
> var.value = 0;
>
>
>
> What __CompileTimeString precisely is would be to determine (are there any
> proposals about compile-time strings in the reflection group?).
> Operator *__name* (bikeshed) would convert a compile time string to an
> actual name.
>
> Combine this + compile time strings + other cool reflection features and
> we get something really powerful.
>
A name (or rather, an unqualified-id) is not a string. Consider, for
instance, the name 'operator int', which should presumably be the same name
as 'operator T' if T is a typedef for 'int'.
> On Tuesday, March 31, 2015 at 3:48:48 PM UTC-4, Roland Bock wrote:
>
>> On 2015-03-31 21:36, Matthew Woehlke wrote:
>> > On 2015-03-31 15:05, Roland Bock wrote:
>> >> On 2015-03-31 19:24, Matthew Woehlke wrote:
>> >>> On 2015-03-31 13:03, Roland Bock wrote:
>> >>>> On 2015-03-31 18:16, Matthew Woehlke wrote:
>> >>>>> Related: is the name required to be unqualified? In the original
>> case
>> >>>>> (naming a member), it would be, but in the other cases it could be
>> >>>>> qualified (or even include template arguments). Possibly we don't
>> want
>> >>>>> to try to support that in the first pass, however.
>> >>>> Can you elaborate? What would be a qualified name?
>> >>> A::B, or even ::B. Consider the previous example of giving a function
>> >>> name; it may be the case that you need to namespace-qualify the name.
>> >>> (For obvious reasons, it is an error to give a qualified name if the
>> use
>> >>> of the name is to define a new identifier.)
>> >> Right.
>> >>
>> >> So I would assume that this works:
>> >>
>> >> template<name A, name B>
>> >> struct sample
>> >> {
>> >> using type = A::B;
>> >> };
>> >> auto x = typename sample<`std`, `string`>::type{};
>> > I would hope that works, iff 'name' can be used anywhere 'typename' can
>> > be used.
>> >
>> >> But I guess we should /not/ aim for this:
>> >>
>> >> template<name A>
>> >> struct sample
>> >> {
>> >> using type = A
>> >> };
>> >> auto x = typename sample<`std::string`>::type{};
>> > I would disagree here, although I don't consider this a good example.
>> > Rather, I would argue that this should work:
>> >
>> > template <name Operator, typename Args...>
>> > auto sample(Args... args) { return Operator(args); }
>> >
>> > auto x = sample<my_sum>(3, 5); // I think we both agree this is okay
>> > auto y = sample<std::max>(3, 5); // I think this should also be okay
>> > auto z = sample<std::min>(data);
>> >
>> > It seems unnecessarily restrictive if we're going to be serious about
>> > supporting a 'name' in other than member declarations to prohibit
>> > qualified names.
>> >
>> I should probably call it a night and stop writing mails when tired...
>>
>> You are right, of course, your example is quite convincing.
>>
>> Interesting that you don't use forward ticks or other markers to
>> indicate a name. How would you write names outside of template parameter
>> lists? E.g.
>>
>> struct sample
>> {
>> using my_name = `sample`;
>> };
>>
> --
>
> ---
> 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
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c3086431e71505129bd9a6
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, Mar 31, 2015 at 12:58 PM, Alex B <span dir=3D"ltr"><<a href=3D"mailt=
o:devalexb@gmail.com" target=3D"_blank">devalexb@gmail.com</a>></span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>I'm not s=
ure if the idea floated around, but why not use some kind of compile time s=
tring instead of backticks or the <strong>name</strong> keyword?</div><div>=
=C2=A0</div><div style=3D"border:1px solid rgb(187,187,187);background-colo=
r:rgb(250,250,250)"><code><div><span style=3D"color:rgb(0,0,136)">template<=
/span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102=
,102,0)"><</span><span style=3D"color:rgb(0,0,136)">typename</span><span=
style=3D"color:rgb(0,0,0)"> T</span><span style=3D"color:rgb(102,102,0)">,=
</span><span style=3D"color:rgb(0,0,0)"> __CompileTimeString s</span><span =
style=3D"color:rgb(102,102,0)">></span><span style=3D"color:rgb(0,0,0)">=
<br></span><span style=3D"color:rgb(0,0,136)">struct</span><span style=3D"c=
olor:rgb(0,0,0)"> X<br></span><span style=3D"color:rgb(102,102,0)">{</span>=
<span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0T __name</span><span styl=
e=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,0)">s</span=
><span style=3D"color:rgb(102,102,0)">);</span><span style=3D"color:rgb(0,0=
,0)"><br></span><span style=3D"color:rgb(102,102,0)">};</span><span style=
=3D"color:rgb(0,0,0)"><br>=C2=A0<br>X</span><span style=3D"color:rgb(102,10=
2,0)"><</span><span style=3D"color:rgb(0,0,136)">int</span><span style=
=3D"color:rgb(102,102,0)">,</span><span style=3D"color:rgb(0,0,0)"> </span>=
<span style=3D"color:rgb(0,136,0)">"value"</span><span style=3D"c=
olor:rgb(102,102,0)">></span><span style=3D"color:rgb(0,0,0)"> </span><s=
pan style=3D"color:rgb(0,0,136)">var</span><span style=3D"color:rgb(102,102=
,0)">;</span><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"col=
or:rgb(0,0,136)">var</span><span style=3D"color:rgb(102,102,0)">.</span><sp=
an style=3D"color:rgb(0,0,0)">value </span><span style=3D"color:rgb(102,102=
,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"colo=
r:rgb(0,102,102)">0</span><span style=3D"color:rgb(102,102,0)">;</span></di=
v></code></div><div><br></div><div>=C2=A0</div><div>=C2=A0</div><div>What _=
_CompileTimeString precisely is would be to determine (are there any propos=
als about compile-time strings in the reflection group?).</div><div>Operato=
r <strong>__name</strong> (bikeshed) would convert a compile time string to=
an actual name.</div><div>=C2=A0</div><div>Combine this + compile time str=
ings + other cool reflection features and we get something really powerful.=
</div></div></blockquote><div><br></div><div>A name (or rather, an unqualif=
ied-id) is not a string. Consider, for instance, the name 'operator int=
', which should presumably be the same name as 'operator T' if =
T is a typedef for 'int'.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div><div class=3D"h5"><div>On Tuesday, Marc=
h 31, 2015 at 3:48:48 PM UTC-4, Roland Bock wrote:</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-=
left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">=
On 2015-03-31 21:36, Matthew Woehlke wrote:
<br>> On 2015-03-31 15:05, Roland Bock wrote:
<br>>> On 2015-03-31 19:24, Matthew Woehlke wrote:
<br>>>> On 2015-03-31 13:03, Roland Bock wrote:
<br>>>>> On 2015-03-31 18:16, Matthew Woehlke wrote:
<br>>>>>> Related: is the name required to be unqualified? I=
n the original case
<br>>>>>> (naming a member), it would be, but in the other c=
ases it could be
<br>>>>>> qualified (or even include template arguments). Po=
ssibly we don't want
<br>>>>>> to try to support that in the first pass, however.
<br>>>>> Can you elaborate? What would be a qualified name?
<br>>>> A::B, or even ::B. Consider the previous example of giving=
a function
<br>>>> name; it may be the case that you need to namespace-qualif=
y the name.
<br>>>> (For obvious reasons, it is an error to give a qualified n=
ame if the use
<br>>>> of the name is to define a new identifier.)
<br>>> Right.
<br>>>
<br>>> So I would assume that this works:
<br>>>
<br>>> template<name A, name B>
<br>>> struct sample
<br>>> {
<br>>> =C2=A0 =C2=A0using type =3D A::B;
<br>>> };
<br>>> auto x =3D typename sample<`std`, `string`>::type{};
<br>> I would hope that works, iff 'name' can be used anywhere &=
#39;typename' can
<br>> be used.
<br>>
<br>>> But I guess we should /not/ aim for this:
<br>>>
<br>>> template<name A>
<br>>> struct sample
<br>>> {
<br>>> =C2=A0 =C2=A0using type =3D A
<br>>> };
<br>>> auto x =3D typename sample<`std::string`>::type{};
<br>> I would disagree here, although I don't consider this a good e=
xample.
<br>> Rather, I would argue that this should work:
<br>>
<br>> =C2=A0 template <name Operator, typename Args...>
<br>> =C2=A0 auto sample(Args... args) { return Operator(args); }
<br>>
<br>> =C2=A0 auto x =3D sample<my_sum>(3, 5); // I think we both a=
gree this is okay
<br>> =C2=A0 auto y =3D sample<std::max>(3, 5); // I think this sh=
ould also be okay
<br>> =C2=A0 auto z =3D sample<std::min>(data);
<br>>
<br>> It seems unnecessarily restrictive if we're going to be seriou=
s about
<br>> supporting a 'name' in other than member declarations to p=
rohibit
<br>> qualified names.
<br>>
<br>I should probably call it a night and stop writing mails when tired...
<br>
<br>You are right, of course, your example is quite convincing.
<br>
<br>Interesting that you don't use forward ticks or other markers to
<br>indicate a name. How would you write names outside of template paramete=
r
<br>lists? E.g.
<br>
<br>struct sample
<br>{
<br>=C2=A0 =C2=A0using my_name =3D `sample`;
<br>};
<br></blockquote></div></div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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" target=3D"_=
blank">std-proposals+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></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--001a11c3086431e71505129bd9a6--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Tue, 31 Mar 2015 14:06:07 -0700
Raw View
--089e011619c4a1eca305129bf7b8
Content-Type: text/plain; charset=UTF-8
On Tue, Mar 31, 2015 at 12:15 PM, Thiago Macieira <thiago@macieira.org>
wrote:
> On Tuesday 31 March 2015 21:05:50 Roland Bock wrote:
> > template<name A, name B>
>
> Please note that this syntax will conflict with a concept of type "name".
>
It would also conflict with a type with name "name" (where A and B would be
non-type template parameters).
One could imagine solving this conflict by adding a standard-library type
std::name (or std::reflect::name, or whatever), with `...` being a literal
of that type. Following similar systems in other languages (Template
Haskell, lisp macros, ...), there should probably be an explicit
reification syntax ($foo, perhaps) to disambiguate between mention and
expansion. So:
namespace std { using name = decltype(`blah`); }
template<std::name A> struct X { // name is a normal identifier here
Y<A> ya; // pass name A to Y
Y<$A> yda; // look up the name represented by A, pass the result to Y
int k1 = ya.A; // look up member A in ya
int k2 = ya.$A; // look up the name represented by A
};
X<`foo`> xfoo;
If such a thing were formally proposed, it would seem prudent to consider
whether it can be extended naturally to capture other constructs (types,
expressions, statements).
--
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> 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
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e011619c4a1eca305129bf7b8
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, Mar 31, 2015 at 12:15 PM, Thiago Macieira <span dir=3D"ltr"><<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Tues=
day 31 March 2015 21:05:50 Roland Bock wrote:<br>
> template<name A, name B><br>
<br>
</span>Please note that this syntax will conflict with a concept of type &q=
uot;name".<br></blockquote><div><br></div><div>It would also conflict =
with a type with name "name" (where A and B would be non-type tem=
plate parameters).</div><div><br></div><div>One could imagine solving this =
conflict by adding a standard-library type std::name (or std::reflect::name=
, or whatever), with `...` being a literal of that type. Following similar =
systems in other languages (Template Haskell, lisp macros, ...), there shou=
ld probably be an explicit reification syntax ($foo, perhaps) to disambigua=
te between mention and expansion. So:</div><div><br></div><div>namespace st=
d { using name =3D decltype(`blah`); }</div><div>template<std::name A>=
; struct X { // name is a normal identifier here</div><div>=C2=A0 Y<A>=
; ya; // pass name A to Y</div><div>=C2=A0 Y<$A> yda; // look up the =
name represented by A, pass the result to Y</div><div>=C2=A0 int k1 =3D ya.=
A; // look up member A in ya</div><div>=C2=A0 int k2 =3D ya.$A; // look up =
the name represented by A</div><div>};</div><div>X<`foo`> xfoo;</div>=
<div><br></div><div>If such a thing were formally proposed, it would seem p=
rudent to consider whether it can be extended naturally to capture other co=
nstructs (types, expressions, statements).</div><div><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">
<span class=3D"HOEnZb"><font color=3D"#888888">--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=3D"_b=
lank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C=C2=A0 966C 33F5 F005 6EF4 535=
8<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><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" 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 />
--089e011619c4a1eca305129bf7b8--
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Wed, 01 Apr 2015 07:41:19 +0200
Raw View
This is a multi-part message in MIME format.
--------------090209070601060508070308
Content-Type: text/plain; charset=UTF-8
On 2015-03-31 21:58, Alex B wrote:
> I'm not sure if the idea floated around, but why not use some kind of
> compile time string instead of backticks or the *name* keyword?
>
> |
> template<typenameT,__CompileTimeString s>
> structX
> {
> T __name(s);
> };
>
> X<int,"value">var;
> var.value =0;
> |
>
>
>
> What __CompileTimeString precisely is would be to determine (are there
> any proposals about compile-time strings in the reflection group?).
> Operator *__name* (bikeshed) would convert a compile time string to an
> actual name.
>
> Combine this + compile time strings + other cool reflection features
> and we get something really powerful.
>
IMO compile time strings (can contain anything) and names are different
animals. It should be possible to turn names into compile time strings.
I am not sure about the other way.
And I agree that goal should be to combine reflection (analysis) and
names (synthesis).
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
--------------090209070601060508070308
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">On 2015-03-31 21:58, Alex B wrote:<br>
</div>
<blockquote
cite=3D"mid:969e2b70-427e-45a6-a697-c7866a89d143@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>I'm not sure if the idea floated around, but why not use
some kind of compile time string instead of backticks or the <str=
ong>name</strong>
keyword?</div>
<div>=C2=A0</div>
<div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187,
187); -ms-word-wrap: break-word; background-color: rgb(250,
250, 250);"><code class=3D"prettyprint">
<div class=3D"subprettyprint"><span class=3D"styled-by-prettify=
"
style=3D"color: rgb(0, 0, 136);">template</span><span
class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"=
>
</span><span class=3D"styled-by-prettify" style=3D"color:
rgb(102, 102, 0);"><</span><span
class=3D"styled-by-prettify" style=3D"color: rgb(0, 0,
136);">typename</span><span class=3D"styled-by-prettify"
style=3D"color: rgb(0, 0, 0);"> T</span><span
class=3D"styled-by-prettify" style=3D"color: rgb(102, 102,
0);">,</span><span class=3D"styled-by-prettify"
style=3D"color: rgb(0, 0, 0);"> __CompileTimeString s</span=
><span
class=3D"styled-by-prettify" style=3D"color: rgb(102, 102,
0);">></span><span class=3D"styled-by-prettify"
style=3D"color: rgb(0, 0, 0);"><br>
</span><span class=3D"styled-by-prettify" style=3D"color:
rgb(0, 0, 136);">struct</span><span
class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"=
>
X<br>
</span><span class=3D"styled-by-prettify" style=3D"color:
rgb(102, 102, 0);">{</span><span
class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"=
><br>
=C2=A0 =C2=A0T __name</span><span class=3D"styled-by-pretti=
fy"
style=3D"color: rgb(102, 102, 0);">(</span><span
class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"=
>s</span><span
class=3D"styled-by-prettify" style=3D"color: rgb(102, 102,
0);">);</span><span class=3D"styled-by-prettify"
style=3D"color: rgb(0, 0, 0);"><br>
</span><span class=3D"styled-by-prettify" style=3D"color:
rgb(102, 102, 0);">};</span><span
class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"=
><br>
=C2=A0<br>
X</span><span class=3D"styled-by-prettify" style=3D"color:
rgb(102, 102, 0);"><</span><span
class=3D"styled-by-prettify" style=3D"color: rgb(0, 0,
136);">int</span><span class=3D"styled-by-prettify"
style=3D"color: rgb(102, 102, 0);">,</span><span
class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"=
>
</span><span class=3D"styled-by-prettify" style=3D"color:
rgb(0, 136, 0);">"value"</span><span
class=3D"styled-by-prettify" style=3D"color: rgb(102, 102,
0);">></span><span class=3D"styled-by-prettify"
style=3D"color: rgb(0, 0, 0);"> </span><span
class=3D"styled-by-prettify" style=3D"color: rgb(0, 0,
136);">var</span><span class=3D"styled-by-prettify"
style=3D"color: rgb(102, 102, 0);">;</span><span
class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"=
><br>
</span><span class=3D"styled-by-prettify" style=3D"color:
rgb(0, 0, 136);">var</span><span
class=3D"styled-by-prettify" style=3D"color: rgb(102, 102,
0);">.</span><span class=3D"styled-by-prettify"
style=3D"color: rgb(0, 0, 0);">value </span><span
class=3D"styled-by-prettify" style=3D"color: rgb(102, 102,
0);">=3D</span><span class=3D"styled-by-prettify"
style=3D"color: rgb(0, 0, 0);"> </span><span
class=3D"styled-by-prettify" style=3D"color: rgb(0, 102,
102);">0</span><span class=3D"styled-by-prettify"
style=3D"color: rgb(102, 102, 0);">;</span></div>
</code></div>
<div><br>
</div>
<div>=C2=A0</div>
<div>=C2=A0</div>
<div>What __CompileTimeString precisely is would be to determine
(are there any proposals about compile-time strings in the
reflection group?).</div>
<div>Operator <strong>__name</strong> (bikeshed) would convert
a compile time string to an actual name.</div>
<div>=C2=A0</div>
<div>Combine this + compile time strings + other cool reflection
features and we get something really powerful.</div>
<br>
</div>
</blockquote>
IMO compile time strings (can contain anything) and names are
different animals. It should be possible to turn names into compile
time strings. I am not sure about the other way.<br>
<br>
And I agree that goal should be to combine reflection (analysis) and
names (synthesis).<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" 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 />
--------------090209070601060508070308--
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Wed, 01 Apr 2015 08:11:25 +0200
Raw View
This is a multi-part message in MIME format.
--------------080206010702020908010000
Content-Type: text/plain; charset=UTF-8
On 2015-03-31 22:57, Richard Smith wrote:
> On Tue, Mar 31, 2015 at 12:58 PM, Alex B <devalexb@gmail.com
> <mailto:devalexb@gmail.com>> wrote:
>
> I'm not sure if the idea floated around, but why not use some kind
> of compile time string instead of backticks or the *name* keyword?
>
> |
> template<typenameT,__CompileTimeString s>
> structX
> {
> T __name(s);
> };
>
> X<int,"value">var;
> var.value =0;
> |
>
>
>
> What __CompileTimeString precisely is would be to determine (are
> there any proposals about compile-time strings in the reflection
> group?).
> Operator *__name* (bikeshed) would convert a compile time string
> to an actual name.
>
> Combine this + compile time strings + other cool reflection
> features and we get something really powerful.
>
>
> A name (or rather, an unqualified-id) is not a string.
Agreed, although I think that a name should be convertible to some kind
of string.
> Consider, for instance, the name 'operator int', which should
> presumably be the same name as 'operator T' if T is a typedef for 'int'.
>
Depends on where you look, right?
template<typename T, std::name X>
struct foo
{
$X();
};
struct bar
{
using T = int;
using A = foo<int, `operator T`>;
using B = foo<float, `operator T`>;
using C = foo<float, `operator int`>;
static_assert(std::is_same<A, C>::value == true, "");
static_assert(std::is_same<B, C>::value == false, "");
};
In case B, $X would evaluate to `operator float`, because T is float in foo.
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
--------------080206010702020908010000
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">On 2015-03-31 22:57, Richard Smith
wrote:<br>
</div>
<blockquote
cite=3D"mid:CAOfiQq=3DnMTJqERxA_RYPmUikTTVN3X1UdAQawgP91EFCny3KAw@mail.gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Tue, Mar 31, 2015 at 12:58 PM,
Alex B <span dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:devalexb@gmail.com" target=3D"_blank">devale=
xb@gmail.com</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">
<div>I'm not sure if the idea floated around, but why
not use some kind of compile time string instead of
backticks or the <strong>name</strong> keyword?</div>
<div>=C2=A0</div>
<div style=3D"border:1px solid
rgb(187,187,187);background-color:rgb(250,250,250)"><code=
>
<div><span style=3D"color:rgb(0,0,136)">template</span>=
<span
style=3D"color:rgb(0,0,0)"> </span><span
style=3D"color:rgb(102,102,0)"><</span><span
style=3D"color:rgb(0,0,136)">typename</span><span
style=3D"color:rgb(0,0,0)"> T</span><span
style=3D"color:rgb(102,102,0)">,</span><span
style=3D"color:rgb(0,0,0)"> __CompileTimeString s</=
span><span
style=3D"color:rgb(102,102,0)">></span><span
style=3D"color:rgb(0,0,0)"><br>
</span><span style=3D"color:rgb(0,0,136)">struct</spa=
n><span
style=3D"color:rgb(0,0,0)"> X<br>
</span><span style=3D"color:rgb(102,102,0)">{</span><=
span
style=3D"color:rgb(0,0,0)"><br>
=C2=A0 =C2=A0T __name</span><span
style=3D"color:rgb(102,102,0)">(</span><span
style=3D"color:rgb(0,0,0)">s</span><span
style=3D"color:rgb(102,102,0)">);</span><span
style=3D"color:rgb(0,0,0)"><br>
</span><span style=3D"color:rgb(102,102,0)">};</span>=
<span
style=3D"color:rgb(0,0,0)"><br>
=C2=A0<br>
X</span><span style=3D"color:rgb(102,102,0)"><</=
span><span
style=3D"color:rgb(0,0,136)">int</span><span
style=3D"color:rgb(102,102,0)">,</span><span
style=3D"color:rgb(0,0,0)"> </span><span
style=3D"color:rgb(0,136,0)">"value"</span><span
style=3D"color:rgb(102,102,0)">></span><span
style=3D"color:rgb(0,0,0)"> </span><span
style=3D"color:rgb(0,0,136)">var</span><span
style=3D"color:rgb(102,102,0)">;</span><span
style=3D"color:rgb(0,0,0)"><br>
</span><span style=3D"color:rgb(0,0,136)">var</span><=
span
style=3D"color:rgb(102,102,0)">.</span><span
style=3D"color:rgb(0,0,0)">value </span><span
style=3D"color:rgb(102,102,0)">=3D</span><span
style=3D"color:rgb(0,0,0)"> </span><span
style=3D"color:rgb(0,102,102)">0</span><span
style=3D"color:rgb(102,102,0)">;</span></div>
</code></div>
<div><br>
</div>
<div>=C2=A0</div>
<div>=C2=A0</div>
<div>What __CompileTimeString precisely is would be to
determine (are there any proposals about compile-time
strings in the reflection group?).</div>
<div>Operator <strong>__name</strong> (bikeshed) would
convert a compile time string to an actual name.</div>
<div>=C2=A0</div>
<div>Combine this + compile time strings + other cool
reflection features and we get something really
powerful.</div>
</div>
</blockquote>
<div><br>
</div>
<div>A name (or rather, an unqualified-id) is not a string.</di=
v>
</div>
</div>
</div>
</blockquote>
Agreed, although I think that a name should be convertible to some
kind of string.<br>
<br>
<blockquote
cite=3D"mid:CAOfiQq=3DnMTJqERxA_RYPmUikTTVN3X1UdAQawgP91EFCny3KAw@mail.gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div>Consider, for instance, the name 'operator int', which
should presumably be the same name as 'operator T' if T is
a typedef for 'int'.</div>
<div>=C2=A0</div>
</div>
</div>
</div>
</blockquote>
Depends on where you look, right?<br>
<br>
<tt>template<typename T, std::name X></tt><tt><br>
</tt><tt>struct foo</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 $X();</tt><tt><br>
</tt><tt>};</tt><tt><br>
</tt><tt><br>
</tt><tt>struct bar</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 using T =3D int;</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 using A =3D foo<int, =C2=A0 `operator T`>;<=
/tt><tt><br>
</tt><tt>=C2=A0=C2=A0 using B =3D foo<float, `operator T`>;</tt><=
tt><br>
</tt><tt>
</tt><tt>=C2=A0=C2=A0 using C =3D foo<float, `operator int`>;</tt=
><tt><br>
</tt><tt>=C2=A0=C2=A0 static_assert(std::is_same<A, C>::value =3D=
=3D true,
"");</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 static_assert(std::is_same<B, C>::value =3D=
=3D false,
"");</tt><tt><br>
</tt><tt>
</tt><tt>};</tt><tt><br>
</tt><br>
In case B, $X would evaluate to `operator float`, because T is float
in foo.<br>
<br>
<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" 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 />
--------------080206010702020908010000--
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Wed, 01 Apr 2015 08:14:00 +0200
Raw View
On 2015-03-31 22:14, Matthew Woehlke wrote:
> On 2015-03-31 15:48, Roland Bock wrote:
>> Interesting that you don't use forward ticks or other markers to
>> indicate a name.
> That's *at least* part laziness :-)... and an opinion that the little
> syntax bits aren't nailed down yet. Don't read too much into it :-).
>
>> How would you write names outside of template parameter
>> lists? E.g.
>>
>> struct sample
>> {
>> using my_name = `sample`;
>> };
> That's an interesting point, although I don't entirely follow the
> example. How would you subsequently use 'my_name'? I guess as a template
> parameter?
>
My use case was the CRTP-replaced-by-mixin example in the blog post[1],
here's the mixin:
template <typename Derived>
struct mixin
{
using name = `check`; // name of the mixin
Derived* _derived;
template <typename T>
bool operator()(const T& t) const // mixin is callable
{
return _derived->_data == t;
}
};
// Made this variadic for fun
template<template<typename> class ... Mixin>
struct MyClass
{
Mixin<MyClass> Mixin<MyClass>::name = {this};...
int _data = 7;
};
auto x = MyClass<mixin>{};
x.check(7);
So the mixin has a name (`check`) which is then used by MyClass to name
the member object. Thus, the name is not a template argument here.
> (IOW, I guess you are proposing something a little like, but
> not entirely the same as, a string literal?)
Actually, my original idea of a name literal was similar to a compile
time string. As Richard pointed out, this might be a bad idea (not 100%
sure yet).
[1]: http://cpp.eudoxos.de/dreaming-of-names/
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Wed, 01 Apr 2015 08:36:41 +0200
Raw View
This is a multi-part message in MIME format.
--------------080605010104080802030805
Content-Type: text/plain; charset=UTF-8
On 2015-03-31 23:06, Richard Smith wrote:
> On Tue, Mar 31, 2015 at 12:15 PM, Thiago Macieira <thiago@macieira.org
> <mailto:thiago@macieira.org>> wrote:
>
> On Tuesday 31 March 2015 21:05:50 Roland Bock wrote:
> > template<name A, name B>
>
> Please note that this syntax will conflict with a concept of type
> "name".
>
>
> It would also conflict with a type with name "name" (where A and B
> would be non-type template parameters).
Right.
>
> One could imagine solving this conflict by adding a standard-library
> type std::name (or std::reflect::name, or whatever), with `...` being
> a literal of that type. Following similar systems in other languages
> (Template Haskell, lisp macros, ...), there should probably be an
> explicit reification syntax ($foo, perhaps) to disambiguate between
> mention and expansion. So:
>
> namespace std { using name = decltype(`blah`); }
> template<std::name A> struct X { // name is a normal identifier here
> Y<A> ya; // pass name A to Y
> Y<$A> yda; // look up the name represented by A, pass the result to Y
I am a bit confused here, what would be the differences of
Y<A>
Y<$A>
here? Or did you intend to write
Y<`A`>
Y<$A>
?
> int k1 = ya.A; // look up member A in ya
> int k2 = ya.$A; // look up the name represented by A
> };
> X<`foo`> xfoo;
>
> If such a thing were formally proposed, it would seem prudent to
> consider whether it can be extended naturally to capture other
> constructs (types, expressions, statements).
Whoops! That is a fascinating idea that requires some digestion time :-)
Btw: Quite a few people suggested concatenation of names at CppCon and
fantasized about never needing the preprocessor again (not sure about that).
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
--------------080605010104080802030805
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">On 2015-03-31 23:06, Richard Smith
wrote:<br>
</div>
<blockquote
cite=3D"mid:CAOfiQqnF20C2Lo-qjmEea63CqySPFQVmDCOy1z0oAcPnPYLrhw@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Tue, Mar 31, 2015 at 12:15 PM,
Thiago Macieira <span dir=3D"ltr"><<a
moz-do-not-send=3D"true" href=3D"mailto:thiago@macieira.org=
"
target=3D"_blank">thiago@macieira.org</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class=3D"">On Tuesday 31 March 2015 21:05:50 Roland Bock
wrote:<br>
> template<name A, name B><br>
<br>
</span>Please note that this syntax will conflict with a
concept of type "name".<br>
</blockquote>
<div><br>
</div>
<div>It would also conflict with a type with name "name"
(where A and B would be non-type template parameters).</div>
</div>
</div>
</div>
</blockquote>
Right.<br>
<br>
<blockquote
cite=3D"mid:CAOfiQqnF20C2Lo-qjmEea63CqySPFQVmDCOy1z0oAcPnPYLrhw@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div><br>
</div>
<div>One could imagine solving this conflict by adding a
standard-library type std::name (or std::reflect::name, or
whatever), with `...` being a literal of that type.
Following similar systems in other languages (Template
Haskell, lisp macros, ...), there should probably be an
explicit reification syntax ($foo, perhaps) to
disambiguate between mention and expansion. So:</div>
<div><br>
</div>
<div>namespace std { using name =3D decltype(`blah`); }</div>
<div>template<std::name A> struct X { // name is a
normal identifier here</div>
<div>=C2=A0 Y<A> ya; // pass name A to Y</div>
<div>=C2=A0 Y<$A> yda; // look up the name represented by
A, pass the result to Y</div>
</div>
</div>
</div>
</blockquote>
I am a bit confused here, what would be the differences of <br>
<br>
Y<A><br>
Y<$A><br>
<br>
here? Or did you intend to write <br>
<br>
Y<`A`><br>
Y<$A><br>
<br>
?<br>
<br>
<blockquote
cite=3D"mid:CAOfiQqnF20C2Lo-qjmEea63CqySPFQVmDCOy1z0oAcPnPYLrhw@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div>=C2=A0 int k1 =3D ya.A; // look up member A in ya</div>
<div>=C2=A0 int k2 =3D ya.$A; // look up the name represented b=
y A</div>
<div>};</div>
<div>X<`foo`> xfoo;</div>
<div><br>
</div>
<div>If such a thing were formally proposed, it would seem
prudent to consider whether it can be extended naturally
to capture other constructs (types, expressions,
statements).</div>
</div>
</div>
</div>
</blockquote>
Whoops! That is a fascinating idea that requires some digestion time
:-)<br>
<br>
Btw: Quite a few people suggested concatenation of names at CppCon
and fantasized about never needing the preprocessor again (not sure
about that).<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" 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 />
--------------080605010104080802030805--
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Wed, 01 Apr 2015 10:03:43 +0200
Raw View
On 2015-04-01 08:36, Roland Bock wrote:
>> If such a thing were formally proposed, it would seem prudent to
>> consider whether it can be extended naturally to capture other
>> constructs (types, expressions, statements).
> Whoops! That is a fascinating idea that requires some digestion time :-)
>
> Btw: Quite a few people suggested concatenation of names at CppCon and
> fantasized about never needing the preprocessor again (not sure about
> that).
I should have written "macros" instead of "the preprocessor".
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 1 Apr 2015 15:29:13 +0800
Raw View
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D"" dir=3D"auto"><br c=
lass=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=
=E2=80=9304=E2=80=9301, at 1:41 PM, Roland Bock <<a href=3D"mailto:rbock=
@eudoxos.de" class=3D"">rbock@eudoxos.de</a>> wrote:</div><br class=3D"A=
pple-interchange-newline"><div class=3D"">
=20
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
" class=3D"">
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF" class=3D"">
<div class=3D"moz-cite-prefix">IMO compile time strings (can contain an=
ything) and names are
different animals. It should be possible to turn names into compile
time strings. I am not sure about the other way.</div></div></div></blo=
ckquote><div><br class=3D""></div><div>Strings into names is a well-defined=
transformation: =E2=80=9Cjust=E2=80=9D compile the string. Nothing else re=
ally makes sense.</div><div><br class=3D""></div><div>Names into strings le=
aves a lot of headroom for lazy implementations. What does <font face=3D"Co=
urier" class=3D"">__func__</font> look like in a constructor, destructor, o=
perator overload, or conversion function? Typically it doesn=E2=80=99t look=
like source code. More common to see compatibility with <font face=3D"Cour=
ier" class=3D"">dlsym</font> than with the C++ compiler, and no reason to e=
xpect that trend to reverse.</div><br class=3D""><blockquote type=3D"cite" =
class=3D""><div class=3D""><div text=3D"#000000" bgcolor=3D"#FFFFFF" class=
=3D"">
=20
And I agree that goal should be to combine reflection (analysis) and
names (synthesis).<br class=3D"">
</div></div></blockquote><br class=3D""></div><div>Not sure how well all =
this fits into the existing template model.</div><div><br class=3D""></div>=
<div>It could be nice to add basic scope awareness to the current preproces=
sor, just at the level of minding namespaces and counting braces. We alread=
y have the <font face=3D"Courier" class=3D"">##</font> operator for synthes=
izing names and the <font face=3D"Courier" class=3D"">#</font> operator for=
getting strings, they just suffer from lack of encapsulation.</div></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" 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 />
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Wed, 01 Apr 2015 17:46:04 +0200
Raw View
This is a multi-part message in MIME format.
--------------090002000903050907080908
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 2015-04-01 09:29, David Krauss wrote:
>
>> On 2015=E2=80=9304=E2=80=9301, at 1:41 PM, Roland Bock <rbock@eudoxos.de
>> <mailto:rbock@eudoxos.de>> wrote:
>>
>> IMO compile time strings (can contain anything) and names are
>> different animals. It should be possible to turn names into compile
>> time strings. I am not sure about the other way.
>
> Strings into names is a well-defined transformation: =E2=80=9Cjust=E2=80=
=9D compile
> the string. Nothing else really makes sense.
I can't really comment on the "just".
>
> Names into strings leaves a lot of headroom for lazy implementations.
> What does __func__ look like in a constructor, destructor, operator
> overload, or conversion function? Typically it doesn=E2=80=99t look like
> source code. More common to see compatibility with dlsym than with the
> C++ compiler, and no reason to expect that trend to reverse.
The internal representation is not what this is about. The idea is to have
- tokens
- identifiers
- or even expressions
as literals which can be used as template arguments for instance.
>
>> And I agree that goal should be to combine reflection (analysis) and
>> names (synthesis).
>
> Not sure how well all this fits into the existing template model.
I'd be very interested in your doubts.
>
> It could be nice to add basic scope awareness to the current
> preprocessor, just at the level of minding namespaces and counting
> braces. We already have the ## operator for synthesizing names and the
> # operator for getting strings, they just suffer from lack of
> encapsulation.
True, but that is a different topic in my eyes, isn't it?
Best,
Roland
--=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/.
--------------090002000903050907080908
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">On 2015-04-01 09:29, David Krauss
wrote:<br>
</div>
<blockquote
cite=3D"mid:3A5CADAC-0058-48AB-9A0B-635EA0AA7AE1@gmail.com"
type=3D"cite">
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf=
-8">
<br class=3D"">
<div>
<blockquote type=3D"cite" class=3D"">
<div class=3D"">On 2015=E2=80=9304=E2=80=9301, at 1:41 PM, Roland=
Bock <<a
moz-do-not-send=3D"true" href=3D"mailto:rbock@eudoxos.de"
class=3D"">rbock@eudoxos.de</a>> wrote:</div>
<br class=3D"Apple-interchange-newline">
<div class=3D"">
<meta content=3D"text/html; charset=3Dutf-8"
http-equiv=3D"Content-Type" class=3D"">
<div text=3D"#000000" bgcolor=3D"#FFFFFF" class=3D"">
<div class=3D"moz-cite-prefix">IMO compile time strings (can
contain anything) and names are different animals. It
should be possible to turn names into compile time
strings. I am not sure about the other way.</div>
</div>
</div>
</blockquote>
<div><br class=3D"">
</div>
<div>Strings into names is a well-defined transformation: =E2=80=9C=
just=E2=80=9D
compile the string. Nothing else really makes sense.</div>
</div>
</blockquote>
I can't really comment on the "just".<br>
<br>
<blockquote
cite=3D"mid:3A5CADAC-0058-48AB-9A0B-635EA0AA7AE1@gmail.com"
type=3D"cite">
<div>
<div><br class=3D"">
</div>
<div>Names into strings leaves a lot of headroom for lazy
implementations. What does <font class=3D"" face=3D"Courier">__fu=
nc__</font>
look like in a constructor, destructor, operator overload, or
conversion function? Typically it doesn=E2=80=99t look like sourc=
e
code. More common to see compatibility with <font class=3D""
face=3D"Courier">dlsym</font> than with the C++ compiler, and
no reason to expect that trend to reverse.</div>
</div>
</blockquote>
The internal representation is not what this is about. The idea is
to have <br>
<br>
- tokens<br>
- identifiers<br>
- or even expressions<br>
<br>
as literals which can be used as template arguments for instance.<br>
<br>
<blockquote
cite=3D"mid:3A5CADAC-0058-48AB-9A0B-635EA0AA7AE1@gmail.com"
type=3D"cite">
<div><br class=3D"">
<blockquote type=3D"cite" class=3D"">
<div class=3D"">
<div text=3D"#000000" bgcolor=3D"#FFFFFF" class=3D""> And I agr=
ee
that goal should be to combine reflection (analysis) and
names (synthesis).<br class=3D"">
</div>
</div>
</blockquote>
<br class=3D"">
</div>
<div>Not sure how well all this fits into the existing template
model.</div>
</blockquote>
I'd be very interested in your doubts.<br>
<br>
<blockquote
cite=3D"mid:3A5CADAC-0058-48AB-9A0B-635EA0AA7AE1@gmail.com"
type=3D"cite">
<div><br class=3D"">
</div>
<div>It could be nice to add basic scope awareness to the current
preprocessor, just at the level of minding namespaces and
counting braces. We already have the <font class=3D""
face=3D"Courier">##</font> operator for synthesizing names and
the <font class=3D"" face=3D"Courier">#</font> operator for getting
strings, they just suffer from lack of encapsulation.</div>
</blockquote>
<br>
True, but that is a different topic in my eyes, isn't it?<br>
<br>
<br>
Best,<br>
<br>
Roland<br>
<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" 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 />
--------------090002000903050907080908--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Wed, 1 Apr 2015 11:57:01 -0700
Raw View
--047d7b33caf2c5117c0512ae4758
Content-Type: text/plain; charset=UTF-8
On Tue, Mar 31, 2015 at 11:36 PM, Roland Bock <rbock@eudoxos.de> wrote:
> On 2015-03-31 23:06, Richard Smith wrote:
>
> On Tue, Mar 31, 2015 at 12:15 PM, Thiago Macieira <thiago@macieira.org>
> wrote:
>
>> On Tuesday 31 March 2015 21:05:50 Roland Bock wrote:
>> > template<name A, name B>
>>
>> Please note that this syntax will conflict with a concept of type "name".
>>
>
> It would also conflict with a type with name "name" (where A and B would
> be non-type template parameters).
>
> Right.
>
>
> One could imagine solving this conflict by adding a standard-library
> type std::name (or std::reflect::name, or whatever), with `...` being a
> literal of that type. Following similar systems in other languages
> (Template Haskell, lisp macros, ...), there should probably be an explicit
> reification syntax ($foo, perhaps) to disambiguate between mention and
> expansion. So:
>
> namespace std { using name = decltype(`blah`); }
> template<std::name A> struct X { // name is a normal identifier here
> Y<A> ya; // pass name A to Y
> Y<$A> yda; // look up the name represented by A, pass the result to Y
>
> I am a bit confused here, what would be the differences of
>
> Y<A>
> Y<$A>
>
> here?
>
As the comments say, the first passes the name A to Y, the second passes
the result of looking up the name to Y. So, given
constexpr std::name foo = `bar`;
X<`foo`>::ya would have type Y<`foo`>
X<`foo`>::yda would have type Y<`bar`>
> Or did you intend to write
>
> Y<`A`>
> Y<$A>
>
No; Y<`A`> is something different again.
?
>
> int k1 = ya.A; // look up member A in ya
> int k2 = ya.$A; // look up the name represented by A
> };
> X<`foo`> xfoo;
>
> If such a thing were formally proposed, it would seem prudent to
> consider whether it can be extended naturally to capture other constructs
> (types, expressions, statements).
>
> Whoops! That is a fascinating idea that requires some digestion time :-)
>
> Btw: Quite a few people suggested concatenation of names at CppCon and
> fantasized about never needing the preprocessor again (not sure about that).
>
> --
>
> ---
> 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
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7b33caf2c5117c0512ae4758
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, Mar 31, 2015 at 11:36 PM, Roland Bock <span dir=3D"ltr"><<a href=3D"=
mailto:rbock@eudoxos.de" target=3D"_blank">rbock@eudoxos.de</a>></span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF"><span class=3D"">
<div>On 2015-03-31 23:06, Richard Smith
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Tue, Mar 31, 2015 at 12:15 PM,
Thiago Macieira <span dir=3D"ltr"><<a href=3D"mailto:thiago@=
macieira.org" target=3D"_blank">thiago@macieira.org</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><span>On Tuesday 31 March 2015 2=
1:05:50 Roland Bock
wrote:<br>
> template<name A, name B><br>
<br>
</span>Please note that this syntax will conflict with a
concept of type "name".<br>
</blockquote>
<div><br>
</div>
<div>It would also conflict with a type with name "name&qu=
ot;
(where A and B would be non-type template parameters).</div>
</div>
</div>
</div>
</blockquote></span>
Right.<span class=3D""><br>
<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div><br>
</div>
<div>One could imagine solving this conflict by adding a
standard-library type std::name (or std::reflect::name, or
whatever), with `...` being a literal of that type.
Following similar systems in other languages (Template
Haskell, lisp macros, ...), there should probably be an
explicit reification syntax ($foo, perhaps) to
disambiguate between mention and expansion. So:</div>
<div><br>
</div>
<div>namespace std { using name =3D decltype(`blah`); }</div>
<div>template<std::name A> struct X { // name is a
normal identifier here</div>
<div>=C2=A0 Y<A> ya; // pass name A to Y</div>
<div>=C2=A0 Y<$A> yda; // look up the name represented by
A, pass the result to Y</div>
</div>
</div>
</div>
</blockquote></span>
I am a bit confused here, what would be the differences of <br>
<br>
Y<A><br>
Y<$A><br>
<br>
here?</div></blockquote><div><br></div><div>As the comments say, the fi=
rst passes the name A to Y, the second passes the result of looking up the =
name to Y. So, given</div><div><br></div><div>=C2=A0 constexpr std::name fo=
o =3D `bar`;</div><div><br></div><div>X<`foo`>::ya would have type Y&=
lt;`foo`></div><div>X<`foo`>::yda would have type Y<`bar`></=
div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text=3D"#000000" b=
gcolor=3D"#FFFFFF">Or did you intend to write <br>
<br>
Y<`A`><br>
Y<$A></div></blockquote><div><br></div><div>No; Y<`A`> is s=
omething different again.</div><div><br></div><blockquote class=3D"gmail_qu=
ote" 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>
<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div>=C2=A0 int k1 =3D ya.A; // look up member A in ya</div>
<div>=C2=A0 int k2 =3D ya.$A; // look up the name represented b=
y A</div>
<div>};</div>
<div>X<`foo`> xfoo;</div>
<div><br>
</div>
<div>If such a thing were formally proposed, it would seem
prudent to consider whether it can be extended naturally
to capture other constructs (types, expressions,
statements).</div>
</div>
</div>
</div>
</blockquote></span>
Whoops! That is a fascinating idea that requires some digestion time
:-)<br>
<br>
Btw: Quite a few people suggested concatenation of names at CppCon
and fantasized about never needing the preprocessor again (not sure
about that).<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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" target=3D"_=
blank">std-proposals+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></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--047d7b33caf2c5117c0512ae4758--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Wed, 1 Apr 2015 12:06:20 -0700
Raw View
--001a11c30864213e070512ae690e
Content-Type: text/plain; charset=UTF-8
On Tue, Mar 31, 2015 at 11:11 PM, Roland Bock <rbock@eudoxos.de> wrote:
> On 2015-03-31 22:57, Richard Smith wrote:
>
> On Tue, Mar 31, 2015 at 12:58 PM, Alex B <devalexb@gmail.com> wrote:
>
>> I'm not sure if the idea floated around, but why not use some kind of
>> compile time string instead of backticks or the *name* keyword?
>>
>> template <typename T, __CompileTimeString s>
>> struct X
>> {
>> T __name(s);
>> };
>>
>> X<int, "value"> var;
>> var.value = 0;
>>
>>
>>
>> What __CompileTimeString precisely is would be to determine (are there
>> any proposals about compile-time strings in the reflection group?).
>> Operator *__name* (bikeshed) would convert a compile time string to an
>> actual name.
>>
>> Combine this + compile time strings + other cool reflection features and
>> we get something really powerful.
>>
>
> A name (or rather, an unqualified-id) is not a string.
>
> Agreed, although I think that a name should be convertible to some kind of
> string.
>
> Consider, for instance, the name 'operator int', which should
> presumably be the same name as 'operator T' if T is a typedef for 'int'.
>
>
> Depends on where you look, right?
>
No, I don't think it should, and I don't think it can. The translation from
the token sequence to a name should be performed where the name lexically
appears.
> template<typename T, std::name X>
> struct foo
> {
> $X();
> };
>
> struct bar
> {
> using T = int;
> using A = foo<int, `operator T`>;
> using B = foo<float, `operator T`>;
>
Both these references to T should find the T declared just above, that is,
'int'. If not, it's not possible to form a name representing a conversion
operator to some local type, or template type parameter, or similar. And
consider
`operator T::U<V>`
We need to know whether T::U is a template to be able to parse this sort of
thing, which means we should bind it early.
using C = foo<float, `operator int`>;
> static_assert(std::is_same<A, C>::value == true, "");
> static_assert(std::is_same<B, C>::value == false, "");
> };
>
> In case B, $X would evaluate to `operator float`, because T is float in
> foo.
>
Being able to snoop into other scopes by deferring the lookup of a
component of a name seems like a bad idea to me. I find it hard to imagine
your interpretation of code like the above being the desired one.
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c30864213e070512ae690e
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, Mar 31, 2015 at 11:11 PM, Roland Bock <span dir=3D"ltr"><<a href=3D"=
mailto:rbock@eudoxos.de" target=3D"_blank">rbock@eudoxos.de</a>></span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF"><span class=3D"">
<div>On 2015-03-31 22:57, Richard Smith
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Tue, Mar 31, 2015 at 12:58 PM,
Alex B <span dir=3D"ltr"><<a href=3D"mailto:devalexb@gmail.c=
om" target=3D"_blank">devalexb@gmail.com</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">
<div>I'm not sure if the idea floated around, but why
not use some kind of compile time string instead of
backticks or the <strong>name</strong> keyword?</div>
<div>=C2=A0</div>
<div style=3D"border:1px solid rgb(187,187,187);background-=
color:rgb(250,250,250)"><code>
<div><span style=3D"color:rgb(0,0,136)">template</span>=
<span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0=
)"><</span><span style=3D"color:rgb(0,0,136)">typename</span><span style=
=3D"color:rgb(0,0,0)"> T</span><span style=3D"color:rgb(102,102,0)">,</span=
><span style=3D"color:rgb(0,0,0)"> __CompileTimeString s</span><span style=
=3D"color:rgb(102,102,0)">></span><span style=3D"color:rgb(0,0,0)"><br>
</span><span style=3D"color:rgb(0,0,136)">struct</spa=
n><span style=3D"color:rgb(0,0,0)"> X<br>
</span><span style=3D"color:rgb(102,102,0)">{</span><=
span style=3D"color:rgb(0,0,0)"><br>
=C2=A0 =C2=A0T __name</span><span style=3D"color:rg=
b(102,102,0)">(</span><span style=3D"color:rgb(0,0,0)">s</span><span style=
=3D"color:rgb(102,102,0)">);</span><span style=3D"color:rgb(0,0,0)"><br>
</span><span style=3D"color:rgb(102,102,0)">};</span>=
<span style=3D"color:rgb(0,0,0)"><br>
=C2=A0<br>
X</span><span style=3D"color:rgb(102,102,0)"><</=
span><span style=3D"color:rgb(0,0,136)">int</span><span style=3D"color:rgb(=
102,102,0)">,</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D=
"color:rgb(0,136,0)">"value"</span><span style=3D"color:rgb(102,1=
02,0)">></span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"c=
olor:rgb(0,0,136)">var</span><span style=3D"color:rgb(102,102,0)">;</span><=
span style=3D"color:rgb(0,0,0)"><br>
</span><span style=3D"color:rgb(0,0,136)">var</span><=
span style=3D"color:rgb(102,102,0)">.</span><span style=3D"color:rgb(0,0,0)=
">value </span><span style=3D"color:rgb(102,102,0)">=3D</span><span style=
=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,102,102)">0</span>=
<span style=3D"color:rgb(102,102,0)">;</span></div>
</code></div>
<div><br>
</div>
<div>=C2=A0</div>
<div>=C2=A0</div>
<div>What __CompileTimeString precisely is would be to
determine (are there any proposals about compile-time
strings in the reflection group?).</div>
<div>Operator <strong>__name</strong> (bikeshed) would
convert a compile time string to an actual name.</div>
<div>=C2=A0</div>
<div>Combine this + compile time strings + other cool
reflection features and we get something really
powerful.</div>
</div>
</blockquote>
<div><br>
</div>
<div>A name (or rather, an unqualified-id) is not a string.</di=
v>
</div>
</div>
</div>
</blockquote></span>
Agreed, although I think that a name should be convertible to some
kind of string.<span class=3D""><br>
<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div>Consider, for instance, the name 'operator int', w=
hich
should presumably be the same name as 'operator T' if=
T is
a typedef for 'int'.</div>
<div>=C2=A0</div>
</div>
</div>
</div>
</blockquote></span>
Depends on where you look, right?<br></div></blockquote><div><br></div>=
<div>No, I don't think it should, and I don't think it can. The tra=
nslation from the token sequence to a name should be performed where the na=
me lexically appears.</div><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<tt>template<typename T, std::name X></tt><tt><br>
</tt><tt>struct foo</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 $X();</tt><tt><br>
</tt><tt>};</tt><tt><br>
</tt><tt><br>
</tt><tt>struct bar</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 using T =3D int;</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 using A =3D foo<int, =C2=A0 `operator T`>;<=
/tt><tt><br>
</tt><tt>=C2=A0=C2=A0 using B =3D foo<float, `operator T`>;</tt><=
/div></blockquote><div><br></div><div>Both these references to T should fin=
d the T declared just above, that is, 'int'. If not, it's not p=
ossible to form a name representing a conversion operator to some local typ=
e, or template type parameter, or similar. And consider</div><div><br></div=
><div>=C2=A0 `operator T::U<V>`</div><div><br></div><div>We need to k=
now whether T::U is a template to be able to parse this sort of thing, whic=
h means we should bind it early.</div><div><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div text=3D"#000000" bgcolor=3D"#FFFFFF"><tt>
</tt><tt>=C2=A0=C2=A0 using C =3D foo<float, `operator int`>;</tt=
><tt><br>
</tt><tt>=C2=A0=C2=A0 static_assert(std::is_same<A, C>::value =3D=
=3D true,
"");</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 static_assert(std::is_same<B, C>::value =3D=
=3D false,
"");</tt><tt><br>
</tt><tt>
</tt><tt>};</tt><tt><br>
</tt><br>
In case B, $X would evaluate to `operator float`, because T is float
in foo.</div></blockquote><div><br></div><div>Being able to snoop into =
other scopes by deferring the lookup of a component of a name seems like a =
bad idea to me. I find it hard to imagine your interpretation of code like =
the above being the desired one.</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" 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 />
--001a11c30864213e070512ae690e--
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Wed, 01 Apr 2015 21:37:51 +0200
Raw View
This is a multi-part message in MIME format.
--------------090805030807060003080706
Content-Type: text/plain; charset=UTF-8
On 2015-04-01 20:57, Richard Smith wrote:
> On Tue, Mar 31, 2015 at 11:36 PM, Roland Bock <rbock@eudoxos.de
> <mailto:rbock@eudoxos.de>> wrote:
>
> On 2015-03-31 23:06, Richard Smith wrote:
>> On Tue, Mar 31, 2015 at 12:15 PM, Thiago Macieira
>> <thiago@macieira.org <mailto:thiago@macieira.org>> wrote:
>>
>> On Tuesday 31 March 2015 21:05:50 Roland Bock wrote:
>> > template<name A, name B>
>>
>> Please note that this syntax will conflict with a concept of
>> type "name".
>>
>>
>> It would also conflict with a type with name "name" (where A and
>> B would be non-type template parameters).
> Right.
>
>>
>> One could imagine solving this conflict by adding a
>> standard-library type std::name (or std::reflect::name, or
>> whatever), with `...` being a literal of that type. Following
>> similar systems in other languages (Template Haskell, lisp
>> macros, ...), there should probably be an explicit reification
>> syntax ($foo, perhaps) to disambiguate between mention and
>> expansion. So:
>>
>> namespace std { using name = decltype(`blah`); }
>> template<std::name A> struct X { // name is a normal identifier here
>> Y<A> ya; // pass name A to Y
>> Y<$A> yda; // look up the name represented by A, pass the
>> result to Y
> I am a bit confused here, what would be the differences of
>
> Y<A>
> Y<$A>
>
> here?
>
>
> As the comments say, the first passes the name A to Y, the second
> passes the result of looking up the name to Y. So, given
>
> constexpr std::name foo = `bar`;
>
> X<`foo`>::ya would have type Y<`foo`>
> X<`foo`>::yda would have type Y<`bar`>
>
>
> Or did you intend to write
>
> Y<`A`>
> Y<$A>
>
>
> No; Y<`A`> is something different again.
Got it. I did not think of the possibility that foo might be a std::name
itself.
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
--------------090805030807060003080706
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">On 2015-04-01 20:57, Richard Smith
wrote:<br>
</div>
<blockquote
cite=3D"mid:CAOfiQq=3DpY=3DD=3D02dDVX-KqqbcEbynUDt=3DM+7Qakv768V6N64kWg@mai=
l.gmail.com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Tue, Mar 31, 2015 at 11:36 PM,
Roland Bock <span dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:rbock@eudoxos.de" target=3D"_blank">rbock@eu=
doxos.de</a>></span>
wrote:<br>
<blockquote 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"">
<div>On 2015-03-31 23:06, Richard Smith wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Tue, Mar 31, 2015 at
12:15 PM, Thiago Macieira <span dir=3D"ltr"><<=
a
moz-do-not-send=3D"true"
href=3D"mailto:thiago@macieira.org"
target=3D"_blank">thiago@macieira.org</a>>=
</span>
wrote:<br>
<blockquote class=3D"gmail_quote"
style=3D"margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex"><span>On
Tuesday 31 March 2015 21:05:50 Roland Bock
wrote:<br>
> template<name A, name B><br>
<br>
</span>Please note that this syntax will
conflict with a concept of type "name".<br>
</blockquote>
<div><br>
</div>
<div>It would also conflict with a type with
name "name" (where A and B would be non-type
template parameters).</div>
</div>
</div>
</div>
</blockquote>
</span> Right.<span class=3D""><br>
<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div><br>
</div>
<div>One could imagine solving this conflict
by adding a standard-library type std::name
(or std::reflect::name, or whatever), with
`...` being a literal of that type.
Following similar systems in other languages
(Template Haskell, lisp macros, ...), there
should probably be an explicit reification
syntax ($foo, perhaps) to disambiguate
between mention and expansion. So:</div>
<div><br>
</div>
<div>namespace std { using name =3D
decltype(`blah`); }</div>
<div>template<std::name A> struct X { //
name is a normal identifier here</div>
<div>=C2=A0 Y<A> ya; // pass name A to Y</d=
iv>
<div>=C2=A0 Y<$A> yda; // look up the name
represented by A, pass the result to Y</div>
</div>
</div>
</div>
</blockquote>
</span> I am a bit confused here, what would be the
differences of <br>
<br>
Y<A><br>
Y<$A><br>
<br>
here?</div>
</blockquote>
<div><br>
</div>
<div>As the comments say, the first passes the name A to Y,
the second passes the result of looking up the name to Y.
So, given</div>
<div><br>
</div>
<div>=C2=A0 constexpr std::name foo =3D `bar`;</div>
<div><br>
</div>
<div>X<`foo`>::ya would have type Y<`foo`></div>
<div>X<`foo`>::yda would have type Y<`bar`></div>
<div>=C2=A0</div>
<blockquote 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">Or did you intend t=
o
write <br>
<br>
Y<`A`><br>
Y<$A></div>
</blockquote>
<div><br>
</div>
<div>No; Y<`A`> is something different again.<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
Got it. I did not think of the possibility that foo might be a
std::name itself.<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" 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 />
--------------090805030807060003080706--
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Wed, 01 Apr 2015 22:49:20 +0200
Raw View
This is a multi-part message in MIME format.
--------------080108090703020306020503
Content-Type: text/plain; charset=UTF-8
On 2015-04-01 21:06, Richard Smith wrote:
> On Tue, Mar 31, 2015 at 11:11 PM, Roland Bock <rbock@eudoxos.de
> <mailto:rbock@eudoxos.de>> wrote:
>
> On 2015-03-31 22:57, Richard Smith wrote:
>> On Tue, Mar 31, 2015 at 12:58 PM, Alex B <devalexb@gmail.com
>> <mailto:devalexb@gmail.com>> wrote:
>>
>> I'm not sure if the idea floated around, but why not use some
>> kind of compile time string instead of backticks or the
>> *name* keyword?
>>
>> |
>> template<typenameT,__CompileTimeString s>
>> structX
>> {
>> T __name(s);
>> };
>>
>> X<int,"value">var;
>> var.value =0;
>> |
>>
>>
>>
>> What __CompileTimeString precisely is would be to determine
>> (are there any proposals about compile-time strings in the
>> reflection group?).
>> Operator *__name* (bikeshed) would convert a compile time
>> string to an actual name.
>>
>> Combine this + compile time strings + other cool reflection
>> features and we get something really powerful.
>>
>>
>> A name (or rather, an unqualified-id) is not a string.
> Agreed, although I think that a name should be convertible to some
> kind of string.
>
>> Consider, for instance, the name 'operator int', which should
>> presumably be the same name as 'operator T' if T is a typedef for
>> 'int'.
>>
> Depends on where you look, right?
>
>
> No, I don't think it should, and I don't think it can. The translation
> from the token sequence to a name should be performed where the name
> lexically appears.
>
>
> template<typename T, std::name X>
> struct foo
> {
> $X();
> };
>
> struct bar
> {
> using T = int;
> using A = foo<int, `operator T`>;
> using B = foo<float, `operator T`>;
>
>
> Both these references to T should find the T declared just above, that
> is, 'int'.
That sounds wrong to me. Here's another example:
template<typename T1, typename T2, std::name N1, std::name N2>
struct named_pair
{
T1 N1;
T2 N2;
};
struct sample
{
using A = int;
using B = float;
using C = named_pair<char, char, `A`, `B`>;
};
using D = named_pair<char, char, `A`, `B`>;
If I understand you correctly, since A and B are defined in sample, you
would interpret them as `int` and `float`, which would lead to a compile
error for C, while D is OK?
It would mean that named_pair<char, char, `A`, `B`> could mean different
things depending on the scope it is used in?
> If not, it's not possible to form a name representing a conversion
> operator to some local type, or template type parameter, or similar.
I wonder whether this is a real use case? I am asking because I have no
idea yet how I would use `operator T`?
template<typename T, std::name X>
struct sample
{
X() {/* What goes here? */}
};
> And consider
>
> `operator T::U<V>`
>
> We need to know whether T::U is a template to be able to parse this
> sort of thing, which means we should bind it early.
Assuming my interpretation, using this would imply a bunch of
requirements for the template and/or other template parameters, but that
is nothing new, is it?
using X = foo<`operator T::U<V>`>;
For this to compile, foo has to have a type T such that T::U<V> makes
sense. But that's ok, I'd say.
Best,
Roland
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
--------------080108090703020306020503
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">On 2015-04-01 21:06, Richard Smith
wrote:<br>
</div>
<blockquote
cite=3D"mid:CAOfiQqkRfc+HhnaWKza1ZmdTtfu35NUuCjoDbCTZJcHXBwpLVw@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Tue, Mar 31, 2015 at 11:11 PM,
Roland Bock <span dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:rbock@eudoxos.de" target=3D"_blank">rbock@eu=
doxos.de</a>></span>
wrote:<br>
<blockquote 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"">
<div>On 2015-03-31 22:57, Richard Smith wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Tue, Mar 31, 2015 at
12:58 PM, Alex B <span dir=3D"ltr"><<a
moz-do-not-send=3D"true"
href=3D"mailto:devalexb@gmail.com"
target=3D"_blank">devalexb@gmail.com</a>><=
/span>
wrote:<br>
<blockquote class=3D"gmail_quote"
style=3D"margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<div dir=3D"ltr">
<div>I'm not sure if the idea floated
around, but why not use some kind of
compile time string instead of backticks
or the <strong>name</strong> keyword?</div>
<div>=C2=A0</div>
<div style=3D"border:1px solid
rgb(187,187,187);background-color:rgb(250,2=
50,250)"><code>
<div><span style=3D"color:rgb(0,0,136)">t=
emplate</span><span
style=3D"color:rgb(0,0,0)"> </span><s=
pan
style=3D"color:rgb(102,102,0)"><</=
span><span
style=3D"color:rgb(0,0,136)">typename=
</span><span
style=3D"color:rgb(0,0,0)"> T</span><=
span
style=3D"color:rgb(102,102,0)">,</spa=
n><span
style=3D"color:rgb(0,0,0)">
__CompileTimeString s</span><span
style=3D"color:rgb(102,102,0)">></=
span><span
style=3D"color:rgb(0,0,0)"><br>
</span><span
style=3D"color:rgb(0,0,136)">struct</=
span><span
style=3D"color:rgb(0,0,0)"> X<br>
</span><span
style=3D"color:rgb(102,102,0)">{</spa=
n><span
style=3D"color:rgb(0,0,0)"><br>
=C2=A0 =C2=A0T __name</span><span
style=3D"color:rgb(102,102,0)">(</spa=
n><span
style=3D"color:rgb(0,0,0)">s</span><s=
pan
style=3D"color:rgb(102,102,0)">);</sp=
an><span
style=3D"color:rgb(0,0,0)"><br>
</span><span
style=3D"color:rgb(102,102,0)">};</sp=
an><span
style=3D"color:rgb(0,0,0)"><br>
=C2=A0<br>
X</span><span
style=3D"color:rgb(102,102,0)"><</=
span><span
style=3D"color:rgb(0,0,136)">int</spa=
n><span
style=3D"color:rgb(102,102,0)">,</spa=
n><span
style=3D"color:rgb(0,0,0)"> </span><s=
pan
style=3D"color:rgb(0,136,0)">"value"<=
/span><span
style=3D"color:rgb(102,102,0)">></=
span><span
style=3D"color:rgb(0,0,0)"> </span><s=
pan
style=3D"color:rgb(0,0,136)">var</spa=
n><span
style=3D"color:rgb(102,102,0)">;</spa=
n><span
style=3D"color:rgb(0,0,0)"><br>
</span><span
style=3D"color:rgb(0,0,136)">var</spa=
n><span
style=3D"color:rgb(102,102,0)">.</spa=
n><span
style=3D"color:rgb(0,0,0)">value </sp=
an><span
style=3D"color:rgb(102,102,0)">=3D</s=
pan><span
style=3D"color:rgb(0,0,0)"> </span><s=
pan
style=3D"color:rgb(0,102,102)">0</spa=
n><span
style=3D"color:rgb(102,102,0)">;</spa=
n></div>
</code></div>
<div><br>
</div>
<div>=C2=A0</div>
<div>=C2=A0</div>
<div>What __CompileTimeString precisely is
would be to determine (are there any
proposals about compile-time strings in
the reflection group?).</div>
<div>Operator <strong>__name</strong>
(bikeshed) would convert a compile time
string to an actual name.</div>
<div>=C2=A0</div>
<div>Combine this + compile time strings +
other cool reflection features and we
get something really powerful.</div>
</div>
</blockquote>
<div><br>
</div>
<div>A name (or rather, an unqualified-id) is
not a string.</div>
</div>
</div>
</div>
</blockquote>
</span> Agreed, although I think that a name should be
convertible to some kind of string.<span class=3D""><br>
<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div>Consider, for instance, the name
'operator int', which should presumably be
the same name as 'operator T' if T is a
typedef for 'int'.</div>
<div>=C2=A0</div>
</div>
</div>
</div>
</blockquote>
</span> Depends on where you look, right?<br>
</div>
</blockquote>
<div><br>
</div>
<div>No, I don't think it should, and I don't think it can.
The translation from the token sequence to a name should
be performed where the name lexically appears.</div>
<div>=C2=A0</div>
<blockquote 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"> <tt>template<ty=
pename
T, std::name X></tt><tt><br>
</tt><tt>struct foo</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 $X();</tt><tt><br>
</tt><tt>};</tt><tt><br>
</tt><tt><br>
</tt><tt>struct bar</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 using T =3D int;</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 using A =3D foo<int, =C2=A0 `opera=
tor T`>;</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 using B =3D foo<float, `operator T=
`>;</tt></div>
</blockquote>
<div><br>
</div>
<div>Both these references to T should find the T declared
just above, that is, 'int'. </div>
</div>
</div>
</div>
</blockquote>
That sounds wrong to me. Here's another example:<br>
<br>
<tt>template<typename T1, typename T2, std::name N1, std::name
N2></tt><tt><br>
</tt><tt>struct named_pair</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 T1 N1;</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 T2 N2;</tt><tt><br>
</tt><tt>};</tt><tt><br>
</tt><tt><br>
</tt><tt>struct sample</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0 using A =3D int;</tt><tt><br>
</tt><tt>=C2=A0 using B =3D float;</tt><tt><br>
</tt><tt>=C2=A0 using C =3D named_pair<char, char, `A`, `B`>;</tt=
><tt><br>
</tt><tt>};</tt><tt><br>
</tt><tt>using D =3D named_pair<char, char, `A`, `B`>;</tt><br>
<br>
If I understand you correctly, since A and B are defined in sample,
you would interpret them as `int` and `float`, which would lead to a
compile error for C, while D is OK?<br>
<br>
It would mean that <tt>named_pair<char, char, `A`, `B`></tt>
could mean different things depending on the scope it is used in?<br>
<br>
<br>
<blockquote
cite=3D"mid:CAOfiQqkRfc+HhnaWKza1ZmdTtfu35NUuCjoDbCTZJcHXBwpLVw@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div>If not, it's not possible to form a name representing a
conversion operator to some local type, or template type
parameter, or similar. </div>
</div>
</div>
</div>
</blockquote>
I wonder whether this is a real use case? I am asking because I have
no idea yet how I would use `operator T`?<br>
<br>
<tt>template<typename T, std::name X></tt><tt><br>
</tt><tt>struct sample</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 X() {/* What goes here? */}</tt><tt><br>
</tt><tt>};</tt><br>
<br>
<br>
<blockquote
cite=3D"mid:CAOfiQqkRfc+HhnaWKza1ZmdTtfu35NUuCjoDbCTZJcHXBwpLVw@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div>And consider</div>
<div><br>
</div>
<div>=C2=A0 `operator T::U<V>`</div>
<div><br>
</div>
<div>We need to know whether T::U is a template to be able
to parse this sort of thing, which means we should bind it
early.</div>
</div>
</div>
</div>
</blockquote>
<br>
Assuming my interpretation, using this would imply a bunch of
requirements for the template and/or other template parameters, but
that is nothing new, is it?<br>
<br>
<tt>using X =3D foo<`operator T::U<V>`>;</tt><br>
<br>
For this to compile, foo has to have a type <tt>T</tt> such that <tt>T:=
:U<V></tt>
makes sense. But that's ok, I'd say.<br>
<br>
<br>
Best,<br>
<br>
Roland<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" 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 />
--------------080108090703020306020503--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Wed, 1 Apr 2015 14:31:55 -0700
Raw View
--001a11c24a16bd60b10512b071da
Content-Type: text/plain; charset=UTF-8
On Wed, Apr 1, 2015 at 1:49 PM, Roland Bock <rbock@eudoxos.de> wrote:
> On 2015-04-01 21:06, Richard Smith wrote:
>
> On Tue, Mar 31, 2015 at 11:11 PM, Roland Bock <rbock@eudoxos.de> wrote:
>
>> On 2015-03-31 22:57, Richard Smith wrote:
>>
>> On Tue, Mar 31, 2015 at 12:58 PM, Alex B <devalexb@gmail.com> wrote:
>>
>>> I'm not sure if the idea floated around, but why not use some kind of
>>> compile time string instead of backticks or the *name* keyword?
>>>
>>> template <typename T, __CompileTimeString s>
>>> struct X
>>> {
>>> T __name(s);
>>> };
>>>
>>> X<int, "value"> var;
>>> var.value = 0;
>>>
>>>
>>>
>>> What __CompileTimeString precisely is would be to determine (are there
>>> any proposals about compile-time strings in the reflection group?).
>>> Operator *__name* (bikeshed) would convert a compile time string to an
>>> actual name.
>>>
>>> Combine this + compile time strings + other cool reflection features and
>>> we get something really powerful.
>>>
>>
>> A name (or rather, an unqualified-id) is not a string.
>>
>> Agreed, although I think that a name should be convertible to some kind
>> of string.
>>
>> Consider, for instance, the name 'operator int', which should
>> presumably be the same name as 'operator T' if T is a typedef for 'int'.
>>
>>
>> Depends on where you look, right?
>>
>
> No, I don't think it should, and I don't think it can. The translation
> from the token sequence to a name should be performed where the name
> lexically appears.
>
>
>> template<typename T, std::name X>
>> struct foo
>> {
>> $X();
>> };
>>
>> struct bar
>> {
>> using T = int;
>> using A = foo<int, `operator T`>;
>> using B = foo<float, `operator T`>;
>>
>
> Both these references to T should find the T declared just above, that
> is, 'int'.
>
> That sounds wrong to me. Here's another example:
>
> template<typename T1, typename T2, std::name N1, std::name N2>
> struct named_pair
> {
> T1 N1;
> T2 N2;
> };
>
> struct sample
> {
> using A = int;
> using B = float;
> using C = named_pair<char, char, `A`, `B`>;
> };
> using D = named_pair<char, char, `A`, `B`>;
>
> If I understand you correctly, since A and B are defined in sample, you
> would interpret them as `int` and `float`, which would lead to a compile
> error for C, while D is OK?
>
No. Look at [basic]p8:
"Two names are the same if
-- they are identifiers composed of the same character sequence, or
[...]
-- they are conversion-function-ids formed with the same type, or
[...]"
When an identifier is used as a name, the meaning of that name is
determined by the sequence of characters in the identifier, so `A` should
not be resolved to a type (how could it? a type's not a name).
When a conversion-function-id is used as a name, the meaning of that name
is determined by the identity of the type, and doesn't depend on how the
type is spelled. So `operator A` should be resolved to `operator int` and
would be the same name as any other way of spelling that name.
> It would mean that named_pair<char, char, `A`, `B`> could mean different
> things depending on the scope it is used in?
>
>
> If not, it's not possible to form a name representing a conversion
> operator to some local type, or template type parameter, or similar.
>
> I wonder whether this is a real use case? I am asking because I have no
> idea yet how I would use `operator T`?
>
> template<typename T, std::name X>
> struct sample
> {
> X() {/* What goes here? */}
> };
>
>
> And consider
>
> `operator T::U<V>`
>
> We need to know whether T::U is a template to be able to parse this sort
> of thing, which means we should bind it early.
>
>
> Assuming my interpretation, using this would imply a bunch of requirements
> for the template and/or other template parameters, but that is nothing new,
> is it?
>
> using X = foo<`operator T::U<V>`>;
>
> For this to compile, foo has to have a type T such that T::U<V> makes
> sense. But that's ok, I'd say.
>
>
> Best,
>
> Roland
>
> --
>
> ---
> 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
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c24a16bd60b10512b071da
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 W=
ed, Apr 1, 2015 at 1:49 PM, Roland Bock <span dir=3D"ltr"><<a href=3D"ma=
ilto:rbock@eudoxos.de" target=3D"_blank">rbock@eudoxos.de</a>></span> wr=
ote:<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">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF"><div><div class=3D"h5">
<div>On 2015-04-01 21:06, Richard Smith
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Tue, Mar 31, 2015 at 11:11 PM,
Roland Bock <span dir=3D"ltr"><<a href=3D"mailto:rbock@eudox=
os.de" target=3D"_blank">rbock@eudoxos.de</a>></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">
<div text=3D"#000000" bgcolor=3D"#FFFFFF"><span>
<div>On 2015-03-31 22:57, Richard Smith wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Tue, Mar 31, 2015 at
12:58 PM, Alex B <span dir=3D"ltr"><<a href=3D=
"mailto:devalexb@gmail.com" target=3D"_blank">devalexb@gmail.com</a>></s=
pan>
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">
<div dir=3D"ltr">
<div>I'm not sure if the idea floated
around, but why not use some kind of
compile time string instead of backticks
or the <strong>name</strong> keyword?</div>
<div>=C2=A0</div>
<div style=3D"border:1px solid rgb(187,187,18=
7);background-color:rgb(250,250,250)"><code>
<div><span style=3D"color:rgb(0,0,136)">t=
emplate</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color=
:rgb(102,102,0)"><</span><span style=3D"color:rgb(0,0,136)">typename</sp=
an><span style=3D"color:rgb(0,0,0)"> T</span><span style=3D"color:rgb(102,1=
02,0)">,</span><span style=3D"color:rgb(0,0,0)">
__CompileTimeString s</span><span sty=
le=3D"color:rgb(102,102,0)">></span><span style=3D"color:rgb(0,0,0)"><br=
>
</span><span style=3D"color:rgb(0,0,136=
)">struct</span><span style=3D"color:rgb(0,0,0)"> X<br>
</span><span style=3D"color:rgb(102,102=
,0)">{</span><span style=3D"color:rgb(0,0,0)"><br>
=C2=A0 =C2=A0T __name</span><span sty=
le=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,0)">s</spa=
n><span style=3D"color:rgb(102,102,0)">);</span><span style=3D"color:rgb(0,=
0,0)"><br>
</span><span style=3D"color:rgb(102,102=
,0)">};</span><span style=3D"color:rgb(0,0,0)"><br>
=C2=A0<br>
X</span><span style=3D"color:rgb(102,=
102,0)"><</span><span style=3D"color:rgb(0,0,136)">int</span><span style=
=3D"color:rgb(102,102,0)">,</span><span style=3D"color:rgb(0,0,0)"> </span>=
<span style=3D"color:rgb(0,136,0)">"value"</span><span style=3D"c=
olor:rgb(102,102,0)">></span><span style=3D"color:rgb(0,0,0)"> </span><s=
pan style=3D"color:rgb(0,0,136)">var</span><span style=3D"color:rgb(102,102=
,0)">;</span><span style=3D"color:rgb(0,0,0)"><br>
</span><span style=3D"color:rgb(0,0,136=
)">var</span><span style=3D"color:rgb(102,102,0)">.</span><span style=3D"co=
lor:rgb(0,0,0)">value </span><span style=3D"color:rgb(102,102,0)">=3D</span=
><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,102,10=
2)">0</span><span style=3D"color:rgb(102,102,0)">;</span></div>
</code></div>
<div><br>
</div>
<div>=C2=A0</div>
<div>=C2=A0</div>
<div>What __CompileTimeString precisely is
would be to determine (are there any
proposals about compile-time strings in
the reflection group?).</div>
<div>Operator <strong>__name</strong>
(bikeshed) would convert a compile time
string to an actual name.</div>
<div>=C2=A0</div>
<div>Combine this + compile time strings +
other cool reflection features and we
get something really powerful.</div>
</div>
</blockquote>
<div><br>
</div>
<div>A name (or rather, an unqualified-id) is
not a string.</div>
</div>
</div>
</div>
</blockquote>
</span> Agreed, although I think that a name should be
convertible to some kind of string.<span><br>
<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div>Consider, for instance, the name
'operator int', which should presumably=
be
the same name as 'operator T' if T is a
typedef for 'int'.</div>
<div>=C2=A0</div>
</div>
</div>
</div>
</blockquote>
</span> Depends on where you look, right?<br>
</div>
</blockquote>
<div><br>
</div>
<div>No, I don't think it should, and I don't think it =
can.
The translation from the token sequence to a name should
be performed where the name lexically appears.</div>
<div>=C2=A0</div>
<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">
<div text=3D"#000000" bgcolor=3D"#FFFFFF"> <tt>template<ty=
pename
T, std::name X></tt><tt><br>
</tt><tt>struct foo</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 $X();</tt><tt><br>
</tt><tt>};</tt><tt><br>
</tt><tt><br>
</tt><tt>struct bar</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 using T =3D int;</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 using A =3D foo<int, =C2=A0 `opera=
tor T`>;</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 using B =3D foo<float, `operator T=
`>;</tt></div>
</blockquote>
<div><br>
</div>
<div>Both these references to T should find the T declared
just above, that is, 'int'. </div>
</div>
</div>
</div>
</blockquote></div></div>
That sounds wrong to me. Here's another example:<br>
<br>
<tt>template<typename T1, typename T2, std::name N1, std::name
N2></tt><span class=3D""><tt><br>
</tt><tt>struct named_pair</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 T1 N1;</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 T2 N2;</tt><tt><br>
</tt></span><tt>};</tt><tt><br>
</tt><tt><br>
</tt><tt>struct sample</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0 using A =3D int;</tt><tt><br>
</tt><tt>=C2=A0 using B =3D float;</tt><tt><br>
</tt><tt>=C2=A0 using C =3D named_pair<char, char, `A`, `B`>;</tt=
><tt><br>
</tt><tt>};</tt><tt><br>
</tt><tt>using D =3D named_pair<char, char, `A`, `B`>;</tt><br>
<br>
If I understand you correctly, since A and B are defined in sample,
you would interpret them as `int` and `float`, which would lead to a
compile error for C, while D is OK?<br></div></blockquote><div><br></di=
v><div>No. Look at [basic]p8:</div><div><br></div><div>"Two names are =
the same if</div><div>-- =C2=A0they are identifiers composed of the same ch=
aracter sequence, or</div><div>[...]</div><div>-- they are conversion-funct=
ion-ids formed with the same type, or</div><div>[...]"</div><div><br><=
/div><div>When an identifier is used as a name, the meaning of that name is=
determined by the sequence of characters in the identifier, so `A` should =
not be resolved to a type (how could it? a type's not a name).</div><di=
v><br></div><div>When a conversion-function-id is used as a name, the meani=
ng of that name is determined by the identity of the type, and doesn't =
depend on how the type is spelled. So `operator A` should be resolved to `o=
perator int` and would be the same name as any other way of spelling that n=
ame.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204=
);border-left-style:solid;padding-left:1ex"><div text=3D"#000000" bgcolor=
=3D"#FFFFFF">
It would mean that <tt>named_pair<char, char, `A`, `B`></tt>
could mean different things depending on the scope it is used in?<span =
class=3D""><br>
<br>
<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div>If not, it's not possible to form a name representing =
a
conversion operator to some local type, or template type
parameter, or similar. </div>
</div>
</div>
</div>
</blockquote></span>
I wonder whether this is a real use case? I am asking because I have
no idea yet how I would use `operator T`?<span class=3D""><br>
<br>
<tt>template<typename T, std::name X></tt><tt><br>
</tt></span><tt>struct sample</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 X() {/* What goes here? */}</tt><tt><br>
</tt><tt>};</tt><span class=3D""><br>
<br>
<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div>And consider</div>
<div><br>
</div>
<div>=C2=A0 `operator T::U<V>`</div>
<div><br>
</div>
<div>We need to know whether T::U is a template to be able
to parse this sort of thing, which means we should bind it
early.</div>
</div>
</div>
</div>
</blockquote>
<br></span>
Assuming my interpretation, using this would imply a bunch of
requirements for the template and/or other template parameters, but
that is nothing new, is it?<br>
<br>
<tt>using X =3D foo<`operator T::U<V>`>;</tt><br>
<br>
For this to compile, foo has to have a type <tt>T</tt> such that <tt>T:=
:U<V></tt>
makes sense. But that's ok, I'd say.<br>
<br>
<br>
Best,<br>
<br>
Roland<br>
</div><div class=3D""><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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" target=3D"_=
blank">std-proposals+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></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--001a11c24a16bd60b10512b071da--
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Thu, 02 Apr 2015 07:31:10 +0200
Raw View
This is a multi-part message in MIME format.
--------------020200030304050302080307
Content-Type: text/plain; charset=UTF-8
On 2015-04-01 23:31, Richard Smith wrote:
> On Wed, Apr 1, 2015 at 1:49 PM, Roland Bock <rbock@eudoxos.de
> <mailto:rbock@eudoxos.de>> wrote:
>
> On 2015-04-01 21:06, Richard Smith wrote:
>> On Tue, Mar 31, 2015 at 11:11 PM, Roland Bock <rbock@eudoxos.de
>> <mailto:rbock@eudoxos.de>> wrote:
>>
>> On 2015-03-31 22:57, Richard Smith wrote:
>>> On Tue, Mar 31, 2015 at 12:58 PM, Alex B <devalexb@gmail.com
>>> <mailto:devalexb@gmail.com>> wrote:
>>>
>>> I'm not sure if the idea floated around, but why not use
>>> some kind of compile time string instead of backticks or
>>> the *name* keyword?
>>>
>>> |
>>> template<typenameT,__CompileTimeString s>
>>> structX
>>> {
>>> T __name(s);
>>> };
>>>
>>> X<int,"value">var;
>>> var.value =0;
>>> |
>>>
>>>
>>>
>>> What __CompileTimeString precisely is would be to
>>> determine (are there any proposals about compile-time
>>> strings in the reflection group?).
>>> Operator *__name* (bikeshed) would convert a compile
>>> time string to an actual name.
>>>
>>> Combine this + compile time strings + other cool
>>> reflection features and we get something really powerful.
>>>
>>>
>>> A name (or rather, an unqualified-id) is not a string.
>> Agreed, although I think that a name should be convertible to
>> some kind of string.
>>
>>> Consider, for instance, the name 'operator int', which
>>> should presumably be the same name as 'operator T' if T is a
>>> typedef for 'int'.
>>>
>> Depends on where you look, right?
>>
>>
>> No, I don't think it should, and I don't think it can. The
>> translation from the token sequence to a name should be performed
>> where the name lexically appears.
>>
>>
>> template<typename T, std::name X>
>> struct foo
>> {
>> $X();
>> };
>>
>> struct bar
>> {
>> using T = int;
>> using A = foo<int, `operator T`>;
>> using B = foo<float, `operator T`>;
>>
>>
>> Both these references to T should find the T declared just above,
>> that is, 'int'.
> That sounds wrong to me. Here's another example:
>
> template<typename T1, typename T2, std::name N1, std::name N2>
> struct named_pair
> {
> T1 N1;
> T2 N2;
> };
>
> struct sample
> {
> using A = int;
> using B = float;
> using C = named_pair<char, char, `A`, `B`>;
> };
> using D = named_pair<char, char, `A`, `B`>;
>
> If I understand you correctly, since A and B are defined in
> sample, you would interpret them as `int` and `float`, which would
> lead to a compile error for C, while D is OK?
>
>
> No. Look at [basic]p8:
>
> "Two names are the same if
> -- they are identifiers composed of the same character sequence, or
> [...]
> -- they are conversion-function-ids formed with the same type, or
> [...]"
>
> When an identifier is used as a name, the meaning of that name is
> determined by the sequence of characters in the identifier, so `A`
> should not be resolved to a type (how could it? a type's not a name).
>
> When a conversion-function-id is used as a name, the meaning of that
> name is determined by the identity of the type, and doesn't depend on
> how the type is spelled. So `operator A` should be resolved to
> `operator int` and would be the same name as any other way of spelling
> that name.
Ah, got it.
Thanks for the reference and the explanation :-)
Now that I read your mail and the respective section of the standard, it
seems quite obvious...
Best,
Roland
--
---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
--------------020200030304050302080307
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">On 2015-04-01 23:31, Richard Smith
wrote:<br>
</div>
<blockquote
cite=3D"mid:CAOfiQq=3DSsC7MTP9c1OK96zW8FoEJH+r5XLhXTVcHzOhh7Ef_6Q@mail.gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Wed, Apr 1, 2015 at 1:49 PM,
Roland Bock <span dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:rbock@eudoxos.de" target=3D"_blank">rbock@eu=
doxos.de</a>></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">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>
<div class=3D"h5">
<div>On 2015-04-01 21:06, Richard Smith wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Tue, Mar 31, 2015
at 11:11 PM, Roland Bock <span dir=3D"ltr"><=
<a
moz-do-not-send=3D"true"
href=3D"mailto:rbock@eudoxos.de"
target=3D"_blank">rbock@eudoxos.de</a>><=
/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">
<div text=3D"#000000" bgcolor=3D"#FFFFFF"><sp=
an>
<div>On 2015-03-31 22:57, Richard
Smith wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Tue,
Mar 31, 2015 at 12:58 PM, Alex
B <span dir=3D"ltr"><<a
moz-do-not-send=3D"true"
href=3D"mailto:devalexb@gmail=
..com"
target=3D"_blank">devalexb@gm=
ail.com</a>></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">
<div dir=3D"ltr">
<div>I'm not sure if the
idea floated around, but
why not use some kind of
compile time string
instead of backticks or
the <strong>name</strong>
keyword?</div>
<div>=C2=A0</div>
<div style=3D"border:1px
solid
rgb(187,187,187);background=
-color:rgb(250,250,250)"><code>
<div><span
style=3D"color:rgb(0,=
0,136)">template</span><span
style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)"><=
;</span><span
style=3D"color:rgb(0,0,136)">typename</span><span style=3D"color:rgb(0,0,0)=
">
T</span><span
style=3D"color:rgb(10=
2,102,0)">,</span><span
style=3D"color:rgb(0,0,0)"> __CompileTimeString s</span><span
style=3D"color:rgb(10=
2,102,0)">></span><span
style=3D"color:rgb(0,0,0)"><br>
</span><span
style=3D"color:rgb(0,=
0,136)">struct</span><span
style=3D"color:rgb(0,0,0)"> X<br>
</span><span
style=3D"color:rgb(10=
2,102,0)">{</span><span
style=3D"color:rgb(0,0,0)"><br>
=C2=A0 =C2=A0T __name=
</span><span
style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,0)">s</=
span><span
style=3D"color:rgb(102,102,0)">);</span><span style=3D"color:rgb(0,0,0)"><b=
r>
</span><span
style=3D"color:rgb(10=
2,102,0)">};</span><span
style=3D"color:rgb(0,0,0)"><br>
=C2=A0<br>
X</span><span
style=3D"color:rgb(10=
2,102,0)"><</span><span
style=3D"color:rgb(0,0,136)">int</span><span style=3D"color:rgb(102,102,0)"=
>,</span><span
style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,136,0)">"valu=
e"</span><span
style=3D"color:rgb(102,102,0)">></span><span style=3D"color:rgb(0,0,0)">
</span><span
style=3D"color:rgb(0,=
0,136)">var</span><span
style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br=
>
</span><span
style=3D"color:rgb(0,=
0,136)">var</span><span
style=3D"color:rgb(102,102,0)">.</span><span style=3D"color:rgb(0,0,0)">val=
ue
</span><span
style=3D"color:rgb(10=
2,102,0)">=3D</span><span
style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,102,102)">0</=
span><span
style=3D"color:rgb(102,102,0)">;</span></div>
</code></div>
<div><br>
</div>
<div>=C2=A0</div>
<div>=C2=A0</div>
<div>What
__CompileTimeString
precisely is would be to
determine (are there any
proposals about
compile-time strings in
the reflection group?).</di=
v>
<div>Operator <strong>__name<=
/strong>
(bikeshed) would convert
a compile time string to
an actual name.</div>
<div>=C2=A0</div>
<div>Combine this +
compile time strings +
other cool reflection
features and we get
something really
powerful.</div>
</div>
</blockquote>
<div><br>
</div>
<div>A name (or rather, an
unqualified-id) is not a
string.</div>
</div>
</div>
</div>
</blockquote>
</span> Agreed, although I think that a
name should be convertible to some kind
of string.<span><br>
<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div>Consider, for instance,
the name 'operator int',
which should presumably be
the same name as 'operator
T' if T is a typedef for
'int'.</div>
<div>=C2=A0</div>
</div>
</div>
</div>
</blockquote>
</span> Depends on where you look,
right?<br>
</div>
</blockquote>
<div><br>
</div>
<div>No, I don't think it should, and I
don't think it can. The translation from
the token sequence to a name should be
performed where the name lexically
appears.</div>
<div>=C2=A0</div>
<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">
<div text=3D"#000000" bgcolor=3D"#FFFFFF"> <t=
t>template<typename
T, std::name X></tt><tt><br>
</tt><tt>struct foo</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 $X();</tt><tt><br>
</tt><tt>};</tt><tt><br>
</tt><tt><br>
</tt><tt>struct bar</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 using T =3D int;</tt>=
<tt><br>
</tt><tt>=C2=A0=C2=A0 using A =3D foo<in=
t, =C2=A0
`operator T`>;</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 using B =3D foo<fl=
oat,
`operator T`>;</tt></div>
</blockquote>
<div><br>
</div>
<div>Both these references to T should find
the T declared just above, that is, 'int'.
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
That sounds wrong to me. Here's another example:<br>
<br>
<tt>template<typename T1, typename T2, std::name N1,
std::name N2></tt><span class=3D""><tt><br>
</tt><tt>struct named_pair</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 T1 N1;</tt><tt><br>
</tt><tt>=C2=A0=C2=A0 T2 N2;</tt><tt><br>
</tt></span><tt>};</tt><tt><br>
</tt><tt><br>
</tt><tt>struct sample</tt><tt><br>
</tt><tt>{</tt><tt><br>
</tt><tt>=C2=A0 using A =3D int;</tt><tt><br>
</tt><tt>=C2=A0 using B =3D float;</tt><tt><br>
</tt><tt>=C2=A0 using C =3D named_pair<char, char, `A`,
`B`>;</tt><tt><br>
</tt><tt>};</tt><tt><br>
</tt><tt>using D =3D named_pair<char, char, `A`,
`B`>;</tt><br>
<br>
If I understand you correctly, since A and B are defined
in sample, you would interpret them as `int` and
`float`, which would lead to a compile error for C,
while D is OK?<br>
</div>
</blockquote>
<div><br>
</div>
<div>No. Look at [basic]p8:</div>
<div><br>
</div>
<div>"Two names are the same if</div>
<div>-- =C2=A0they are identifiers composed of the same charact=
er
sequence, or</div>
<div>[...]</div>
<div>-- they are conversion-function-ids formed with the
same type, or</div>
<div>[...]"</div>
<div><br>
</div>
<div>When an identifier is used as a name, the meaning of
that name is determined by the sequence of characters in
the identifier, so `A` should not be resolved to a type
(how could it? a type's not a name).</div>
<div><br>
</div>
<div>When a conversion-function-id is used as a name, the
meaning of that name is determined by the identity of the
type, and doesn't depend on how the type is spelled. So
`operator A` should be resolved to `operator int` and
would be the same name as any other way of spelling that
name.</div>
</div>
</div>
</div>
</blockquote>
<br>
Ah, got it.<br>
Thanks for the reference and the explanation :-)<br>
<br>
Now that I read your mail and the respective section of the
standard, it seems quite obvious...<br>
<br>
Best,<br>
<br>
Roland<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" 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 />
--------------020200030304050302080307--
.