Topic: enumeration pack and `__enumerator__`
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 29 Sep 2013 00:45:55 +0300
Raw View
--001a11c25b4817a62d04e7788791
Content-Type: text/plain; charset=ISO-8859-1
On 28 September 2013 23:10, Christian Kaeser <
christiankaeser87@googlemail.com> wrote:
>
> Does anyone know anything further about SG7, the reflection study group?
> The forum on here seems to be empty, and not a lot of proposals have been
> put forth for quite a while now. I would be very interested in a discussion
> about concrete, low-hanging-fruit reflection aspects that could hopefully
> be ready for the C++17 timeline.
>
>
>
>
SG7 met in Chicago yesterday, and the forum now accepts subscription
requests, so it's quite likely
that it won't stay empty for long. There's a handful of proposals, and
there's more to come.
--
---
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/.
--001a11c25b4817a62d04e7788791
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 28 September 2013 23:10, Christian Kaeser <span dir=3D"ltr"><=
<a href=3D"mailto:christiankaeser87@googlemail.com" target=3D"_blank">chris=
tiankaeser87@googlemail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>Does anyone know anythi=
ng further about SG7, the reflection study group? The forum on here seems t=
o be empty, and not a lot of proposals have been put forth for quite a whil=
e now. I would be very interested in a discussion about concrete, low-hangi=
ng-fruit reflection aspects that could hopefully be ready for the C++17 tim=
eline.<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
<br><br></div></div></blockquote><div><br></div><div>SG7 met in Chicago yes=
terday, and the forum now accepts subscription requests, so it's quite =
likely<br>that it won't stay empty for long. There's a handful of p=
roposals, and there's more to come.<br>
</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--001a11c25b4817a62d04e7788791--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 29 Sep 2013 01:11:27 +0300
Raw View
--089e011779b564eaad04e778e2d0
Content-Type: text/plain; charset=ISO-8859-1
On 29 September 2013 00:45, Ville Voutilainen
<ville.voutilainen@gmail.com>wrote:
>
>
>
> On 28 September 2013 23:10, Christian Kaeser <
> christiankaeser87@googlemail.com> wrote:
>
>>
>> Does anyone know anything further about SG7, the reflection study group?
>> The forum on here seems to be empty, and not a lot of proposals have been
>> put forth for quite a while now. I would be very interested in a discussion
>> about concrete, low-hanging-fruit reflection aspects that could hopefully
>> be ready for the C++17 timeline.
>>
>>
>>
>>
> SG7 met in Chicago yesterday, and the forum now accepts subscription
> requests, so it's quite likely
> that it won't stay empty for long. There's a handful of proposals, and
> there's more to come.
>
>
I should probably also mention that there's supposed to be a call for
papers in the post-Chicago
mailing, and that CfP should include some direction about the scope and the
plans forward,
outlining what SG7 will be interested in doing and in what order.
--
---
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/.
--089e011779b564eaad04e778e2d0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 29 September 2013 00:45, Ville Voutilainen <span dir=3D"ltr"><=
;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.vou=
tilainen@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote"><div class=3D"im">On 28 September 20=
13 23:10, Christian Kaeser <span dir=3D"ltr"><<a href=3D"mailto:christia=
nkaeser87@googlemail.com" target=3D"_blank">christiankaeser87@googlemail.co=
m</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>Does anyone know anythi=
ng further about SG7, the reflection study group? The forum on here seems t=
o be empty, and not a lot of proposals have been put forth for quite a whil=
e now. I would be very interested in a discussion about concrete, low-hangi=
ng-fruit reflection aspects that could hopefully be ready for the C++17 tim=
eline.<br>
</div><div><div>
<p></p>
<br><br></div></div></blockquote><div><br></div></div><div>SG7 met in Chica=
go yesterday, and the forum now accepts subscription requests, so it's =
quite likely<br>that it won't stay empty for long. There's a handfu=
l of proposals, and there's more to come.<br>
</div></div><br></div></div>
</blockquote></div><br></div><div class=3D"gmail_extra">I should probably a=
lso mention that there's supposed to be a call for papers in the post-C=
hicago<br>mailing, and that CfP should include some direction about the sco=
pe and the plans forward,<br>
</div><div class=3D"gmail_extra">outlining what SG7 will be interested in d=
oing and in what order.<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--089e011779b564eaad04e778e2d0--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 29 Sep 2013 11:29:41 -0700
Raw View
On domingo, 29 de setembro de 2013 07:33:30, Andrew Tomazos wrote:
> static constexpr const char* names[];
Arrays of pointers implies relocations. You may want to avoid this.
--
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: Christian Kaeser <christiankaeser87@googlemail.com>
Date: Sun, 29 Sep 2013 12:05:24 -0700 (PDT)
Raw View
------=_Part_67_22232760.1380481525878
Content-Type: text/plain; charset=ISO-8859-1
Now I remember once reading a post on your blog about the topic, very
interesting stuff:
http://www.macieira.org/blog/2011/07/table-driven-methods-with-no-relocations/
To allow implementations to optimize for fewer relocations, maybe a better
interface would indeed be to provide functions instead of an array, as just
suggested by Andrew before.
So static constexpr const char* name(size_t index);
Or, should string_view be ready in time: static constexpr string_view
name(size_t index);
On Sunday, 29 September 2013 20:29:41 UTC+2, Thiago Macieira wrote:
>
> On domingo, 29 de setembro de 2013 07:33:30, Andrew Tomazos wrote:
> > static constexpr const char* names[];
>
> Arrays of pointers implies relocations. You may want to avoid this.
>
> --
> 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/.
------=_Part_67_22232760.1380481525878
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Now I remember once reading a post on your blog about the =
topic, very interesting stuff: http://www.macieira.org/blog/2011/07/table-d=
riven-methods-with-no-relocations/<br><br>To allow implementations to optim=
ize for fewer relocations, maybe a better interface would indeed be to prov=
ide functions instead of an array, as just suggested by Andrew before.<br><=
br>So <span style=3D"font-family:courier new,monospace">static conste=
xpr const char* name(size_t index);<br><span style=3D"font-family: arial,sa=
ns-serif;">Or, should string_view be ready in time: </span></span><span sty=
le=3D"font-family:courier new,monospace">static constexpr string_view name(=
size_t index);</span><br><br><br>On Sunday, 29 September 2013 20:29:41 UTC+=
2, Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On d=
omingo, 29 de setembro de 2013 07:33:30, Andrew Tomazos wrote:
<br>> static constexpr const c=
har* names[];
<br>
<br>Arrays of pointers implies relocations. You may want to avoid this.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" targ=
et=3D"_blank">kde.org</a>
<br> Software Architect - Intel Open Source Technology Center
<br> PGP/GPG: 0x6EF45358; fingerprint:
<br> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4=
5358
<br>
<br></blockquote><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_67_22232760.1380481525878--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 29 Sep 2013 13:17:18 -0700
Raw View
On domingo, 29 de setembro de 2013 12:05:24, Christian Kaeser wrote:
> Now I remember once reading a post on your blog about the topic, very
> interesting stuff:
> http://www.macieira.org/blog/2011/07/table-driven-methods-with-no-relocation
> s/
>
> To allow implementations to optimize for fewer relocations, maybe a better
> interface would indeed be to provide functions instead of an array, as just
> suggested by Andrew before.
>
> So static constexpr const char* name(size_t index);
> Or, should string_view be ready in time: static constexpr string_view
> name(size_t index);
I'd go for simple const char*. Don't make it more complex unless you have to.
And string_view wouldn't work: as discussed in the other thread, it needs to
point to an existing std::string that won't be destroyed too soon. Where would
that string be? What is its lifetime? If it's static, are you asking that the
compiler know about the layout of a std::string?
So, yeah, don't make it too complex :-)
--
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: Christian Kaeser <christiankaeser87@googlemail.com>
Date: Sun, 29 Sep 2013 13:34:57 -0700 (PDT)
Raw View
------=_Part_354_22569819.1380486897423
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, 29 September 2013 22:17:18 UTC+2, Thiago Macieira wrote:
>
> On domingo, 29 de setembro de 2013 12:05:24, Christian Kaeser wrote:
> > Now I remember once reading a post on your blog about the topic, very
> > interesting stuff:
> >
> http://www.macieira.org/blog/2011/07/table-driven-methods-with-no-relocation
> > s/
> >
> > To allow implementations to optimize for fewer relocations, maybe a
> better
> > interface would indeed be to provide functions instead of an array, as
> just
> > suggested by Andrew before.
> >
> > So static constexpr const char* name(size_t index);
> > Or, should string_view be ready in time: static constexpr string_view
> > name(size_t index);
>
> I'd go for simple const char*. Don't make it more complex unless you have
> to.
>
> And string_view wouldn't work: as discussed in the other thread, it needs
> to
> point to an existing std::string that won't be destroyed too soon. Where
> would
> that string be? What is its lifetime? If it's static, are you asking that
> the
> compiler know about the layout of a std::string?
>
> So, yeah, don't make it too complex :-)
>
> --
> 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
>
>
As far as my understanding goes, string_view does not require a string to
point to. It's just a pair of pointers to const char.
This constructor from N3762 could be easily used by the implementation for
this case:
constexpr basic_string_view(const charT* str, size_type len);
The advantage of string_view would be that the length information isn't
lost, something I personally would find nice to have. Of course, too much
complexity is not desirable, but in this case I would argue that
string_view even reduces the complexity - for the end user.
--
---
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_354_22569819.1380486897423
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Sunday, 29 September 2013 22:17:18 UTC+2, Thiag=
o Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On domingo, =
29 de setembro de 2013 12:05:24, Christian Kaeser wrote:
<br>> Now I remember once reading a post on your blog about the topic, v=
ery=20
<br>> interesting stuff:=20
<br>> <a href=3D"http://www.macieira.org/blog/2011/07/table-driven-metho=
ds-with-no-relocation" target=3D"_blank">http://www.macieira.org/blog/<wbr>=
2011/07/table-driven-methods-<wbr>with-no-relocation</a>
<br>> s/
<br>>=20
<br>> To allow implementations to optimize for fewer relocations, maybe =
a better=20
<br>> interface would indeed be to provide functions instead of an array=
, as just=20
<br>> suggested by Andrew before.
<br>>=20
<br>> So static constexpr const char* name(size_t index);
<br>> Or, should string_view be ready in time: static constexpr string_v=
iew=20
<br>> name(size_t index);
<br>
<br>I'd go for simple const char*. Don't make it more complex unless you ha=
ve to.
<br>
<br>And string_view wouldn't work: as discussed in the other thread, it nee=
ds to=20
<br>point to an existing std::string that won't be destroyed too soon. Wher=
e would=20
<br>that string be? What is its lifetime? If it's static, are you asking th=
at the=20
<br>compiler know about the layout of a std::string?
<br>
<br>So, yeah, don't make it too complex :-)
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" targ=
et=3D"_blank">kde.org</a>
<br> Software Architect - Intel Open Source Technology Center
<br> PGP/GPG: 0x6EF45358; fingerprint:
<br> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4=
5358
<br>
<br></blockquote><div><br><br>As far as my understanding goes, <span style=
=3D"font-family: courier new,monospace;">string_view</span> does not requir=
e a <span style=3D"font-family: courier new,monospace;">string </span>to po=
int to. It's just a pair of pointers to const char.<br>This constructor fro=
m N3762 could be easily used by the implementation for this case:<br><span =
style=3D"font-family: courier new,monospace;">constexpr basic_string_view(c=
onst charT* str, size_type len);</span><br><br>The advantage of string_view=
would be that the length information isn't lost, something I personally wo=
uld find nice to have. Of course, too much complexity is not desirable, but=
in this case I would argue that string_view even reduces the complexity - =
for the end user.<br><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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_354_22569819.1380486897423--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 29 Sep 2013 14:24:39 -0700
Raw View
On domingo, 29 de setembro de 2013 13:34:57, Christian Kaeser wrote:
> As far as my understanding goes, string_view does not require a string to
> point to. It's just a pair of pointers to const char.
> This constructor from N3762 could be easily used by the implementation for
> this case:
> constexpr basic_string_view(const charT* str, size_type len);
>
> The advantage of string_view would be that the length information isn't
> lost, something I personally would find nice to have. Of course, too much
> complexity is not desirable, but in this case I would argue that
> string_view even reduces the complexity - for the end user.
From my own uses and those of Qt, I'd like to request that this type of low-
level functionality that are technically part of the language itself (just
like <type_traits>, <new> and <initializer_list>) not use the more complex
container classes.
In any case, since the character data is a literal (the function is constexpr,
remember?), the compiler is also able to optimise strlen() out of existence.
--
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: David Krauss <potswa@gmail.com>
Date: Mon, 30 Sep 2013 13:10:23 +0800
Raw View
On 9/29/13 7:28 PM, Christian Kaeser wrote:
> You are correct, I first thought the original proposition was "enum types
> are implicitly parameter packs", which of course would create lots of
> problems. If really only "enum-name ..." would be allowed (e.g. the
> ellipsis has to follow the type-name directly), I would find the
> similarities/differences this (very) special case would have to regular
> parameter packs quite problematic/limiting/hard to teach.
>
> As for David Krauss's proposal, this seems interesting, but again (like
> nearly any language change) is bound to have a lot of problematic corner
> cases. Take this example:
>
> template<class T, T... Ts>
> void problematic() { std::cout << "1"; }
>
> template<class T, class U>
> void problematic() { std::cout << "2"; }
>
> Currently, there is no ambiguity when called this way:
>
> enum Enum {};
> problematic<Enum, Enum>();
>
> But what would happen with the new proposed way of implicit expansion?
Yes, I was aware of this when I made the suggestion. I don't think it's=20
significant. There's a long way between this specific example and "lots=20
of problems."
I think it's more important that the ellipsis work consistently.
> Even without this specific problem, I find such an implicit conversion
> (from a type into a value-parameter-list)
Conversions are something else.
> very surprising and therefore
> problematic. In my opinion, such a big, "magical" feature needs to be way
> more explicit. Why not expose such functionality only through the standar=
d
> library? This way all the trouble of a core language change is also avoid=
ed.
Contextual dependence of the precedence of the ellipsis is also quite=20
subtly surprising. Which is easier to annotate with a comment:
A. // this type is expanding to its enumerators
B. // this expression must be kept inside a (meta)function because the=20
ellipsis has odd precedence in the context it would need to be used=20
otherwise
I'm not sure how parsers deal with such issues, but it could be quite=20
difficult to build the template AST, or at least hurt diagnostic=20
generation, as before instantiation you don't know whether a type-id=20
without an unexpanded pack can bind to the ellipsis.
template< typename t >
void foo() { return bar< t ... >(); } // C++11 error without instantiating.
// Proposed instantiation error: "non-pack t expanded but not=20
enumeration type."
Explicitness is nice, and the call site ellipsis is more explicit than=20
none, but it's only marginal.
>> The intention of the two primitives is to make it possible for you to=20
>> implement all of these things as library features. Once you have the=20
>> enumerator list as a pack I believe during translation you should be=20
>> able to create "flag sets" or "arrays indexed by an enum" or whatever=20
>> other fruit you may want. You will have statically all the=20
>> information available about the enumerators and their values.=20
> I understand that and have exactly the same goal as you, to see some form
> of enum reflection in the standard. The question of how to get there is o=
f
> course the big one.
One size of end-user interface will not fit all. The suggestions are=20
already going all over the map. The best part of Andrew's proposal is=20
holding to an ideal of metaprogramming tightly integrated with the compiler=
..
The best way to evaluate the solutions is to implement these extensions=20
into mainstream distributions and see what survives in the wild.
> Then given my "enum_data" definition from before the following would hold=
:
> enum_data<E1>::count =3D=3D 3 =3D=3D __enum_value_count(E1) //
> __enumerator_count might be a better name..
> enum_data<E1>::values =3D=3D [ 0, 10, 0 ]
> enum_data<E1>::names =3D=3D [ "e0", "e1", "elast" ]
>
> This is a very low level view of an enumeration, as it keeps the complete
> ordering even of duplicate values in the enum definition. This could not =
be
> reconstructed with your/David Krauss's approach, as a "enum_data" filled
> with your primitives would look like this:
> enum_data<E1>::count =3D=3D 2
> enum_data<E1>::values =3D=3D [ 0, 10 ]
> enum_data<E1>::names =3D=3D [ "e0\0elast\0", "e1\0" ] // or similar?
It's probably better to stick either to arrays or to metafunctions, and=20
avoid mixing interface styles. Neither is more expressive. Obviously a=20
metafunction would work using indexes rather than keys, yet not=20
necessarily be an array under the hood. Given either primitive, you=20
could define a metafunction to retrieve the name of a given key or=20
static_assert an error if it's ambiguous. But it would be O(N) in the=20
number of enumerators.
> I mainly chose my way for implementation as it was trivial to do in clang
> (clang already keeps all defined enumerators in this order) and because I
> wanted to expose as much information as possible for experimenting.
>
> One application I could think of where my interface might be desirable
> would be a graphical/console interface where the user can select the valu=
e
> for an enum out of a list of all options. Here, the original enumerator
> order might be nice to have. Of course, I myself am not totally convinced
> that this is really an important scenario.
The important scenarios that come up relate to serialization: file=20
formats, network protocols, database schemas, etc. You want to be able=20
to verify that names conform to the spec. It would be nice to be able to=20
flag against case-insensitive duplicates in different enumerators at=20
compile time.
I happen to be a metaprogramming freak, but=85 As a policy, reflection=20
interfaces should be highly amenable to all styles and applications of=20
metaprogramming.
--=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: Christian Kaeser <christiankaeser87@googlemail.com>
Date: Mon, 30 Sep 2013 08:48:33 -0700 (PDT)
Raw View
------=_Part_113_10343879.1380556113414
Content-Type: text/plain; charset=ISO-8859-1
On Monday, 30 September 2013 07:10:23 UTC+2, David Krauss wrote:
>
> On 9/29/13 7:28 PM, Christian Kaeser wrote:
> > You are correct, I first thought the original proposition was "enum
> types
> > are implicitly parameter packs", which of course would create lots of
> > problems. If really only "enum-name ..." would be allowed (e.g. the
> > ellipsis has to follow the type-name directly), I would find the
> > similarities/differences this (very) special case would have to regular
> > parameter packs quite problematic/limiting/hard to teach.
> >
> > As for David Krauss's proposal, this seems interesting, but again (like
> > nearly any language change) is bound to have a lot of problematic corner
> > cases. Take this example:
> >
> > template<class T, T... Ts>
> > void problematic() { std::cout << "1"; }
> >
> > template<class T, class U>
> > void problematic() { std::cout << "2"; }
> >
> > Currently, there is no ambiguity when called this way:
> >
> > enum Enum {};
> > problematic<Enum, Enum>();
> >
> > But what would happen with the new proposed way of implicit expansion?
>
> Yes, I was aware of this when I made the suggestion. I don't think it's
> significant. There's a long way between this specific example and "lots
> of problems."
>
> I think it's more important that the ellipsis work consistently.
>
>
I would guess that the committee would find such corner cases significant.
Some behaviour has to be defined for this case, and better one that does
not break currently valid code, if at all possible.
But exactly this kind complexity is why I find this direction - of
introducing a new, very specific language rule that has no benefits except
for this small purpose, and with some "gotchas" for unsuspecting
programmers - rather questionable. The language is complicated enough
already.
I am not opposed to having reflection of enums in the form of a parameter
pack. But maybe it would be better to wait for improved parameter pack
support in the language before pursuing that idea. Mike Spertus's N3728
sounds like it would be an ideal base. With such language functionality,
there could be a simple trait class with magic specializations that exposes
a parameter pack without any new language rules specific for enum
reflection. Plus using the pack would be also simpler then.
> > Even without this specific problem, I find such an implicit conversion
> > (from a type into a value-parameter-list)
>
> Conversions are something else.
>
>
Are they? I might be using the wrong term, but the description does sound
like an implicit conversion from an enum type to a list of enum values
would be happening given the right context (a non-type parameter pack of
that enum type). Btw, would this also work under your proposition?:
enum e { foo, bar, baz };
template<typename E, E ... all_values >
struct enum_size { /* ... */ };
enum_size< e, foo, e >::value; // allowed?
enum_size< e, e, foo >::value; // allowed?
> > very surprising and therefore
> > problematic. In my opinion, such a big, "magical" feature needs to be
> way
> > more explicit. Why not expose such functionality only through the
> standard
> > library? This way all the trouble of a core language change is also
> avoided.
>
> Contextual dependence of the precedence of the ellipsis is also quite
> subtly surprising. Which is easier to annotate with a comment:
> A. // this type is expanding to its enumerators
> B. // this expression must be kept inside a (meta)function because the
> ellipsis has odd precedence in the context it would need to be used
> otherwise
>
> I'm not sure how parsers deal with such issues, but it could be quite
> difficult to build the template AST, or at least hurt diagnostic
> generation, as before instantiation you don't know whether a type-id
> without an unexpanded pack can bind to the ellipsis.
>
> template< typename t >
> void foo() { return bar< t ... >(); } // C++11 error without
> instantiating.
> // Proposed instantiation error: "non-pack t expanded but not
> enumeration type."
>
> Explicitness is nice, and the call site ellipsis is more explicit than
> none, but it's only marginal.
>
>
I am not defending the original proposal by Andrew. I think we all agree
that that is no better/likely solution. But I am arguing against any
language change at all, and just let implementations deal with specializing
some special templates in the std namespace, just like it is successfully
done already with the existing type traits.
> >> The intention of the two primitives is to make it possible for you to
> >> implement all of these things as library features. Once you have the
> >> enumerator list as a pack I believe during translation you should be
> >> able to create "flag sets" or "arrays indexed by an enum" or whatever
> >> other fruit you may want. You will have statically all the
> >> information available about the enumerators and their values.
> > I understand that and have exactly the same goal as you, to see some
> form
> > of enum reflection in the standard. The question of how to get there is
> of
> > course the big one.
>
> One size of end-user interface will not fit all. The suggestions are
> already going all over the map. The best part of Andrew's proposal is
> holding to an ideal of metaprogramming tightly integrated with the
> compiler.
>
>
One interface might fit in so far as other interfaces for specific use
cases could just be synthesized from the one basic standard one, thanks to
constexpr. I agree that this interface should be as low-level as possible,
so no information is discarded and as many applications as possible can be
implemented on top of it.
Does decoupling the interface from the compiler/language a bit really hurt
that much? As I previously mentioned, e.g. type trait's
std::underlying_type<enum-type>::type is simply a wrapper around the
"magic" intrinsic __underlying_type(enum-type) in GCC/clang. I would not
say that the decision to standardize the wrapper changes anything really,
and now I think we should respect this style the standard has chosen.
> The best way to evaluate the solutions is to implement these extensions
> into mainstream distributions and see what survives in the wild.
>
> > Then given my "enum_data" definition from before the following would
> hold:
> > enum_data<E1>::count == 3 == __enum_value_count(E1) //
> > __enumerator_count might be a better name..
> > enum_data<E1>::values == [ 0, 10, 0 ]
> > enum_data<E1>::names == [ "e0", "e1", "elast" ]
> >
> > This is a very low level view of an enumeration, as it keeps the
> complete
> > ordering even of duplicate values in the enum definition. This could not
> be
> > reconstructed with your/David Krauss's approach, as a "enum_data" filled
> > with your primitives would look like this:
> > enum_data<E1>::count == 2
> > enum_data<E1>::values == [ 0, 10 ]
> > enum_data<E1>::names == [ "e0\0elast\0", "e1\0" ] // or similar?
>
> It's probably better to stick either to arrays or to metafunctions, and
> avoid mixing interface styles. Neither is more expressive. Obviously a
> metafunction would work using indexes rather than keys, yet not
> necessarily be an array under the hood. Given either primitive, you
> could define a metafunction to retrieve the name of a given key or
> static_assert an error if it's ambiguous. But it would be O(N) in the
> number of enumerators.
>
>
After the discussion here I also think the function-interface approach is
better than directly accessible arrays. The accessing pattern is more or
less the same, but this way implementations have more room for
optimizations, like the one Thiago brought up.
Value -> enumerator index lookup (during compile- and run-time): while it
can be done in library (efficently, not only in O(N)) with only something
like enumerator_info, I would argue that such an important function should
be provided through the standard interface.
> > I mainly chose my way for implementation as it was trivial to do in
> clang
> > (clang already keeps all defined enumerators in this order) and because
> I
> > wanted to expose as much information as possible for experimenting.
> >
> > One application I could think of where my interface might be desirable
> > would be a graphical/console interface where the user can select the
> value
> > for an enum out of a list of all options. Here, the original enumerator
> > order might be nice to have. Of course, I myself am not totally
> convinced
> > that this is really an important scenario.
>
> The important scenarios that come up relate to serialization: file
> formats, network protocols, database schemas, etc. You want to be able
> to verify that names conform to the spec. It would be nice to be able to
> flag against case-insensitive duplicates in different enumerators at
> compile time.
>
String processing at compile time would be nice. With the new constexpr
relaxations it might be doable I think? At least as long the identifiers
are only ASCII and not full UTF8...
Some applications I have thought about are container classes that take an
enum as their index. This of course is already possible with something like
std::set<enum-type>, but that can't compete with classic C-style flag
enums, e.g.
enum TextStyle {
bold = 1,
italic = 2,
underlined = 4
};
std::bitset would be good for this task, but it requires an index [0 ..
size[ -- which is where the enumerator index would fit in perfectly. That
way, any enum could be made to work as a set without the brittle, C-style
setting of values to the power of 2 or the wasteful std::set approach.
An array being indexed by an enum and holding any type of value would be
done using the same principle also.
But I am very curious to see the call-for-papers Ville has announced.
Knowing the direction the study group is going/interested in should help
focus/motivate discussions such as this 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/.
------=_Part_113_10343879.1380556113414
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, 30 September 2013 07:10:23 UTC+2, David=
Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 9/29/13 7:28=
PM, Christian Kaeser wrote:
<br>> You are correct, I first thought the original proposition was "enu=
m types
<br>> are implicitly parameter packs", which of course would create lots=
of
<br>> problems. If really only "enum-name ..." would be allowed (e.g. th=
e
<br>> ellipsis has to follow the type-name directly), I would find the
<br>> similarities/differences this (very) special case would have to re=
gular
<br>> parameter packs quite problematic/limiting/hard to teach.
<br>>
<br>> As for David Krauss's proposal, this seems interesting, but again =
(like
<br>> nearly any language change) is bound to have a lot of problematic =
corner
<br>> cases. Take this example:
<br>>
<br>> template<class T, T... Ts>
<br>> void problematic() { std::cout << "1"; }
<br>>
<br>> template<class T, class U>
<br>> void problematic() { std::cout << "2"; }
<br>>
<br>> Currently, there is no ambiguity when called this way:
<br>>
<br>> enum Enum {};
<br>> problematic<Enum, Enum>();
<br>>
<br>> But what would happen with the new proposed way of implicit expans=
ion?
<br>
<br>Yes, I was aware of this when I made the suggestion. I don't think it's=
=20
<br>significant. There's a long way between this specific example and "lots=
=20
<br>of problems."
<br>
<br>I think it's more important that the ellipsis work consistently.
<br>
<br></blockquote><div> </div><div>I would guess that the committee wou=
ld find such corner cases significant. Some behaviour has to be defined for=
this case, and better one that does not break currently valid code, if at =
all possible.<br>But exactly this kind complexity is why I find this direct=
ion - of introducing a new, very specific language rule that has no benefit=
s except for this small purpose, and with some "gotchas" for unsuspecting p=
rogrammers - rather questionable. The language is complicated enough alread=
y.<br><br>I am not opposed to having reflection of enums in the form of a p=
arameter pack. But maybe it would be better to wait for improved parameter =
pack support in the language before pursuing that idea. Mike Spertus's N372=
8 sounds like it would be an ideal base. With such language functionality, =
there could be a simple trait class with magic specializations that exposes=
a parameter pack without any new language rules specific for enum reflecti=
on. Plus using the pack would be also simpler then.<br><br> </div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">> Even without this specific pr=
oblem, I find such an implicit conversion
<br>> (from a type into a value-parameter-list)
<br>
<br>Conversions are something else.
<br>
<br></blockquote><div><br>Are they? I might be using the wrong term, but th=
e description does sound like an implicit conversion from an enum type to a=
list of enum values would be happening given the right context (a non-type=
parameter pack of that enum type). Btw, would this also work under your pr=
oposition?:<br> enum e { foo, bar, baz };<br> =
template<typename E, E ... all_values ><br> &=
nbsp; struct enum_size { /* ... */ };<br> enum_size< e=
, foo, e >::value; // allowed?<br> enum_si=
ze< e, e, foo >::value; // allowed?<br><br> </div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">> very surprising and therefo=
re
<br>> problematic. In my opinion, such a big, "magical" feature needs to=
be way
<br>> more explicit. Why not expose such functionality only through the =
standard
<br>> library? This way all the trouble of a core language change is als=
o avoided.
<br>
<br>Contextual dependence of the precedence of the ellipsis is also quite=
=20
<br>subtly surprising. Which is easier to annotate with a comment:
<br>A. // this type is expanding to its enumerators
<br>B. // this expression must be kept inside a (meta)function because the=
=20
<br>ellipsis has odd precedence in the context it would need to be used=20
<br>otherwise
<br>
<br>I'm not sure how parsers deal with such issues, but it could be quite=
=20
<br>difficult to build the template AST, or at least hurt diagnostic=20
<br>generation, as before instantiation you don't know whether a type-id=20
<br>without an unexpanded pack can bind to the ellipsis.
<br>
<br>template< typename t >
<br>void foo() { return bar< t ... >(); } // C++11 error without inst=
antiating.
<br>// Proposed instantiation error: "non-pack t expanded but not=20
<br>enumeration type."
<br>
<br>Explicitness is nice, and the call site ellipsis is more explicit than=
=20
<br>none, but it's only marginal.
<br>
<br></blockquote><div><br>I am not defending the original proposal by Andre=
w. I think we all agree that that is no better/likely solution. But I am ar=
guing against any language change at all, and just let implementations deal=
with specializing some special templates in the std namespace, just like i=
t is successfully done already with the existing type traits.<br><br> =
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">>> The intention o=
f the two primitives is to make it possible for you to=20
<br>>> implement all of these things as library features. Once you ha=
ve the=20
<br>>> enumerator list as a pack I believe during translation you sho=
uld be=20
<br>>> able to create "flag sets" or "arrays indexed by an enum" or w=
hatever=20
<br>>> other fruit you may want. You will have statically all the=20
<br>>> information available about the enumerators and their values.=
=20
<br>> I understand that and have exactly the same goal as you, to see so=
me form
<br>> of enum reflection in the standard. The question of how to get the=
re is of
<br>> course the big one.
<br>
<br>One size of end-user interface will not fit all. The suggestions are=20
<br>already going all over the map. The best part of Andrew's proposal is=
=20
<br>holding to an ideal of metaprogramming tightly integrated with the comp=
iler.
<br>
<br></blockquote><div><br>One interface might fit in so far as other interf=
aces for specific use cases could just be synthesized from the one basic st=
andard one, thanks to constexpr. I agree that this interface should be as l=
ow-level as possible, so no information is discarded and as many applicatio=
ns as possible can be implemented on top of it.<br><br>Does decoupling the =
interface from the compiler/language a bit really hurt that much? As I prev=
iously mentioned, e.g. type trait's std::underlying_type<enum-type=
>::type is simply a wrapper around the "magic" intrinsic __u=
nderlying_type(enum-type) in GCC/clang. I would not say that the deci=
sion to standardize the wrapper changes anything really, and now I think we=
should respect this style the standard has chosen.<br> </div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">The best way to evaluate the solutions=
is to implement these extensions=20
<br>into mainstream distributions and see what survives in the wild.
<br>
<br>> Then given my "enum_data" definition from before the following wou=
ld hold:
<br>> enum_data<E1>::count =3D=3D 3 =3D=3D __e=
num_value_count(E1) //
<br>> __enumerator_count might be a better name..
<br>> enum_data<E1>::values =3D=3D [ 0, 10, 0 =
]
<br>> enum_data<E1>::names =3D=3D [ "e0", "e1"=
, "elast" ]
<br>>
<br>> This is a very low level view of an enumeration, as it keeps the c=
omplete
<br>> ordering even of duplicate values in the enum definition. This cou=
ld not be
<br>> reconstructed with your/David Krauss's approach, as a "enum_data" =
filled
<br>> with your primitives would look like this:
<br>> enum_data<E1>::count =3D=3D 2
<br>> enum_data<E1>::values =3D=3D [ 0, 10 ]
<br>> enum_data<E1>::names =3D=3D [ "e0\0elast=
\0", "e1\0" ] // or similar?
<br>
<br>It's probably better to stick either to arrays or to metafunctions, and=
=20
<br>avoid mixing interface styles. Neither is more expressive. Obviously a=
=20
<br>metafunction would work using indexes rather than keys, yet not=20
<br>necessarily be an array under the hood. Given either primitive, you=20
<br>could define a metafunction to retrieve the name of a given key or=20
<br>static_assert an error if it's ambiguous. But it would be O(N) in the=
=20
<br>number of enumerators.
<br>
<br></blockquote><div><br>After the discussion here I also think the functi=
on-interface approach is better than directly accessible arrays. The access=
ing pattern is more or less the same, but this way implementations have mor=
e room for optimizations, like the one Thiago brought up.<br><br>Value ->=
; enumerator index lookup (during compile- and run-time): while it can be d=
one in library (efficently, not only in O(N)) with only something like enum=
erator_info, I would argue that such an important function should be provid=
ed through the standard interface.<br><br> </div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;">> I mainly chose my way for implementation as it=
was trivial to do in clang
<br>> (clang already keeps all defined enumerators in this order) and be=
cause I
<br>> wanted to expose as much information as possible for experimenting=
..
<br>>
<br>> One application I could think of where my interface might be desir=
able
<br>> would be a graphical/console interface where the user can select t=
he value
<br>> for an enum out of a list of all options. Here, the original enume=
rator
<br>> order might be nice to have. Of course, I myself am not totally co=
nvinced
<br>> that this is really an important scenario.
<br>
<br>The important scenarios that come up relate to serialization: file=20
<br>formats, network protocols, database schemas, etc. You want to be able=
=20
<br>to verify that names conform to the spec. It would be nice to be able t=
o=20
<br>flag against case-insensitive duplicates in different enumerators at=20
<br>compile time.
<br></blockquote><div><br>String processing at compile time would be nice. =
With the new=20
constexpr relaxations it might be doable I think? At=20
least as long the identifiers are only ASCII and not full UTF8...<br><br>So=
me applications I have thought about are container classes that take an enu=
m as their index. This of course is already possible with something like st=
d::set<enum-type>, but that can't compete with classic C-style flag e=
nums, e.g.<br> enum TextStyle {<br> &nb=
sp; bold =3D 1,<br> italic=
=3D 2,<br> underlined =3D 4<br> =
};<br><br>std::bitset would be good for this task, but it requ=
ires an index [0 .. size[ -- which is where the enumerator index would fit =
in perfectly. That way, any enum could be made to work as a set without the=
brittle, C-style setting of values to the power of 2 or the wasteful std::=
set approach.<br><br>An array being indexed by an enum and holding any type=
of value would be done using the same principle also.<br><br><br>But I am =
very curious to see the call-for-papers Ville has announced. Knowing the di=
rection the study group is going/interested in should help focus/motivate d=
iscussions such as this one.<br><br><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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_113_10343879.1380556113414--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 30 Sep 2013 08:52:59 -0700
Raw View
On domingo, 29 de setembro de 2013 04:28:32, Christian Kaeser wrote:
> template<class T, T... Ts>
> void problematic() { std::cout << "1"; }
>
> template<class T, class U>
> void problematic() { std::cout << "2"; }
>
> Currently, there is no ambiguity when called this way:
>
> enum Enum {};
> problematic<Enum, Enum>();
I don't think there's a mismatch problem here. To me, the above clearly calls
the overload #2. I don't see how typename "Enum" would match "T... [with T =
Enum]": one is a typename, the other is expecting a list of enum values.
If you wanted to pass all possible enum values from that enum, you should have
to write:
problematic<Enum, Enum...>();
--
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: Christian Kaeser <christiankaeser87@googlemail.com>
Date: Mon, 30 Sep 2013 09:01:08 -0700 (PDT)
Raw View
------=_Part_2145_7216785.1380556868445
Content-Type: text/plain; charset=ISO-8859-1
On Monday, 30 September 2013 17:52:59 UTC+2, Thiago Macieira wrote:
>
> On domingo, 29 de setembro de 2013 04:28:32, Christian Kaeser wrote:
> > template<class T, T... Ts>
> > void problematic() { std::cout << "1"; }
> >
> > template<class T, class U>
> > void problematic() { std::cout << "2"; }
> >
> > Currently, there is no ambiguity when called this way:
> >
> > enum Enum {};
> > problematic<Enum, Enum>();
>
> I don't think there's a mismatch problem here. To me, the above clearly
> calls
> the overload #2. I don't see how typename "Enum" would match "T... [with T
> =
> Enum]": one is a typename, the other is expecting a list of enum values.
>
> If you wanted to pass all possible enum values from that enum, you should
> have
> to write:
>
> problematic<Enum, Enum...>();
>
> --
> 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 are describing Andrew's original proposal. I was referring to David's
proposition.
The thing with Andrew's syntax is that it either
- might wreck havok in (existing) parameter pack templates, should enums
*just* be implicit parameter packs
- or might be very confusing to teach and maybe too limited, as e.g.
func(E)... would not work, so workarounds would have to be written
--
---
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_2145_7216785.1380556868445
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, 30 September 2013 17:52:59 UTC+2, Thiag=
o Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On domingo, =
29 de setembro de 2013 04:28:32, Christian Kaeser wrote:
<br>> template<class T, T... Ts>
<br>> void problematic() { std::cout << "1"; }
<br>>=20
<br>> template<class T, class U>
<br>> void problematic() { std::cout << "2"; }
<br>>=20
<br>> Currently, there is no ambiguity when called this way:
<br>>=20
<br>> enum Enum {};
<br>> problematic<Enum, Enum>();
<br>
<br>I don't think there's a mismatch problem here. To me, the above clearly=
calls=20
<br>the overload #2. I don't see how typename "Enum" would match "T... [wit=
h T =3D=20
<br>Enum]": one is a typename, the other is expecting a list of enum values=
..
<br>
<br>If you wanted to pass all possible enum values from that enum, you shou=
ld have=20
<br>to write:
<br>
<br> problematic<Enum, En=
um...>();
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" targ=
et=3D"_blank">kde.org</a>
<br> Software Architect - Intel Open Source Technology Center
<br> PGP/GPG: 0x6EF45358; fingerprint:
<br> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4=
5358
<br>
<br></blockquote><div><br>You are describing Andrew's original proposal. I =
was referring to David's proposition.<br><br>The thing with Andrew's syntax=
is that it either<br><ul><li>might wreck havok in (existing) parameter pac=
k templates, should enums *just* be implicit parameter packs</li><li>or mig=
ht be very confusing to teach and maybe too limited, as e.g. func(E)... wou=
ld not work, so workarounds would have to be written<br></li></ul></div></d=
iv>
<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_2145_7216785.1380556868445--
.