While reviewing the C++11 and C++14 draft standard type traits yesterday
([meta.type.synop]), I noticed that there is no type trait to ascertain
whether or not a type meets the requirements for an aggregate
([dcl.init.aggr]).

The Boost Proto library does define such a type trait.  See
http://www.boost.org/doc/libs/1_55_0/doc/html/boost/proto/is_aggregate.html

I'm curious whether the lack of such a type trait is intentional, or
perhaps an unintentional omission in the standard.

As demonstrated below, the set of class types that meet the requirements
of an aggregate class type are distinct from the sets that match
standard layout, POD, or trivial class types.

It seems to me the standard should provide an is_aggregate type trait.
That said, I don't have a specific use case in mind.  Presumably, the
Boost Proto author(s) did however.

Assuming agreement that the standard should provide an is_aggregate type
trait, and that there isn't an existing proposal that I overlooked, I
would be willing to draft a proposal.

#include <type_traits>

struct empty_class {};

struct polymorphic_class {
     polymorphic_class(int);
     virtual void mf();
};

struct not_trivial_class {
     not_trivial_class(int = 0);
};

// Aggregate and standard layout class, but not a trivial or POD class.
struct aggregate_class {
     not_trivial_class ntc;
};
aggregate_class ac = {0}; // aggregate initialization.
static_assert(  std::is_standard_layout<aggregate_class>::value, "");
static_assert(! std::is_pod            <aggregate_class>::value, "");
static_assert(! std::is_trivial        <aggregate_class>::value, "");

// Aggregate class, but not a standard layout, POD, or trivial class.
struct aggregate_but_not_standard_layout_class {
     polymorphic_class pc;
};
aggregate_but_not_standard_layout_class abnslc = {0}; // aggregate
initialization.
static_assert(!
std::is_standard_layout<aggregate_but_not_standard_layout_class>::value,
"");
static_assert(! std::is_pod
<aggregate_but_not_standard_layout_class>::value, "");
static_assert(! std::is_trivial
<aggregate_but_not_standard_layout_class>::value, "");

// Standard layout class, but not a POD, trivial, or aggregate class.
struct standard_layout_but_not_aggregate_class : not_trivial_class {
};
static_assert(
std::is_standard_layout<standard_layout_but_not_aggregate_class>::value,
"");
static_assert(! std::is_pod
<standard_layout_but_not_aggregate_class>::value, "");
static_assert(! std::is_trivial
<standard_layout_but_not_aggregate_class>::value, "");

// POD, standard layout, and trivial class, but not an aggregate class.
struct pod_but_not_aggregate_class : empty_class {
};
static_assert(
std::is_standard_layout<pod_but_not_aggregate_class>::value, "");
static_assert(  std::is_pod
<pod_but_not_aggregate_class>::value, "");
static_assert(  std::is_trivial
<pod_but_not_aggregate_class>::value, "");

Tom.

--

---
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_478_7639605.1394482850562
Content-Type: text/plain; charset=UTF-8

On Monday, March 10, 2014 5:04:52 PM UTC+1, Tom Honermann wrote:
>
> While reviewing the C++11 and C++14 draft standard type traits yesterday
> ([meta.type.synop]), I noticed that there is no type trait to ascertain
> whether or not a type meets the requirements for an aggregate
> ([dcl.init.aggr]).
>
> The Boost Proto library does define such a type trait.  See
> http://www.boost.org/doc/libs/1_55_0/doc/html/boost/proto/is_aggregate.html
>
> I'm curious whether the lack of such a type trait is intentional, or
> perhaps an unintentional omission in the standard.
>
> As demonstrated below, the set of class types that meet the requirements
> of an aggregate class type are distinct from the sets that match
> standard layout, POD, or trivial class types.
>
> It seems to me the standard should provide an is_aggregate type trait.
> That said, I don't have a specific use case in mind.  Presumably, the
> Boost Proto author(s) did however.
>
> Assuming agreement that the standard should provide an is_aggregate type
> trait, and that there isn't an existing proposal that I overlooked, I
> would be willing to draft a proposal.
>
> #include <type_traits>
>
> struct empty_class {};
>
> struct polymorphic_class {
>      polymorphic_class(int);
>      virtual void mf();
> };
>
> struct not_trivial_class {
>      not_trivial_class(int = 0);
> };
>
> // Aggregate and standard layout class, but not a trivial or POD class.
> struct aggregate_class {
>      not_trivial_class ntc;
> };
> aggregate_class ac = {0}; // aggregate initialization.
> static_assert(  std::is_standard_layout<aggregate_class>::value, "");
> static_assert(! std::is_pod            <aggregate_class>::value, "");
> static_assert(! std::is_trivial        <aggregate_class>::value, "");
>
> // Aggregate class, but not a standard layout, POD, or trivial class.
> struct aggregate_but_not_standard_layout_class {
>      polymorphic_class pc;
> };
> aggregate_but_not_standard_layout_class abnslc = {0}; // aggregate
> initialization.
> static_assert(!
> std::is_standard_layout<aggregate_but_not_standard_layout_class>::value,
> "");
> static_assert(! std::is_pod
> <aggregate_but_not_standard_layout_class>::value, "");
> static_assert(! std::is_trivial
> <aggregate_but_not_standard_layout_class>::value, "");
>
> // Standard layout class, but not a POD, trivial, or aggregate class.
> struct standard_layout_but_not_aggregate_class : not_trivial_class {
> };
> static_assert(
> std::is_standard_layout<standard_layout_but_not_aggregate_class>::value,
> "");
> static_assert(! std::is_pod
> <standard_layout_but_not_aggregate_class>::value, "");
> static_assert(! std::is_trivial
> <standard_layout_but_not_aggregate_class>::value, "");
>
> // POD, standard layout, and trivial class, but not an aggregate class.
> struct pod_but_not_aggregate_class : empty_class {
> };
> static_assert(
> std::is_standard_layout<pod_but_not_aggregate_class>::value, "");
> static_assert(  std::is_pod
> <pod_but_not_aggregate_class>::value, "");
> static_assert(  std::is_trivial
> <pod_but_not_aggregate_class>::value, "");
>
> Tom.
>

You might be interested in this discussion as well:
https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/77IY0cAlYR8


The goal is to loosen some restrictions on aggregate types that have no
reason to be. Daryle Walker has written a draft wording:
http://htmlpreview.github.io/?https://raw.github.com/CTMacUser/multiarray-iso-proposal/master/expanded-aggregate-proposal.html

--

---
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_478_7639605.1394482850562
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, March 10, 2014 5:04:52 PM UTC+1, Tom Honermann =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">While reviewing the C++1=
1 and C++14 draft standard type traits yesterday=20
<br>([meta.type.synop]), I noticed that there is no type trait to ascertain=
=20
<br>whether or not a type meets the requirements for an aggregate=20
<br>([dcl.init.aggr]).
<br>
<br>The Boost Proto library does define such a type trait. &nbsp;See=20
<br><a href=3D"http://www.boost.org/doc/libs/1_55_0/doc/html/boost/proto/is=
_aggregate.html" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.g=
oogle.com/url?q\75http%3A%2F%2Fwww.boost.org%2Fdoc%2Flibs%2F1_55_0%2Fdoc%2F=
html%2Fboost%2Fproto%2Fis_aggregate.html\46sa\75D\46sntz\0751\46usg\75AFQjC=
NHCAMT2Pc02xRGdqHkrrPZuqGDGsA';return true;" onclick=3D"this.href=3D'http:/=
/www.google.com/url?q\75http%3A%2F%2Fwww.boost.org%2Fdoc%2Flibs%2F1_55_0%2F=
doc%2Fhtml%2Fboost%2Fproto%2Fis_aggregate.html\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNHCAMT2Pc02xRGdqHkrrPZuqGDGsA';return true;">http://www.boost.org/doc=
/libs/<wbr>1_55_0/doc/html/boost/proto/<wbr>is_aggregate.html</a>
<br>
<br>I'm curious whether the lack of such a type trait is intentional, or=20
<br>perhaps an unintentional omission in the standard.
<br>
<br>As demonstrated below, the set of class types that meet the requirement=
s=20
<br>of an aggregate class type are distinct from the sets that match=20
<br>standard layout, POD, or trivial class types.
<br>
<br>It seems to me the standard should provide an is_aggregate type trait.=
=20
<br>That said, I don't have a specific use case in mind. &nbsp;Presumably, =
the=20
<br>Boost Proto author(s) did however.
<br>
<br>Assuming agreement that the standard should provide an is_aggregate typ=
e=20
<br>trait, and that there isn't an existing proposal that I overlooked, I=
=20
<br>would be willing to draft a proposal.
<br>
<br>#include &lt;type_traits&gt;
<br>
<br>struct empty_class {};
<br>
<br>struct polymorphic_class {
<br>&nbsp; &nbsp; &nbsp;polymorphic_class(int);
<br>&nbsp; &nbsp; &nbsp;virtual void mf();
<br>};
<br>
<br>struct not_trivial_class {
<br>&nbsp; &nbsp; &nbsp;not_trivial_class(int =3D 0);
<br>};
<br>
<br>// Aggregate and standard layout class, but not a trivial or POD class.
<br>struct aggregate_class {
<br>&nbsp; &nbsp; &nbsp;not_trivial_class ntc;
<br>};
<br>aggregate_class ac =3D {0}; // aggregate initialization.
<br>static_assert( &nbsp;std::is_standard_layout&lt;<wbr>aggregate_class&gt=
;::value, "");
<br>static_assert(! std::is_pod &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&l=
t;aggregate_class&gt;::value, "");
<br>static_assert(! std::is_trivial &nbsp; &nbsp; &nbsp; &nbsp;&lt;aggregat=
e_class&gt;::value, "");
<br>
<br>// Aggregate class, but not a standard layout, POD, or trivial class.
<br>struct aggregate_but_not_standard_<wbr>layout_class {
<br>&nbsp; &nbsp; &nbsp;polymorphic_class pc;
<br>};
<br>aggregate_but_not_standard_<wbr>layout_class abnslc =3D {0}; // aggrega=
te=20
<br>initialization.
<br>static_assert(!=20
<br>std::is_standard_layout&lt;<wbr>aggregate_but_not_standard_<wbr>layout_=
class&gt;::value,=20
<br>"");
<br>static_assert(! std::is_pod=20
<br>&lt;aggregate_but_not_standard_<wbr>layout_class&gt;::value, "");
<br>static_assert(! std::is_trivial=20
<br>&lt;aggregate_but_not_standard_<wbr>layout_class&gt;::value, "");
<br>
<br>// Standard layout class, but not a POD, trivial, or aggregate class.
<br>struct standard_layout_but_not_<wbr>aggregate_class : not_trivial_class=
 {
<br>};
<br>static_assert(=20
<br>std::is_standard_layout&lt;<wbr>standard_layout_but_not_<wbr>aggregate_=
class&gt;::value,=20
<br>"");
<br>static_assert(! std::is_pod=20
<br>&lt;standard_layout_but_not_<wbr>aggregate_class&gt;::value, "");
<br>static_assert(! std::is_trivial=20
<br>&lt;standard_layout_but_not_<wbr>aggregate_class&gt;::value, "");
<br>
<br>// POD, standard layout, and trivial class, but not an aggregate class.
<br>struct pod_but_not_aggregate_class : empty_class {
<br>};
<br>static_assert(=20
<br>std::is_standard_layout&lt;pod_<wbr>but_not_aggregate_class&gt;::<wbr>v=
alue, "");
<br>static_assert( &nbsp;std::is_pod=20
<br>&lt;pod_but_not_aggregate_class&gt;:<wbr>:value, "");
<br>static_assert( &nbsp;std::is_trivial=20
<br>&lt;pod_but_not_aggregate_class&gt;:<wbr>:value, "");
<br>
<br>Tom.
<br></blockquote><div><br>You might be interested in this discussion as wel=
l:<br>https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/77=
IY0cAlYR8 <br><br>The goal is to loosen some restrictions on aggregate type=
s that have no<br>reason to be. Daryle Walker has written a draft wording:<=
br>http://htmlpreview.github.io/?https://raw.github.com/CTMacUser/multiarra=
y-iso-proposal/master/expanded-aggregate-proposal.html<br></div><mytubeelem=
ent data=3D"{&quot;bundle&quot;:{&quot;label_delimitor&quot;:&quot;:&quot;,=
&quot;percentage&quot;:&quot;%&quot;,&quot;smart_buffer&quot;:&quot;Smart B=
uffer&quot;,&quot;start_playing_when_buffered&quot;:&quot;Start playing whe=
n buffered&quot;,&quot;sound&quot;:&quot;Sound&quot;,&quot;desktop_notifica=
tion&quot;:&quot;Desktop Notification&quot;,&quot;continuation_on_next_line=
&quot;:&quot;-&quot;,&quot;loop&quot;:&quot;Loop&quot;,&quot;only_notify&qu=
ot;:&quot;Only Notify&quot;,&quot;estimated_time&quot;:&quot;Estimated Time=
&quot;,&quot;global_preferences&quot;:&quot;Global Preferences&quot;,&quot;=
no_notification_supported_on_your_browser&quot;:&quot;No notification style=
 supported on your browser version&quot;,&quot;video_buffered&quot;:&quot;V=
ideo Buffered&quot;,&quot;buffered&quot;:&quot;Buffered&quot;,&quot;hyphen&=
quot;:&quot;-&quot;,&quot;buffered_message&quot;:&quot;The video has been b=
uffered as requested and is ready to play.&quot;,&quot;not_supported&quot;:=
&quot;Not Supported&quot;,&quot;on&quot;:&quot;On&quot;,&quot;off&quot;:&qu=
ot;Off&quot;,&quot;click_to_enable_for_this_site&quot;:&quot;Click to enabl=
e for this site&quot;,&quot;desktop_notification_denied&quot;:&quot;You hav=
e denied permission for desktop notification for this site&quot;,&quot;noti=
fication_status_delimitor&quot;:&quot;;&quot;,&quot;error&quot;:&quot;Error=
&quot;,&quot;adblock_interferance_message&quot;:&quot;Adblock (or similar e=
xtension) is known to interfere with SmartVideo. Please add this url to adb=
lock whitelist.&quot;,&quot;calculating&quot;:&quot;Calculating&quot;,&quot=
;waiting&quot;:&quot;Waiting&quot;,&quot;will_start_buffering_when_initiali=
zed&quot;:&quot;Will start buffering when initialized&quot;,&quot;will_star=
t_playing_when_initialized&quot;:&quot;Will start playing when initialized&=
quot;,&quot;completed&quot;:&quot;Completed&quot;,&quot;buffering_stalled&q=
uot;:&quot;Buffering is stalled. Will stop.&quot;,&quot;stopped&quot;:&quot=
;Stopped&quot;,&quot;hr&quot;:&quot;Hr&quot;,&quot;min&quot;:&quot;Min&quot=
;,&quot;sec&quot;:&quot;Sec&quot;,&quot;any_moment&quot;:&quot;Any Moment&q=
uot;,&quot;popup_donate_to&quot;:&quot;Donate to&quot;,&quot;extension_id&q=
uot;:null},&quot;prefs&quot;:{&quot;desktopNotification&quot;:true,&quot;so=
undNotification&quot;:false,&quot;logLevel&quot;:0,&quot;enable&quot;:true,=
&quot;loop&quot;:false,&quot;hidePopup&quot;:false,&quot;autoPlay&quot;:fal=
se,&quot;autoBuffer&quot;:false,&quot;autoPlayOnBuffer&quot;:false,&quot;au=
toPlayOnBufferPercentage&quot;:42,&quot;autoPlayOnSmartBuffer&quot;:true,&q=
uot;quality&quot;:&quot;default&quot;,&quot;fshd&quot;:false,&quot;onlyNoti=
fication&quot;:true,&quot;enableFullScreen&quot;:true,&quot;saveBandwidth&q=
uot;:false,&quot;hideAnnotations&quot;:true,&quot;turnOffPagedBuffering&quo=
t;:true}}" event=3D"preferencesUpdated" id=3D"myTubeRelayElementToPage"></m=
ytubeelement><mytubeelement data=3D"{&quot;loadBundle&quot;:true}" event=3D=
"relayPrefs" id=3D"myTubeRelayElementToTab"></mytubeelement></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_478_7639605.1394482850562--

.

--001a113376fecf885a04f447bdc7
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Mar 10, 2014 at 9:04 AM, Tom Honermann <thonermann@coverity.com>wrote:

> While reviewing the C++11 and C++14 draft standard type traits yesterday
> ([meta.type.synop]), I noticed that there is no type trait to ascertain
> whether or not a type meets the requirements for an aggregate
> ([dcl.init.aggr]).
>
> The Boost Proto library does define such a type trait.  See
> http://www.boost.org/doc/libs/1_55_0/doc/html/boost/proto/
> is_aggregate.html
>
> I'm curious whether the lack of such a type trait is intentional, or
> perhaps an unintentional omission in the standard.
>
> As demonstrated below, the set of class types that meet the requirements
> of an aggregate class type are distinct from the sets that match standard
> layout, POD, or trivial class types.
>
> It seems to me the standard should provide an is_aggregate type trait.
> That said, I don't have a specific use case in mind.  Presumably, the Boost
> Proto author(s) did however.
>

I have reservations about this trait. We made a mistake adding useless
traits like is_pod and is_literal_type, and we shouldn't compound that
mistake by adding more useless traits.

In my view, type traits should capture observable properties of types (such
as, "can I direct-initialize this type from that braced-init-list?"), and
not core language ephemera (such as "does this type obey the literal type
rules, which are a crutch for requiring a compiler diagnostic?" or "will
braced initialization on this type perform aggregate initialization or will
it call a constructor?").

Also, I think that a type should be able to switch between being an
aggregate and providing an equivalent constructor set without worrying that
someone might be observing the difference.


> Assuming agreement that the standard should provide an is_aggregate type
> trait, and that there isn't an existing proposal that I overlooked, I would
> be willing to draft a proposal.
>
> #include <type_traits>
>
> struct empty_class {};
>
> struct polymorphic_class {
>     polymorphic_class(int);
>     virtual void mf();
> };
>
> struct not_trivial_class {
>     not_trivial_class(int = 0);
> };
>
> // Aggregate and standard layout class, but not a trivial or POD class.
> struct aggregate_class {
>     not_trivial_class ntc;
> };
> aggregate_class ac = {0}; // aggregate initialization.
> static_assert(  std::is_standard_layout<aggregate_class>::value, "");
> static_assert(! std::is_pod            <aggregate_class>::value, "");
> static_assert(! std::is_trivial        <aggregate_class>::value, "");
>
> // Aggregate class, but not a standard layout, POD, or trivial class.
> struct aggregate_but_not_standard_layout_class {
>     polymorphic_class pc;
> };
> aggregate_but_not_standard_layout_class abnslc = {0}; // aggregate
> initialization.
> static_assert(! std::is_standard_layout<aggregate_but_not_standard_layout_class>::value,
> "");
> static_assert(! std::is_pod <aggregate_but_not_standard_layout_class>::value,
> "");
> static_assert(! std::is_trivial <aggregate_but_not_standard_layout_class>::value,
> "");
>
> // Standard layout class, but not a POD, trivial, or aggregate class.
> struct standard_layout_but_not_aggregate_class : not_trivial_class {
> };
> static_assert( std::is_standard_layout<standard_layout_but_not_aggregate_class>::value,
> "");
> static_assert(! std::is_pod <standard_layout_but_not_aggregate_class>::value,
> "");
> static_assert(! std::is_trivial <standard_layout_but_not_aggregate_class>::value,
> "");
>
> // POD, standard layout, and trivial class, but not an aggregate class.
> struct pod_but_not_aggregate_class : empty_class {
> };
> static_assert( std::is_standard_layout<pod_but_not_aggregate_class>::value,
> "");
> static_assert(  std::is_pod <pod_but_not_aggregate_class>::value, "");
> static_assert(  std::is_trivial <pod_but_not_aggregate_class>::value, "");
>
> Tom.
>
> --
>
> --- 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/.

--001a113376fecf885a04f447bdc7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Mar 10, 2014 at 9:04 AM, Tom Honermann <span dir=3D"ltr">&lt;<a href=3D=
"mailto:thonermann@coverity.com" target=3D"_blank">thonermann@coverity.com<=
/a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">While reviewing the C++11 and C++14 draft st=
andard type traits yesterday ([meta.type.synop]), I noticed that there is n=
o type trait to ascertain whether or not a type meets the requirements for =
an aggregate ([dcl.init.aggr]).<br>

<br>
The Boost Proto library does define such a type trait. =A0See <a href=3D"ht=
tp://www.boost.org/doc/libs/1_55_0/doc/html/boost/proto/is_aggregate.html" =
target=3D"_blank">http://www.boost.org/doc/libs/<u></u>1_55_0/doc/html/boos=
t/proto/<u></u>is_aggregate.html</a><br>

<br>
I&#39;m curious whether the lack of such a type trait is intentional, or pe=
rhaps an unintentional omission in the standard.<br>
<br>
As demonstrated below, the set of class types that meet the requirements of=
 an aggregate class type are distinct from the sets that match standard lay=
out, POD, or trivial class types.<br>
<br>
It seems to me the standard should provide an is_aggregate type trait. That=
 said, I don&#39;t have a specific use case in mind. =A0Presumably, the Boo=
st Proto author(s) did however.<br></blockquote><div><br></div><div>I have =
reservations about this trait. We made a mistake adding useless traits like=
 is_pod and is_literal_type, and we shouldn&#39;t compound that mistake by =
adding more useless traits.</div>
<div><br></div><div>In my view, type traits should capture observable prope=
rties of types (such as, &quot;can I direct-initialize this type from that =
braced-init-list?&quot;), and not core language ephemera (such as &quot;doe=
s this type obey the literal type rules, which are a crutch for requiring a=
 compiler diagnostic?&quot; or &quot;will braced initialization on this typ=
e perform aggregate initialization or will it call a constructor?&quot;).</=
div>
<div><br></div><div>Also, I think that a type should be able to switch betw=
een being an aggregate and providing an equivalent constructor set without =
worrying that someone might be observing the difference.</div><div>=A0</div=
>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Assuming agreement that the standard should provide an is_aggregate type tr=
ait, and that there isn&#39;t an existing proposal that I overlooked, I wou=
ld be willing to draft a proposal.<br>
<br>
#include &lt;type_traits&gt;<br>
<br>
struct empty_class {};<br>
<br>
struct polymorphic_class {<br>
=A0 =A0 polymorphic_class(int);<br>
=A0 =A0 virtual void mf();<br>
};<br>
<br>
struct not_trivial_class {<br>
=A0 =A0 not_trivial_class(int =3D 0);<br>
};<br>
<br>
// Aggregate and standard layout class, but not a trivial or POD class.<br>
struct aggregate_class {<br>
=A0 =A0 not_trivial_class ntc;<br>
};<br>
aggregate_class ac =3D {0}; // aggregate initialization.<br>
static_assert( =A0std::is_standard_layout&lt;<u></u>aggregate_class&gt;::va=
lue, &quot;&quot;);<br>
static_assert(! std::is_pod =A0 =A0 =A0 =A0 =A0 =A0&lt;aggregate_class&gt;:=
:value, &quot;&quot;);<br>
static_assert(! std::is_trivial =A0 =A0 =A0 =A0&lt;aggregate_class&gt;::val=
ue, &quot;&quot;);<br>
<br>
// Aggregate class, but not a standard layout, POD, or trivial class.<br>
struct aggregate_but_not_standard_<u></u>layout_class {<br>
=A0 =A0 polymorphic_class pc;<br>
};<br>
aggregate_but_not_standard_<u></u>layout_class abnslc =3D {0}; // aggregate=
 initialization.<br>
static_assert(! std::is_standard_layout&lt;<u></u>aggregate_but_not_standar=
d_<u></u>layout_class&gt;::value, &quot;&quot;);<br>
static_assert(! std::is_pod &lt;aggregate_but_not_standard_<u></u>layout_cl=
ass&gt;::value, &quot;&quot;);<br>
static_assert(! std::is_trivial &lt;aggregate_but_not_standard_<u></u>layou=
t_class&gt;::value, &quot;&quot;);<br>
<br>
// Standard layout class, but not a POD, trivial, or aggregate class.<br>
struct standard_layout_but_not_<u></u>aggregate_class : not_trivial_class {=
<br>
};<br>
static_assert( std::is_standard_layout&lt;<u></u>standard_layout_but_not_<u=
></u>aggregate_class&gt;::value, &quot;&quot;);<br>
static_assert(! std::is_pod &lt;standard_layout_but_not_<u></u>aggregate_cl=
ass&gt;::value, &quot;&quot;);<br>
static_assert(! std::is_trivial &lt;standard_layout_but_not_<u></u>aggregat=
e_class&gt;::value, &quot;&quot;);<br>
<br>
// POD, standard layout, and trivial class, but not an aggregate class.<br>
struct pod_but_not_aggregate_class : empty_class {<br>
};<br>
static_assert( std::is_standard_layout&lt;pod_<u></u>but_not_aggregate_clas=
s&gt;::<u></u>value, &quot;&quot;);<br>
static_assert( =A0std::is_pod &lt;pod_but_not_aggregate_class&gt;:<u></u>:v=
alue, &quot;&quot;);<br>
static_assert( =A0std::is_trivial &lt;pod_but_not_aggregate_class&gt;:<u></=
u>:value, &quot;&quot;);<br>
<br>
Tom.<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@<u></u>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/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</font></span></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113376fecf885a04f447bdc7--

.

On 2014-03-11, at 6:01 AM, Richard Smith <richard@metafoo.co.uk> wrote:

> Also, I think that a type should be able to switch between being an aggre=
gate and providing an equivalent constructor set without worrying that some=
one might be observing the difference.

Constructor definition rules should generally evolve to allow non-aggregate=
s to imitate aggregates.

Whatever quirk is_aggregate is needed to work around, let's nip it in the b=
ud at the core language level. Or at least try.

Also, note that the aggregate rules are in flux. In C++03, aggregate was cl=
osely related to POD. C++11 is very loose; there may be non-aggregate subob=
jects and empty bases. It has been suggested, if not proposed, for C++17 th=
at access qualified NSDMs may be allowed, as long as they are accessible. S=
o is_aggregate would just be an invitation to future breakage.

--=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/.

.

Richard Smith <richard@metafoo.co.uk> writes:

[...]

| I have reservations about this trait. We made a mistake adding useless
| traits like is_pod and is_literal_type, and we shouldn't compound that
| mistake by adding more useless traits.

Seconded.

-- Gaby

--

---
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/.

.

David Krauss <potswa@gmail.com> writes:

| On 2014-03-11, at 6:01 AM, Richard Smith <richard@metafoo.co.uk> wrote:
|
| > Also, I think that a type should be able to switch between being an
| > aggregate and providing an equivalent constructor set without
| > worrying that someone might be observing the difference.
|
| Constructor definition rules should generally evolve to allow
| non-aggregates to imitate aggregates.

It is a bug in the standard that we have this distinction, IMNSHO.  The
correct action is for it to go away.

-- Gaby

--

---
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/.

.