------=_Part_511_1131837806.1411720754255
Content-Type: text/plain; charset=UTF-8

How useful would it be to have a way at compile-time to retrieve attributes
attached to a class, function, variable, etc.?  It would be a way to detect
[[carries_dependency]] or to implement an equivalent to Microsoft's
__declspec(uuid(...)) + __uuidof(T), but I don't know whether that's worth
it =)

Melissa

--

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

<div dir=3D"ltr">How useful would it be to have a way at compile-time to re=
trieve attributes attached to a class, function, variable, etc.?&nbsp; It w=
ould be a way to detect [[carries_dependency]] or to implement an equivalen=
t to Microsoft's __declspec(uuid(...)) + __uuidof(T), but I don't know whet=
her that's worth it =3D)<br><br>Melissa<br></div>

<p></p>

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

------=_Part_511_1131837806.1411720754255--

.

------=_Part_232_1969486308.1411722180104
Content-Type: text/plain; charset=UTF-8

On Friday, September 26, 2014 5:39:14 AM UTC-3, Myriachan wrote:
>
> How useful would it be to have a way at compile-time to retrieve
> attributes attached to a class, function, variable, etc.?  It would be a
> way to detect [[carries_dependency]] or to implement an equivalent to
> Microsoft's __declspec(uuid(...)) + __uuidof(T), but I don't know whether
> that's worth it =)
>
>
The committee is against standardizing attributes that change the language
semantics, and having reflection on them would do just 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/.

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

<div dir=3D"ltr">On Friday, September 26, 2014 5:39:14 AM UTC-3, Myriachan =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">How use=
ful would it be to have a way at compile-time to retrieve attributes attach=
ed to a class, function, variable, etc.?&nbsp; It would be a way to detect =
[[carries_dependency]] or to implement an equivalent to Microsoft's __decls=
pec(uuid(...)) + __uuidof(T), but I don't know whether that's worth it =3D)=
<br><br></div></blockquote><div><br>The committee is against standardizing =
attributes that change the language semantics, and having reflection on the=
m would do just that.<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 />

------=_Part_232_1969486308.1411722180104--

.

On 26 September 2014 12:03, Matheus Izvekov <mizvekov@gmail.com> wrote:
> On Friday, September 26, 2014 5:39:14 AM UTC-3, Myriachan wrote:
>>
>> How useful would it be to have a way at compile-time to retrieve
>> attributes attached to a class, function, variable, etc.?  It would be a way
>> to detect [[carries_dependency]] or to implement an equivalent to
>> Microsoft's __declspec(uuid(...)) + __uuidof(T), but I don't know whether
>> that's worth it =)
>>
>
> The committee is against standardizing attributes that change the language
> semantics, and having reflection on them would do just that.


That's a bold claim. N4113 doesn't seem to include any sort of
attribute support,
but I wouldn't think it unpalatable for the committee to include
attributes in reflection.
Reflection of attributes does not change semantics; it's just a means to query
whether a declaration was annotated with an attribute or not.

--

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

On Friday, September 26, 2014 6:05:36 AM UTC-3, Ville Voutilainen wrote:
>
> That's a bold claim. N4113 doesn't seem to include any sort of
> attribute support,
> but I wouldn't think it unpalatable for the committee to include
> attributes in reflection.
> Reflection of attributes does not change semantics; it's just a means to
> query
> whether a declaration was annotated with an attribute or not.
>

Well, thanks for the correction. I have been repeating something like that
and had not been corrected so far.
My best understanding of what the committee understood as language
semantics was that their presence could not be "detected", ie they would
either make the compiler generate different (perhaps more efficient) code,
but still work "as-if", or that they would (by misuse) make the the program
ill-formed. But not for example make two well-formed programs behave
differently only by their presence/absence.

So you are saying that's too extreme? What's your best understanding of
this rule then?

--

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

<div dir=3D"ltr">On Friday, September 26, 2014 6:05:36 AM UTC-3, Ville Vout=
ilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">That's a bold cl=
aim. N4113 doesn't seem to include any sort of
<br>attribute support,
<br>but I wouldn't think it unpalatable for the committee to include
<br>attributes in reflection.
<br>Reflection of attributes does not change semantics; it's just a means t=
o query
<br>whether a declaration was annotated with an attribute or not.
<br></blockquote><div><br>Well, thanks for the correction. I have been repe=
ating something like that and had not been corrected so far.<br>My best und=
erstanding of what the committee understood as language semantics was that =
their presence could not be "detected", ie they would either make the compi=
ler generate different (perhaps more efficient) code, but still work "as-if=
", or that they would (by misuse) make the the program ill-formed. But not =
for example make two well-formed programs behave differently only by their =
presence/absence.<br><br>So you are saying that's too extreme? What's your =
best understanding of this rule then?<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 />

------=_Part_132_1340511168.1411722925877--

.

On 2014-09-26, at 5:05 PM, Ville Voutilainen <ville.voutilainen@gmail.com> =
wrote:

> Reflection of attributes does not change semantics; it's just a means to =
query
> whether a declaration was annotated with an attribute or not.

In answering the question of whether a given attribute would change program=
 semantics, it's common to try and construct an example that would discrimi=
nate the proposed semantic difference.

With reflection, discrimination would always be trivial. The meaning of pro=
grams without reflection wouldn't change, but programs with reflection woul=
d. The question is whether reflective queries should be specially exempt an=
d different or "less meaningful" than other semantics. I that could lead us=
ers on a dangerous path. At the least there should be a solid rationale abo=
ut the difference.

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

.

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

On Friday, September 26, 2014 6:20:56 AM UTC-3, David Krauss wrote:
>
> In answering the question of whether a given attribute would change=20
> program semantics, it=E2=80=99s common to try and construct an example th=
at would=20
> discriminate the proposed semantic difference.=20
>
> With reflection, discrimination would always be trivial. The meaning of=
=20
> programs without reflection wouldn=E2=80=99t change, but programs with re=
flection=20
> would. The question is whether reflective queries should be specially=20
> exempt and different or =E2=80=9Cless meaningful=E2=80=9D than other sema=
ntics. I that=20
> could lead users on a dangerous path. At the least there should be a soli=
d=20
> rationale about the difference.=20
>

I agree. I am not even against adding "meaningful" attributes, I think it=
=20
would be better to support reflection and many other ones that are for now=
=20
under implementation-specific namespaces.
But I certainly think it would be worse if the committee allowed some murky=
=20
mishmash of some semantic changes, but not others.

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

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

<div dir=3D"ltr">On Friday, September 26, 2014 6:20:56 AM UTC-3, David Krau=
ss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
In answering the question of whether a given attribute would change program=
 semantics, it=E2=80=99s common to try and construct an example that would =
discriminate the proposed semantic difference.
<br>
<br>With reflection, discrimination would always be trivial. The meaning of=
 programs without reflection wouldn=E2=80=99t change, but programs with ref=
lection would. The question is whether reflective queries should be special=
ly exempt and different or =E2=80=9Cless meaningful=E2=80=9D than other sem=
antics. I that could lead users on a dangerous path. At the least there sho=
uld be a solid rationale about the difference.
<br></blockquote><div><br>I agree. I am not even against adding "meaningful=
" attributes, I think it would be better to support reflection and many oth=
er ones that are for now under implementation-specific namespaces.<br>But I=
 certainly think it would be worse if the committee allowed some murky mish=
mash of some semantic changes, but not others.<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 />

------=_Part_154_1631950610.1411724100579--

.

On 26 September 2014 12:35, Matheus Izvekov <mizvekov@gmail.com> wrote:
> On Friday, September 26, 2014 6:20:56 AM UTC-3, David Krauss wrote:
>>
>> In answering the question of whether a given attribute would change
>> program semantics, it=E2=80=99s common to try and construct an example t=
hat would
>> discriminate the proposed semantic difference.
>>
>> With reflection, discrimination would always be trivial. The meaning of
>> programs without reflection wouldn=E2=80=99t change, but programs with r=
eflection
>> would. The question is whether reflective queries should be specially ex=
empt
>> and different or =E2=80=9Cless meaningful=E2=80=9D than other semantics.=
 I that could lead
>> users on a dangerous path. At the least there should be a solid rational=
e
>> about the difference.
>
>
> I agree. I am not even against adding "meaningful" attributes, I think it
> would be better to support reflection and many other ones that are for no=
w
> under implementation-specific namespaces.
> But I certainly think it would be worse if the committee allowed some mur=
ky
> mishmash of some semantic changes, but not others.

Querying the properties of a declaration and making decisions based on thos=
e
properties doesn't seem nefarious to me, even if those properties are
attributes.
We can certainly make people aware of whether such attribute reflection is
100% portable, but that doesn't mean we should ban it outright.

I do see your point, though - some implementations would likely wish
to ignore attributes
completely, and thus not include them in any reflection information. I
am perfectly happy with an
approach that makes it implementation-defined whether attributes are
returned for a reflective attribute query or not.

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

.

------=_Part_151_448363212.1411726805704
Content-Type: text/plain; charset=UTF-8

On Friday, September 26, 2014 6:58:17 AM UTC-3, Ville Voutilainen wrote:
>
> I do see your point, though - some implementations would likely wish
> to ignore attributes
> completely, and thus not include them in any reflection information. I
> am perfectly happy with an
> approach that makes it implementation-defined whether attributes are
> returned for a reflective attribute query or not.
>

Yes, I think the biggest strength of the current approach is that it makes
things conceptually simpler to some degree,
that implementations could choose to completely ignore attributes and not
change the program semantics.
But allowing implementation-specific attributes to violate that rule was
unfortunate in regards to that...

Still, attributes are a very satisfying way of adding implementation
specific features in a way that's much less likely to break the grammar.

So maybe there ought to be a syntactic distinction between attributes that
can be ignored, and those that would possibly break the program if they
were ignored.
To handle the latter, the compiler would just error out and print
diagnostics to the effect that they are unsupported.

It seems this distinction is missing in the current standard. It would be
broken to ignore lots of implementation-specific attributes currently under
namespaces, and this seems like a flaw worth to consider fixing.
Implementations could also choose to introduce "non-meaningful" attributes
as well, and these would be safe to ignore, but there is no easy way to
knowing that syntactically, just by 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/.

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

<div dir=3D"ltr">On Friday, September 26, 2014 6:58:17 AM UTC-3, Ville Vout=
ilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I do see your po=
int, though - some implementations would likely wish
<br>to ignore attributes
<br>completely, and thus not include them in any reflection information. I
<br>am perfectly happy with an
<br>approach that makes it implementation-defined whether attributes are
<br>returned for a reflective attribute query or not.
<br></blockquote><div><br>Yes, I think the biggest strength of the current =
approach is that it makes things conceptually simpler to some degree,<br>th=
at implementations could choose to completely ignore attributes and not cha=
nge the program semantics.<br>But allowing implementation-specific attribut=
es to violate that rule was unfortunate in regards to that...<br><br>Still,=
 attributes are a very satisfying way of adding implementation specific fea=
tures in a way that's much less likely to break the grammar.<br><br>So mayb=
e there ought to be a syntactic distinction between attributes that can be =
ignored, and those that would possibly break the program if they were ignor=
ed.<br>To handle the latter, the compiler would just error out and print di=
agnostics to the effect that they are unsupported.<br><br>It seems this dis=
tinction is missing in the current standard. It would be broken to ignore l=
ots of implementation-specific attributes currently under namespaces, and t=
his seems like a flaw worth to consider fixing.<br>Implementations could al=
so choose to introduce "non-meaningful" attributes as well, and these would=
 be safe to ignore, but there is no easy way to knowing that syntactically,=
 just by name.<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 />

------=_Part_151_448363212.1411726805704--

.

On 26 September 2014 13:20, Matheus Izvekov <mizvekov@gmail.com> wrote:
> Yes, I think the biggest strength of the current approach is that it makes
> things conceptually simpler to some degree,
> that implementations could choose to completely ignore attributes and not
> change the program semantics.
> But allowing implementation-specific attributes to violate that rule was
> unfortunate in regards to that...

Implementation-specific annotations are not something the standard can dictate.
Allowing implementations to do what they please with them at least encourages
implementations to adopt standard attribute grammar, as you point out below.
Otherwise they would continue using whatever implementation-specific
double-underscore
hack.

> Still, attributes are a very satisfying way of adding implementation
> specific features in a way that's much less likely to break the grammar.

Exactly.

>
> So maybe there ought to be a syntactic distinction between attributes that
> can be ignored, and those that would possibly break the program if they were
> ignored.
> To handle the latter, the compiler would just error out and print
> diagnostics to the effect that they are unsupported.

I fail to see what the point of this would be. An implementation can already
diagnose attributes it doesn't grok.

> It seems this distinction is missing in the current standard. It would be
> broken to ignore lots of implementation-specific attributes currently under
> namespaces, and this seems like a flaw worth to consider fixing.

I don't see how that's the case. If you use an implementation-specific attribute
and you need the semantics of that implementation-specific attribute, it's
not the standard's problem to make your code ill-formed on other
implementations.

I fail to see the use of spending committee energy on this. I don't
believe it's a useful
use of the committee's time.

--

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

On Friday, September 26, 2014 7:20:05 AM UTC-3, Matheus Izvekov wrote:
>
> It seems this distinction is missing in the current standard. It would be
> broken to ignore lots of implementation-specific attributes currently under
> namespaces, and this seems like a flaw worth to consider fixing.
> Implementations could also choose to introduce "non-meaningful" attributes
> as well, and these would be safe to ignore, but there is no easy way to
> knowing that syntactically, just by name.
>

So, to exemplify what I said above, consider the following strawman-syntax:

[[ non_meaningful_attrib1, nma2, ... ]] [[[ meaningful_attrib1, ma2, ... ]]]

So two '[' for "non-meaningful" ones, and three for meaningful ones.

If the compiler saw any attrib under [[ ]] it did not know about, it could
just ignore it, but if it saw any under [[[ ]]] it did not know about, it
would error out and issue a diagnostic.

Now we just have to go back in time and stop gnu::xxxx from being allowed
under [[ ]] ....

--

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

<div dir=3D"ltr">On Friday, September 26, 2014 7:20:05 AM UTC-3, Matheus Iz=
vekov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div>It seems this distinction is missing in the current standard. It would =
be broken to ignore lots of implementation-specific attributes currently un=
der namespaces, and this seems like a flaw worth to consider fixing.<br>Imp=
lementations could also choose to introduce "non-meaningful" attributes as =
well, and these would be safe to ignore, but there is no easy way to knowin=
g that syntactically, just by name.<br></div></div></blockquote><div><br>So=
, to exemplify what I said above, consider the following strawman-syntax:<b=
r><br>[[ non_meaningful_attrib1, nma2, ... ]] [[[ meaningful_attrib1, ma2, =
.... ]]]<br><br>So two '[' for "non-meaningful" ones, and three for meaningf=
ul ones.<br><br>If the compiler saw any attrib under [[ ]] it did not know =
about, it could just ignore it, but if it saw any under [[[ ]]] it did not =
know about, it would error out and issue a diagnostic.<br><br>Now we just h=
ave to go back in time and stop gnu::xxxx from being allowed under [[ ]] ..=
...<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 />

------=_Part_184_1988463249.1411727656395--

.

------=_Part_197_1901797194.1411727938554
Content-Type: text/plain; charset=UTF-8

On Friday, September 26, 2014 7:31:13 AM UTC-3, Ville Voutilainen wrote:
>
> I don't see how that's the case. If you use an implementation-specific
> attribute
> and you need the semantics of that implementation-specific attribute, it's
> not the standard's problem to make your code ill-formed on other
> implementations.
>
> I fail to see the use of spending committee energy on this. I don't
> believe it's a useful
> use of the committee's time.
>

Well, I just posted an example of what i meant right as you were replying
this.
If you still don't think that's worth the trouble, so well, I am not too
committed to this idea either, but I still think it has some merit :)

--

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

<div dir=3D"ltr">On Friday, September 26, 2014 7:31:13 AM UTC-3, Ville Vout=
ilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I don't see how =
that's the case. If you use an implementation-specific attribute
<br>and you need the semantics of that implementation-specific attribute, i=
t's
<br>not the standard's problem to make your code ill-formed on other
<br>implementations.
<br>
<br>I fail to see the use of spending committee energy on this. I don't
<br>believe it's a useful
<br>use of the committee's time.
<br></blockquote><div><br>Well, I just posted an example of what i meant ri=
ght as you were replying this.<br>If you still don't think that's worth the=
 trouble, so well, I am not too committed to this idea either, but I still =
think it has some merit :)<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 />

------=_Part_197_1901797194.1411727938554--

.

------=_Part_240_1143898853.1411728954138
Content-Type: text/plain; charset=UTF-8

On Friday, September 26, 2014 7:34:16 AM UTC-3, Matheus Izvekov wrote:
>
> Now we just have to go back in time and stop gnu::xxxx from being allowed
> under [[ ]] ....
>

So, maybe a syntax that fits better with the current situation would be to
have a '!' prefix for attributes.
If they are prefixed by !, the compiler is required to either support them
or diagnose, if they are not prefixed, the compiler can just ignore them.

And so perhaps reflection would only works on attributes prefixed with '!'.

Seems like a fair compromise?

--

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

<div dir=3D"ltr">On Friday, September 26, 2014 7:34:16 AM UTC-3, Matheus Iz=
vekov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div>Now we just have to go back in time and stop gnu::xxxx from being allow=
ed under [[ ]] ....<br></div></div></blockquote><div><br>So, maybe a syntax=
 that fits better with the current situation would be to have a '!' prefix =
for attributes.<br>If they are prefixed by !, the compiler is required to e=
ither support them or diagnose, if they are not prefixed, the compiler can =
just ignore them.<br><br>And so perhaps reflection would only works on attr=
ibutes prefixed with '!'.<br><br>Seems like a fair compromise?<br></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&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_240_1143898853.1411728954138--

.

On 26 September 2014 13:55, Matheus Izvekov <mizvekov@gmail.com> wrote:
> On Friday, September 26, 2014 7:34:16 AM UTC-3, Matheus Izvekov wrote:
>>
>> Now we just have to go back in time and stop gnu::xxxx from being allowed
>> under [[ ]] ....
>
>
> So, maybe a syntax that fits better with the current situation would be to
> have a '!' prefix for attributes.
> If they are prefixed by !, the compiler is required to either support them
> or diagnose, if they are not prefixed, the compiler can just ignore them.
>
> And so perhaps reflection would only works on attributes prefixed with '!'.
>
> Seems like a fair compromise?

A couple of items:

1) reflection doesn't support attributes at all? Fine by me.
2) reflection support for attributes is implementation-specific? Fine.

I prefer those to this suggestion of yours, since I don't see a
benefit of making
the rules stricter in the case of attributes in general, and especially for
attributes in the context of reflection.

--

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

On Friday, September 26, 2014 8:32:01 AM UTC-3, Ville Voutilainen wrote:
>
> I prefer those to this suggestion of yours, since I don't see a
> benefit of making
> the rules stricter in the case of attributes in general, and especially
> for
> attributes in the context of reflection.
>

Well, I am just concerned with the situation that currently implementations
are allowed to either diagnose or ignore a missing attribute,
and this could break for user programs that rely on any semantic effect of
attributes in order to work at all.
There is no way with the current rules to specify that an attribute is
required, in a standard way at least. Don't you think that's a problem?

--

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

<div dir=3D"ltr">On Friday, September 26, 2014 8:32:01 AM UTC-3, Ville Vout=
ilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I prefer those t=
o this suggestion of yours, since I don't see a
<br>benefit of making
<br>the rules stricter in the case of attributes in general, and especially=
 for
<br>attributes in the context of reflection.
<br></blockquote><div><br>Well, I am just concerned with the situation that=
 currently implementations are allowed to either diagnose or ignore a missi=
ng attribute,<br>and this could break for user programs that rely on any se=
mantic effect of attributes in order to work at all.<br>There is no way wit=
h the current rules to specify that an attribute is required, in a standard=
 way at least. Don't you think that's a problem?<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 />

------=_Part_12_1982316731.1411731435334--

.

On 26 September 2014 14:37, Matheus Izvekov <mizvekov@gmail.com> wrote:
> Well, I am just concerned with the situation that currently implementations
> are allowed to either diagnose or ignore a missing attribute,
> and this could break for user programs that rely on any semantic effect of
> attributes in order to work at all.
> There is no way with the current rules to specify that an attribute is
> required, in a standard way at least. Don't you think that's a problem?

No. How is it a problem? Standard attributes have no semantic effect,
the effects of implementation-defined attributes are outside the scope of
the standard. Why should the standard try to change any of that? If the
standard tries to invent a syntax for "support for this attribute is required,
else ill-formed", do you think it will succeed in the committee? Do you think
it will succeed on the practical implementation level? I don't.

--

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

On Friday, September 26, 2014 9:04:53 AM UTC-3, Ville Voutilainen wrote:
>
> No. How is it a problem?


Adding support for reflection would add semantic effect, even if trivial,
to existing standard attributes.
So it would start to be possible that some program would break if some
implementation failed to support one of them.

The '!' prefix idea could be even made to allow implementations to
optionally support attrib reflection.
For example, a compiler that implements [[ noreturn ]], but does not
implement reflection, could accept [[ noreturn ]] but diagnose [[ !noreturn
]]


> Standard attributes have no semantic effect,
> the effects of implementation-defined attributes are outside the scope of
> the standard.
>

That's a bit extreme, just because impl-defined attribs are outside the
scope of the standard, does not mean the standard cannot take measures
to regulate them and make the situation less chaotic. See for example the
opengl standard, they take measures to regulate vendor extensions,
so that it does not become wild west territory.


> Why should the standard try to change any of that? If the
> standard tries to invent a syntax for "support for this attribute is
> required,
> else ill-formed", do you think it will succeed in the committee?


Well, I suppose that if they want to allow semantic changes with standard
attribs, then yeah, this could be a possibility.


> Do you think
> it will succeed on the practical implementation level? I don't.
>

I don't know, but you have not made any convincing arguments on this issue
yet either :)

While I respect your opinion, I'll wait on other people's feedback on this
issue.
If there is interest I would gladly spend my time writing a paper on 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/.

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

<div dir=3D"ltr">On Friday, September 26, 2014 9:04:53 AM UTC-3, Ville Vout=
ilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">No. How is it a =
problem?</blockquote><div><br>Adding support for reflection would add seman=
tic effect, even if trivial, to existing standard attributes.<br>So it woul=
d start to be possible that some program would break if some implementation=
 failed to support one of them.<br><br>The '!' prefix idea could be even ma=
de to allow implementations to optionally support attrib reflection.<br>For
 example, a compiler that implements [[ noreturn ]], but does not=20
implement reflection, could accept [[ noreturn ]] but diagnose [[=20
!noreturn ]] <br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">S=
tandard attributes have no semantic effect,
<br>the effects of implementation-defined attributes are outside the scope =
of
<br>the standard.<br></blockquote><div><br>That's a bit extreme, just becau=
se impl-defined attribs are outside the scope of the standard, does not mea=
n the standard cannot take measures<br>to regulate them and make the situat=
ion less chaotic. See for example the opengl standard, they take measures t=
o regulate vendor extensions,<br>so that it does not become wild west terri=
tory.<br></div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"> Why should the standard try to change any of that? If the
<br>standard tries to invent a syntax for "support for this attribute is re=
quired,
<br>else ill-formed", do you think it will succeed in the committee?</block=
quote><div><br>Well, I suppose that if they want to allow semantic changes =
with standard attribs, then yeah, this could be a possibility.<br>&nbsp;</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"> Do you think
<br>it will succeed on the practical implementation level? I don't.
<br></blockquote><div><br>I don't know, but you have not made any convincin=
g arguments on this issue yet either :)<br><br>While I respect your opinion=
, I'll wait on other people's feedback on this issue.<br>If there is intere=
st I would gladly spend my time writing a paper on this.<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 />

------=_Part_408_520103005.1411734213863--

.

On 26 September 2014 15:23, Matheus Izvekov <mizvekov@gmail.com> wrote:
> On Friday, September 26, 2014 9:04:53 AM UTC-3, Ville Voutilainen wrote:
>>
>> No. How is it a problem?
>
>
> Adding support for reflection would add semantic effect, even if trivial, to
> existing standard attributes.
> So it would start to be possible that some program would break if some
> implementation failed to support one of them.

Yes, unless we say from the get-go that whether reflection returns information
about any attributes remains implementation-defined.

> The '!' prefix idea could be even made to allow implementations to
> optionally support attrib reflection.
> For example, a compiler that implements [[ noreturn ]], but does not
> implement reflection, could accept [[ noreturn ]] but diagnose [[ !noreturn
> ]]

A compiler could also diagnose uses of reflection on attributes if it so
chooses. The question is what we allow an implementation to do and what
we require from it.

>> Standard attributes have no semantic effect,
>> the effects of implementation-defined attributes are outside the scope of
>> the standard.
> That's a bit extreme, just because impl-defined attribs are outside the
> scope of the standard, does not mean the standard cannot take measures
> to regulate them and make the situation less chaotic. See for example the
> opengl standard, they take measures to regulate vendor extensions,
> so that it does not become wild west territory.

I don't think they succeed in avoiding a wild-west territory. It seems to me
that the whole point of attributes with an attribute-namespace is to allow
the inevitable wild-west with minimal impact on the attribute support in
the standard proper.

--

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

On Friday, September 26, 2014 9:34:52 AM UTC-3, Ville Voutilainen wrote:
>
> Yes, unless we say from the get-go that whether reflection returns
> information
> about any attributes remains implementation-defined.
>

Sure, but allowing a standard way for users to require an attrib to be
implemented would make
the situation less implementation defined.

It would give the same sort of control a user has in being able to query
thru numeric_limits some type's implementation defined
characteristic, it allows them to static_assert and error out when he needs
something that is not provided.

This would be completely pointless if "meaningful" attribs are never
supported.
But suppose you have a master plan for supporting them.
The biggest obstacle I think would be that attribs are meant to be
ignorable without ill-effects.
What would be a better idea to convince the committee to support them, then?


> A compiler could also diagnose uses of reflection on attributes if it so
> chooses. The question is what we allow an implementation to do and what
> we require from it.
>

Sure, but that only covers the specific case of reflection.

I don't think they succeed in avoiding a wild-west territory. It seems to
> me
> that the whole point of attributes with an attribute-namespace is to allow
> the inevitable wild-west with minimal impact on the attribute support in
> the standard proper.
>

I do agree with the above, but I think the situation can be improved, so it
becomes a bit less like a Sam Peckinpah kind of west,
and more like a Sergio Leone kind, perhaps? :)

--

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

<div dir=3D"ltr">On Friday, September 26, 2014 9:34:52 AM UTC-3, Ville Vout=
ilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Yes, unless we s=
ay from the get-go that whether reflection returns information
<br>about any attributes remains implementation-defined.
<br></blockquote><div><br>Sure, but allowing a standard way for users to re=
quire an attrib to be implemented would make<br>the situation less implemen=
tation defined.<br><br>It would give the same sort of control a user has in=
 being able to query thru numeric_limits some type's implementation defined=
<br>characteristic, it allows them to static_assert and error out when he n=
eeds something that is not provided.<br><br>This would be completely pointl=
ess if "meaningful" attribs are never supported.<br>But suppose you have a =
master plan for supporting them.<br>The biggest obstacle I think would be t=
hat attribs are meant to be ignorable without ill-effects.<br>What would be=
 a better idea to convince the committee to support them, then?<br>&nbsp;</=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">
A compiler could also diagnose uses of reflection on attributes if it so
<br>chooses. The question is what we allow an implementation to do and what
<br>we require from it.
<br></blockquote><div><br>Sure, but that only covers the specific case of r=
eflection.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I don'=
t think they succeed in avoiding a wild-west territory. It seems to me
<br>that the whole point of attributes with an attribute-namespace is to al=
low
<br>the inevitable wild-west with minimal impact on the attribute support i=
n
<br>the standard proper.
<br></blockquote><div><br>I do agree with the above, but I think the situat=
ion can be improved, so it becomes a bit less like a Sam Peckinpah kind of =
west,<br>and more like a Sergio Leone kind, perhaps? :)<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 />

------=_Part_370_1623019897.1411736450547--

.

On 26 September 2014 16:00, Matheus Izvekov <mizvekov@gmail.com> wrote:
> This would be completely pointless if "meaningful" attribs are never
> supported.
> But suppose you have a master plan for supporting them.
> The biggest obstacle I think would be that attribs are meant to be ignorable
> without ill-effects.
> What would be a better idea to convince the committee to support them, then?

I must say I don't know. There seems to be strong support in the committee for
the view that an implementation should be allowed to ignore attributes, ignore
meaning parse and throw away without any analysis.

>> I don't think they succeed in avoiding a wild-west territory. It seems to
>> me
>> that the whole point of attributes with an attribute-namespace is to allow
>> the inevitable wild-west with minimal impact on the attribute support in
>> the standard proper.
> I do agree with the above, but I think the situation can be improved, so it
> becomes a bit less like a Sam Peckinpah kind of west,
> and more like a Sergio Leone kind, perhaps? :)

I'm not opposed to that personally, but I'm not sure whether placing
restrictions
in the standard will help. Note that I don't like non-portable
attributes, at all.
I hate with a passion attributes that some implementations use to eg. designate
how to parallelize programs and where to run tasks, especially when ignoring
such attributes will mean that the program will not work. I hate such
things enough
that they sometimes make me think it was a mistake to add standard attributes
to C++.

--

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

On Friday, September 26, 2014 10:17:36 AM UTC-3, Ville Voutilainen wrote:
>
> I must say I don't know. There seems to be strong support in the committee
> for
> the view that an implementation should be allowed to ignore attributes,
> ignore
> meaning parse and throw away without any analysis.
>

I see, and while not ideal, I would have been fine by that.
The problem is that the standard encouraged implementation-specific
attributes, ie reserved them namespaces.
And it did not require those attributes to follow those rules about being
ignorable, which is very unfortunate.

I see two "fine by me" solutions: Go back and prohibit impl specific
"meaningful" attribs, or go ahead and allow a standard way for a user to
specify requirement on them.


> I'm not opposed to that personally, but I'm not sure whether placing
> restrictions
> in the standard will help. Note that I don't like non-portable
> attributes, at all.
> I hate with a passion attributes that some implementations use to eg.
> designate
> how to parallelize programs and where to run tasks, especially when
> ignoring
> such attributes will mean that the program will not work. I hate such
> things enough
> that they sometimes make me think it was a mistake to add standard
> attributes
> to C++.
>

Well, if you do embedded works you start to like them... They help avoid
going into assembly territory for simple things.

And it's quite handy that you can use the same attribs in gcc and clang the
same as is, without any preprocessor tricks.

It ended up with a defacto standard that was defined by GNU, but as the
standards body has their hand on it now,
maybe MSVC can be pressured into at least accepting the same syntax for the
attribs it does support in common.
And if this happens because of '[[ xxx::attr ]] syntax, then the situation
only got better.

Or to put it another way, if the standards committee ignored
vendor-specific attribs, they are still not going away, so why not accept
them and make things better?

--

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

<div dir=3D"ltr">On Friday, September 26, 2014 10:17:36 AM UTC-3, Ville Vou=
tilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I must say I do=
n't know. There seems to be strong support in the committee for
<br>the view that an implementation should be allowed to ignore attributes,=
 ignore
<br>meaning parse and throw away without any analysis.
<br></blockquote><div><br>I see, and while not ideal, I would have been fin=
e by that.<br>The problem is that the standard encouraged implementation-sp=
ecific attributes, ie reserved them namespaces.<br>And it did not require t=
hose attributes to follow those rules about being ignorable, which is very =
unfortunate.<br><br>I see two "fine by me" solutions: Go back and prohibit =
impl specific "meaningful" attribs, or go ahead and allow a standard way fo=
r a user to specify requirement on them.<br>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">
I'm not opposed to that personally, but I'm not sure whether placing
<br>restrictions
<br>in the standard will help. Note that I don't like non-portable
<br>attributes, at all.
<br>I hate with a passion attributes that some implementations use to eg. d=
esignate
<br>how to parallelize programs and where to run tasks, especially when ign=
oring
<br>such attributes will mean that the program will not work. I hate such
<br>things enough
<br>that they sometimes make me think it was a mistake to add standard attr=
ibutes
<br>to C++.<br></blockquote><div><br>Well, if you do embedded works you sta=
rt to like them... They help avoid going into assembly territory for simple=
 things.<br><br>And it's quite handy that you can use the same attribs in g=
cc and clang the same as is, without any preprocessor tricks.<br><br>It end=
ed up with a defacto standard that was defined by GNU, but as the standards=
 body has their hand on it now,<br>maybe MSVC can be pressured into at leas=
t accepting the same syntax for the attribs it does support in common.<br>A=
nd if this happens because of '[[ xxx::attr ]] syntax, then the situation o=
nly got better.<br><br>Or to put it another way, if the standards committee=
 ignored vendor-specific attribs, they are still not going away, so why not=
 accept them and make things better?<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 />

------=_Part_350_1915940626.1411738939807--

.

--001a11c214125570b30503fbbf0f
Content-Type: text/plain; charset=UTF-8

On Fri, Sep 26, 2014 at 2:15 AM, Matheus Izvekov <mizvekov@gmail.com> wrote:

> On Friday, September 26, 2014 6:05:36 AM UTC-3, Ville Voutilainen wrote:
>>
>> That's a bold claim. N4113 doesn't seem to include any sort of
>> attribute support,
>> but I wouldn't think it unpalatable for the committee to include
>> attributes in reflection.
>> Reflection of attributes does not change semantics; it's just a means to
>> query
>> whether a declaration was annotated with an attribute or not.
>>
>
> Well, thanks for the correction. I have been repeating something like that
> and had not been corrected so far.
> My best understanding of what the committee understood as language
> semantics was that their presence could not be "detected", ie they would
> either make the compiler generate different (perhaps more efficient) code,
> but still work "as-if", or that they would (by misuse) make the the program
> ill-formed. But not for example make two well-formed programs behave
> differently only by their presence/absence.
>
> So you are saying that's too extreme? What's your best understanding of
> this rule then?
>

The guideline as I've heard it, for standard attributes, is:

"Removing all instances of a particular attribute from a program should not
change the semantics of that program."

That is, "if a compiler doesn't support the attribute, it can safely ignore
it".

[This means that an attribute can have semantic effects: it cause a program
to be ill-formed, or can cause behavior to be undefined in some
circumstances (because changing from UB to defined behavior does not change
semantics) as [[noreturn]] does. It also means an attribute can say "you
must put this on every declaration in every TU if you put it anywhere, or
else the program is ill-formed, NDR" as [[carries_dependency]] does.]

If we want to keep to the spirit of this guideline, then we can allow
reflection on attributes so long as the reflection mechanism doesn't reveal
whether the compiler supports the attribute or not. That would mean that
compilers can no longer choose to ignore attribute-lists entirely, but
still don't need to know what any particular attribute means.

--

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

--001a11c214125570b30503fbbf0f
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 F=
ri, Sep 26, 2014 at 2:15 AM, Matheus Izvekov <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mizvekov@gmail.com" target=3D"_blank">mizvekov@gmail.com</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span cla=
ss=3D"">On Friday, September 26, 2014 6:05:36 AM UTC-3, Ville Voutilainen w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex">That&#39;s a bold claim. N4113=
 doesn&#39;t seem to include any sort of
<br>attribute support,
<br>but I wouldn&#39;t think it unpalatable for the committee to include
<br>attributes in reflection.
<br>Reflection of attributes does not change semantics; it&#39;s just a mea=
ns to query
<br>whether a declaration was annotated with an attribute or not.
<br></blockquote></span><div><br>Well, thanks for the correction. I have be=
en repeating something like that and had not been corrected so far.<br>My b=
est understanding of what the committee understood as language semantics wa=
s that their presence could not be &quot;detected&quot;, ie they would eith=
er make the compiler generate different (perhaps more efficient) code, but =
still work &quot;as-if&quot;, or that they would (by misuse) make the the p=
rogram ill-formed. But not for example make two well-formed programs behave=
 differently only by their presence/absence.<br><br>So you are saying that&=
#39;s too extreme? What&#39;s your best understanding of this rule then?</d=
iv></div></blockquote><div><br></div><div>The guideline as I&#39;ve heard i=
t, for standard attributes, is:</div><div><br></div><div>&quot;Removing all=
 instances of a particular attribute from a program should not change the s=
emantics of that program.&quot;</div><div><br></div><div>That is, &quot;if =
a compiler doesn&#39;t support the attribute, it can safely ignore it&quot;=
..</div><div><br></div><div>[This means that an attribute can have semantic =
effects: it cause a program to be ill-formed, or can cause behavior to be u=
ndefined in some circumstances (because changing from UB to defined behavio=
r does not change semantics) as [[noreturn]] does. It also means an attribu=
te can say &quot;you must put this on every declaration in every TU if you =
put it anywhere, or else the program is ill-formed, NDR&quot; as [[carries_=
dependency]] does.]</div><div><br></div><div>If we want to keep to the spir=
it of this guideline, then we can allow reflection on attributes so long as=
 the reflection mechanism doesn&#39;t reveal whether the compiler supports =
the attribute or not. That would mean that compilers can no longer choose t=
o ignore attribute-lists entirely, but still don&#39;t need to know what an=
y particular attribute means.</div></div></div></div>

<p></p>

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

--001a11c214125570b30503fbbf0f--

.

------=_Part_785_471309269.1411769748886
Content-Type: text/plain; charset=UTF-8

On Friday, September 26, 2014 3:04:27 PM UTC-3, Richard Smith wrote:
>
> If we want to keep to the spirit of this guideline, then we can allow
> reflection on attributes so long as the reflection mechanism doesn't reveal
> whether the compiler supports the attribute or not. That would mean that
> compilers can no longer choose to ignore attribute-lists entirely, but
> still don't need to know what any particular attribute means.
>

Sure, that sounds workable, but still, I think a compelling use case for
such reflection has to be made.
Maybe I am being short sighted, but I can't see much use for it unless you
are able to guarantee the attribute has any effect at all.

A second problem with that approach is that it would open the gates for
"programmer invented attributes".

[[ xyzzy::cool_function ]] void foo();

Attributes not recognized by any known implementation, used just for their
reflection effect.

Are we sure we want to go there at all?
If we do, maybe it's best to reserve a namespace for them (like user::) and
mandate that all implementations ignore them except for reflection purposes.


--

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

<div dir=3D"ltr">On Friday, September 26, 2014 3:04:27 PM UTC-3, Richard Sm=
ith wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><di=
v><div class=3D"gmail_quote"><div></div><div>If we want to keep to the spir=
it of this guideline, then we can allow reflection on attributes so long as=
 the reflection mechanism doesn't reveal whether the compiler supports the =
attribute or not. That would mean that compilers can no longer choose to ig=
nore attribute-lists entirely, but still don't need to know what any partic=
ular attribute means.</div></div></div></div></blockquote><div><br>Sure, th=
at sounds workable, but still, I think a compelling use case for such refle=
ction has to be made.<br>Maybe I am being short sighted, but I can't see mu=
ch use for it unless you are able to guarantee the attribute has any effect=
 at all.<br><br>A second problem with that approach is that it would open t=
he gates for "programmer invented attributes".<br><br><div class=3D"prettyp=
rint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187,=
 187, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"=
><code class=3D"prettyprint"><div class=3D"subprettyprint"><div class=3D"pr=
ettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb=
(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-w=
ord;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #660;" class=3D"styled-by-prettify">[[</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> xyzzy</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">cool_function </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">]]</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> foo</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">();</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span></div></code></div><span style=3D"color: #660;" class=3D"styled-by-p=
rettify"></span></div></code></div><br>Attributes not recognized by any kno=
wn implementation, used just for their reflection effect.<br><br>Are we sur=
e we want to go there at all?<br>If we do, maybe it's best to reserve a nam=
espace for them (like user::) and mandate that all implementations ignore t=
hem except for reflection purposes.<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&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_785_471309269.1411769748886--

.

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

On Fri, Sep 26, 2014 at 8:04 PM, Richard Smith <richard@metafoo.co.uk>
wrote:

> If we want to keep to the spirit of this guideline, then we can allow
> reflection on attributes so long as the reflection mechanism doesn't reveal
> whether the compiler supports the attribute or not. That would mean that
> compilers can no longer choose to ignore attribute-lists entirely, but
> still don't need to know what any particular attribute means.
>

Correct.  My draft design for attribute reflection specifies an encoding of
a token sequence, that corresponds to the `attribute-list` grammar, into a
compile-time string.  These compile-time strings would then be exposed in a
similar fashion to N4113.  This transformation is agnostic to the semantics
of the attribute (if any).

So for example the attribute-specifier:

[[foo    ("bar"{ /*baz */ 42}}]]

might be encoded (just before translation phase 7) into the compile-time
string "foo ( \"bar\" { 42 } }"

which you might get from std::some_entity_tbd::attribute_v<x,y,z>.  You can
then (re)parse this with constexpr programming.

There are still a lot of details to work out, and this would be something
for a second version (separate proposal) after the proposal rev-chain
N3815->N4113 (hopefully) gets adopted with the basic reflection
functionality.

--

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

--089e0158b0345fa8560504014e9d
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 F=
ri, Sep 26, 2014 at 8:04 PM, Richard Smith <span dir=3D"ltr">&lt;<a href=3D=
"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bord=
er-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_=
extra"><div class=3D"gmail_quote"><div>If we want to keep to the spirit of =
this guideline, then we can allow reflection on attributes so long as the r=
eflection mechanism doesn&#39;t reveal whether the compiler supports the at=
tribute or not. That would mean that compilers can no longer choose to igno=
re attribute-lists entirely, but still don&#39;t need to know what any part=
icular attribute means.</div></div></div></div></blockquote><div><br></div>=
<div>Correct.=C2=A0 My draft design for attribute reflection specifies an e=
ncoding of a token sequence, that corresponds to the `attribute-list` gramm=
ar, into a compile-time string.=C2=A0 These compile-time strings would then=
 be exposed in a similar fashion to N4113.=C2=A0 This transformation is agn=
ostic to the semantics of the attribute (if any).</div><div><br></div><div>=
So for example the attribute-specifier:</div><div><br></div><div>[[foo =C2=
=A0 =C2=A0(&quot;bar&quot;{ /*baz */ 42}}]]</div><div><br></div><div>might =
be encoded (just before translation phase 7) into the compile-time string &=
quot;foo ( \&quot;bar\&quot; { 42 } }&quot;</div><div><br></div><div>which =
you might get from std::some_entity_tbd::attribute_v&lt;x,y,z&gt;.=C2=A0 Yo=
u can then (re)parse this with constexpr programming.</div><div><br></div><=
div>There are still a lot of details to work out, and this would be somethi=
ng for a second version (separate proposal) after the proposal rev-chain N3=
815-&gt;N4113 (hopefully) gets adopted with the basic reflection functional=
ity.</div><div><br></div></div></div></div>

<p></p>

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

--089e0158b0345fa8560504014e9d--

.

------=_Part_941_591263441.1411785123626
Content-Type: text/plain; charset=UTF-8

On Friday, September 26, 2014 9:42:23 PM UTC-3, Andrew Tomazos wrote:
>
> which you might get from std::some_entity_tbd::attribute_v<x,y,z>.  You
> can then (re)parse this with constexpr programming.
>
> There are still a lot of details to work out, and this would be something
> for a second version (separate proposal) after the proposal rev-chain
> N3815->N4113 (hopefully) gets adopted with the basic reflection
> functionality.
>

That looks great, but it has a lot of potential for abuse. As I said above,
programmers can start to invent new attribute names just to annotate some
entity with a property they are supposed to have.
And then you can do all sorts of things like multiple overloads /
specialization based on attributes, and then things start getting very
complex.

Now if a programmer mistypes [[ user::idenpotent ]] instead of [[
user::idempotent ]], it can cause serious breakage depending on the meaning
that attribute has in the program. And the way the syntax for them works is
that there is no way to diagnose this error.
So to fix that, we introduce a rule that user attributes must be declared
first before use... More complexity :)

--

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

<div dir=3D"ltr">On Friday, September 26, 2014 9:42:23 PM UTC-3, Andrew Tom=
azos wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><d=
iv><div class=3D"gmail_quote"><div>which you might get from std::some_entit=
y_tbd::<wbr>attribute_v&lt;x,y,z&gt;.&nbsp; You can then (re)parse this wit=
h constexpr programming.</div><div><br></div><div>There are still a lot of =
details to work out, and this would be something for a second version (sepa=
rate proposal) after the proposal rev-chain N3815-&gt;N4113 (hopefully) get=
s adopted with the basic reflection functionality.</div></div></div></div><=
/blockquote><div><br>That looks great, but it has a lot of potential for ab=
use. As I said above, programmers can start to invent new attribute names j=
ust to annotate some entity with a property they are supposed to have.<br>A=
nd then you can do all sorts of things like multiple overloads / specializa=
tion based on attributes, and then things start getting very complex.<br><b=
r>Now if a programmer mistypes [[ user::idenpotent ]] instead of [[ user::i=
dempotent ]], it can cause serious breakage depending on the meaning that a=
ttribute has in the program. And the way the syntax for them works is that =
there is no way to diagnose this error.<br>So to fix that, we introduce a r=
ule that user attributes must be declared first before use... More complexi=
ty :)<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 />

------=_Part_941_591263441.1411785123626--

.

------=_Part_1592_1796621815.1411787739000
Content-Type: text/plain; charset=UTF-8

On Friday, September 26, 2014 5:42:23 PM UTC-7, Andrew Tomazos wrote:
>
> On Fri, Sep 26, 2014 at 8:04 PM, Richard Smith <ric...@metafoo.co.uk
> <javascript:>> wrote:
>
>> If we want to keep to the spirit of this guideline, then we can allow
>> reflection on attributes so long as the reflection mechanism doesn't reveal
>> whether the compiler supports the attribute or not. That would mean that
>> compilers can no longer choose to ignore attribute-lists entirely, but
>> still don't need to know what any particular attribute means.
>>
>
> Correct.  My draft design for attribute reflection specifies an encoding
> of a token sequence, that corresponds to the `attribute-list` grammar, into
> a compile-time string.  These compile-time strings would then be exposed in
> a similar fashion to N4113.  This transformation is agnostic to the
> semantics of the attribute (if any).
>
> So for example the attribute-specifier:
>
> [[foo    ("bar"{ /*baz */ 42}}]]
>
> might be encoded (just before translation phase 7) into the compile-time
> string "foo ( \"bar\" { 42 } }"
>
> which you might get from std::some_entity_tbd::attribute_v<x,y,z>.  You
> can then (re)parse this with constexpr programming.
>
> There are still a lot of details to work out, and this would be something
> for a second version (separate proposal) after the proposal rev-chain
> N3815->N4113 (hopefully) gets adopted with the basic reflection
> functionality.
>
>
Why does it have to be a string?  Like, why couldn't it be something like
this?


// They don't have to exist or be understood by the compiler,
// so we need to declare them.
namespace std
{
    namespace attribute
    {
        struct noreturn;
        struct deprecated;
    }
}

// Prints 1
std::printf("%d\n", std::attributes_of_t<std::exit>::has_attribute<std::
attribute::noreturn>::value);

// Prints 1
std::printf("%d\n", std::is_same<std::attributes_of_t<bzero>::attribute<0>::
type,
    std::attribute::deprecated>::value);
// Prints 1
std::printf("%d\n", std::attributes_of_t<bzero>::attribute<0>::param<0>::
exists);
// Prints 0
std::printf("%d\n", std::attributes_of_t<bzero>::attribute<0>::param<0>::
is_type);
// Prints 1
std::printf("%d\n", std::attributes_of_t<bzero>::attribute<0>::param<0>::
is_value);
// Prints typeid(const char [19]).name()
std::printf("%s\n", typeid(std::attributes_of_t<bzero>::attribute<0>::param<
0>::type).name());
// Prints "use memset instead"
std::printf("%s\n", std::attributes_of_t<bzero>::attribute<0>::param<0>::
value);



Melissa


--

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

<div dir=3D"ltr">On Friday, September 26, 2014 5:42:23 PM UTC-7, Andrew Tom=
azos wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><d=
iv><div class=3D"gmail_quote">On Fri, Sep 26, 2014 at 8:04 PM, Richard Smit=
h <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"xVPQK0aSAlMJ" onmousedown=3D"this.href=3D'javascript:';retu=
rn true;" onclick=3D"this.href=3D'javascript:';return true;">ric...@metafoo=
..co.uk</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,20=
4,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><div=
 class=3D"gmail_quote"><div>If we want to keep to the spirit of this guidel=
ine, then we can allow reflection on attributes so long as the reflection m=
echanism doesn't reveal whether the compiler supports the attribute or not.=
 That would mean that compilers can no longer choose to ignore attribute-li=
sts entirely, but still don't need to know what any particular attribute me=
ans.</div></div></div></div></blockquote><div><br></div><div>Correct.&nbsp;=
 My draft design for attribute reflection specifies an encoding of a token =
sequence, that corresponds to the `attribute-list` grammar, into a compile-=
time string.&nbsp; These compile-time strings would then be exposed in a si=
milar fashion to N4113.&nbsp; This transformation is agnostic to the semant=
ics of the attribute (if any).</div><div><br></div><div>So for example the =
attribute-specifier:</div><div><br></div><div>[[foo &nbsp; &nbsp;("bar"{ /*=
baz */ 42}}]]</div><div><br></div><div>might be encoded (just before transl=
ation phase 7) into the compile-time string "foo ( \"bar\" { 42 } }"</div><=
div><br></div><div>which you might get from std::some_entity_tbd::<wbr>attr=
ibute_v&lt;x,y,z&gt;.&nbsp; You can then (re)parse this with constexpr prog=
ramming.</div><div><br></div><div>There are still a lot of details to work =
out, and this would be something for a second version (separate proposal) a=
fter the proposal rev-chain N3815-&gt;N4113 (hopefully) gets adopted with t=
he basic reflection functionality.</div><div><br></div></div></div></div></=
blockquote><div><br>Why does it have to be a string?&nbsp; Like, why couldn=
't it be something like this?<br><div><br><br><div class=3D"prettyprint" st=
yle=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 18=
7); border-style: solid; border-width: 1px; word-wrap: break-word;"><code c=
lass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #8=
00;" class=3D"styled-by-prettify">// They don't have to exist or be underst=
ood by the compiler,</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span><span style=3D"color: #800;" class=3D"styled-by-pretti=
fy">// so we need to declare them.</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">namespace</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> std<br></span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br>&nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">namespace</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> attribute<br>&nbsp; &nbsp; </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> noreturn</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> deprecated</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br><br></span><span style=3D"color: #800;" clas=
s=3D"styled-by-prettify">// Prints 1</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br>std</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">printf</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(</span><span style=3D"color: #080;" class=3D"styled-by-prettif=
y">"%d\n"</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">attributes_of_t</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">exit</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">&gt;::</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">has_attribute</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">attribute</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
noreturn</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&g=
t;::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">value<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><spa=
n style=3D"color: #800;" class=3D"styled-by-prettify">// Prints 1</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br>std</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">printf</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #080;=
" class=3D"styled-by-prettify">"%d\n"</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">is_same</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">std</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">attributes_of_t</spa=
n><span style=3D"color: #080;" class=3D"styled-by-prettify">&lt;bzero&gt;</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">attribute</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span styl=
e=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&gt;::</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">type</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>&nbsp; &nbsp; std</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">attribute</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">deprecated</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&gt;::</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">value</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span><span style=3D"color: #800;" class=3D"styled-by-prettify">// Prin=
ts 1</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>st=
d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">printf</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #080;" class=3D"styled-by-prettify">"%d\n"</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">attributes_of_t</span><span style=3D"color: #080;" clas=
s=3D"styled-by-prettify">&lt;bzero&gt;</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">attribute</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">&lt;</span><span style=3D"color: #066;" class=3D"styled-=
by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">&gt;::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
param</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;<=
/span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">&gt;::</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">exists</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #80=
0;" class=3D"styled-by-prettify">// Prints 0</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br>std</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">printf</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #080;" class=3D"styled-by=
-prettify">"%d\n"</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> s=
td</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">attributes_of_t<=
/span><span style=3D"color: #080;" class=3D"styled-by-prettify">&lt;bzero&g=
t;</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">attribute</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span =
style=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">&gt;::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">param</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #066;" c=
lass=3D"styled-by-prettify">0</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">&gt;::</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">is_type</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify">//=
 Prints 1</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">printf</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #080;" class=3D"styled-by-prettify">"%d\n"</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">attributes_of_t</span><span style=3D"color: #080;" =
class=3D"styled-by-prettify">&lt;bzero&gt;</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">attribute</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;</span><span style=3D"color: #066;" class=3D"st=
yled-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&gt;::</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">param</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
&lt;</span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;::</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">is_value</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #800;" class=3D"styled-by-prettify">// Prints typeid(const char [19]).=
name()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">printf</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #080;" class=3D"styled-by-prettify">"%s\n"</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">typeid</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">att=
ributes_of_t</span><span style=3D"color: #080;" class=3D"styled-by-prettify=
">&lt;bzero&gt;</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">att=
ribute</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;=
</span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&gt;::</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">param</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #066;" class=3D"styled-by-prettify">0</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">&gt;::</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">type</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">).</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">name</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">());</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify">//=
 Prints "use memset instead"</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>std</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">printf</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><span style=3D"color: #080;" class=3D"styled-by-prettify">"%s\n"=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">attributes_of_t</span><span style=
=3D"color: #080;" class=3D"styled-by-prettify">&lt;bzero&gt;</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">attribute</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #=
066;" class=3D"styled-by-prettify">0</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">&gt;::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">param</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">&lt;</span><span style=3D"color: #066;" class=3D"styled-=
by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">&gt;::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
value</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</s=
pan></div></code></div><br><br><br>Melissa<br></div>&nbsp;</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 />

------=_Part_1592_1796621815.1411787739000--

.

------=_Part_2734_753548564.1411941158756
Content-Type: text/plain; charset=UTF-8

Lots of interesting debate, but to be utterly frank, user-defined
attributes are all but required for reflection to actually be useful for
any of the interesting use cases for reflection.

The bare basic bog-standard example of reflection is serialization. A
simple actually-usable-in-practice XML serialization library needs to allow
uses to note which fields are serializable, what names to use, whether to
serialize members as elements or attributes, options for how containers are
serialized, etc. deserialization semantics for smart pointers as well as
dynamic types, etc. Without a way to specify all that users will just be
forced to build their own library-based reflection systems (using macros
and templates and lots of manual repetition, like we already do today in
C++03) in order to actually do anything interesting.

I don't think there's any realistic debate here about whether reflection of
user-defined attributes are needed. They are. The only question is "what
should it look like" ?

I for one am in favor of explicit definitions. Something like (the syntax
itself is irrelevant):

  namespace serialization {
    // an attribute, which must be usable as a constexpr value type
    struct xml attribute
    {
      // std::string name;  // not allowed, not constexpr-constructible
      char const* name; // allowed for constexpr

      // xml (char const*); // not allowed, not constexpr
      constexpr xml(char const* name, enum node_type = element); // allowed
    };
  }

  // specify the XML element name this class with serialize with
  // as an aside, I think the C++ generalized attribute syntax is terrible;
it's totally non-obvious to normal users
  // that placing the [[]] before `class` is valid code but has an entirely
different and unintended meaning. that ship has sailed, though.
  class [[serialization::xml{"ns::Bar"}]] bar {
    // specify that this member serializes as an XML attribute with the
given name
    int [[serialization::xml{"ns::BaxValue", serialization::attribute}]]
bax;
  };

  // querying attributes is also constexpr
  // attr0 here is an instance of serialization::xml constructed with xml{"bar",
element}
  constexpr auto attr0 = std::reflect::attribute_v<bar, 0>;

  // attr1 should be obvious (ignoring the strawman reflection library shim)
  constexpr auto attr1 =
std::reflect::attribute_v<std::reflect::member<bar, 0>, 0>;

This system has several benefits: (1) spelling mistakes are compile-time
detected, (2) zero run-time overhead is mandated, (3) zero
compiled-binary-size overhead is mandated, (4) integrates with tools, and
(5) provides flexibility to users who understand their problem domains far
better than could be expected of us or the committee.

(4) is a super huge primary reason that I utterly reject a string-based
approach. We really want to use a tools-first mentality to any language or
library extension. Code isn't text. Code is structure and semantics. Text
is just the way we express program source and make it easy to read and
write. The very first thing a compiler, or a tool, or your human brain does
is convert that textual representation into structured semantics. A
text-based attribute language would still let our brains do that but
utterly subverts the ability for tools to do it, especially for
user-defined attributes.

In order to help with the problems noted in the aside in that code sample,
it may also be useful to let user-defined attributes explicitly declare
whether they apply to types definitions, declared types in other
definitions, variable/member definitions, variables or functions, etc. Then
at least a misplaced attribute could raise a helpful compile-time
warning/error.

--

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

<div dir=3D"ltr">Lots of interesting debate, but to be utterly frank, user-=
defined attributes are all but required for reflection to actually be usefu=
l for any of the interesting use cases for reflection.<div><br></div><div>T=
he bare basic bog-standard example of reflection is serialization. A simple=
 actually-usable-in-practice XML serialization library needs to allow uses =
to note which fields are serializable, what names to use, whether to serial=
ize members as elements or attributes, options for how containers are seria=
lized, etc. deserialization semantics for smart pointers as well as dynamic=
 types, etc. Without a way to specify all that users will just be forced to=
 build their own library-based reflection systems (using macros and templat=
es and lots of manual repetition, like we already do today in C++03) in ord=
er to actually do anything interesting.</div><div><br></div><div>I don't th=
ink there's any realistic debate here about whether reflection of user-defi=
ned attributes are needed. They are. The only question is "what should it l=
ook like" ?</div><div><br></div><div>I for one am in favor of explicit defi=
nitions. Something like (the syntax itself is irrelevant):</div><div><br></=
div><div><font face=3D"courier new, monospace">&nbsp; namespace serializati=
on {</font></div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; /=
/ an attribute, which must be usable as a constexpr value type</font></div>=
<div><font face=3D"courier new, monospace">&nbsp; &nbsp; struct xml attribu=
te</font></div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; {</=
font></div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; &nbsp; =
// std::string name; &nbsp;// not allowed, not constexpr-constructible</fon=
t></div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; &nbsp; cha=
r const* name; // allowed for constexpr</font></div><div><font face=3D"cour=
ier new, monospace"><br></font></div><div><font face=3D"courier new, monosp=
ace">&nbsp; &nbsp; &nbsp; //&nbsp;</font><span style=3D"font-family: 'couri=
er new', monospace;">xml&nbsp;</span><font face=3D"courier new, monospace">=
(char const*); // not allowed, not constexpr</font></div><div><font face=3D=
"courier new, monospace">&nbsp; &nbsp; &nbsp; constexpr&nbsp;</font><span s=
tyle=3D"font-family: 'courier new', monospace;">xml</span><font face=3D"cou=
rier new, monospace">(char const* name, enum node_type =3D element); // all=
owed</font></div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; }=
;</font></div><div><font face=3D"courier new, monospace">&nbsp; }</font></d=
iv><div><font face=3D"courier new, monospace"><br></font></div><div><font f=
ace=3D"courier new, monospace">&nbsp; // specify the XML element name this =
class with serialize with</font></div><div><font face=3D"courier new, monos=
pace">&nbsp; // as an aside, I think the C++ generalized attribute syntax i=
s terrible; it's totally non-obvious to normal users</font></div><div><font=
 face=3D"courier new, monospace">&nbsp; // that placing the [[]] before `cl=
ass` is valid code but has an entirely different and unintended meaning. th=
at ship has sailed, though.</font></div><div><font face=3D"courier new, mon=
ospace">&nbsp; class&nbsp;</font><span style=3D"font-family: 'courier new',=
 monospace;">[[serialization::xml{"ns::Bar"}]]&nbsp;</span><span style=3D"f=
ont-family: 'courier new', monospace;">bar {</span><br></div><div><span sty=
le=3D"font-family: 'courier new', monospace;">&nbsp; &nbsp; // specify that=
 this member serializes as an XML attribute with the given name</span><br><=
/div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; int [[seriali=
zation::xml{"ns::BaxValue", serialization::attribute}]] bax;</font></div><d=
iv><font face=3D"courier new, monospace">&nbsp; };</font></div><div><font f=
ace=3D"courier new, monospace"><br></font></div><div><font face=3D"courier =
new, monospace">&nbsp; // querying attributes is also constexpr</font></div=
><div><font face=3D"courier new, monospace">&nbsp; // attr0 here is an inst=
ance of serialization::</font><span style=3D"font-family: 'courier new', mo=
nospace;">xml&nbsp;</span><font face=3D"courier new, monospace">constructed=
 with&nbsp;</font><span style=3D"font-family: 'courier new', monospace;">xm=
l</span><font face=3D"courier new, monospace">{"bar", element}<br></font></=
div><div><font face=3D"courier new, monospace">&nbsp; constexpr auto attr0 =
=3D std::reflect::attribute_v&lt;bar, 0&gt;;</font></div><div><font face=3D=
"courier new, monospace"><br></font></div><div><font face=3D"courier new, m=
onospace">&nbsp; // attr1 should be obvious (ignoring the strawman reflecti=
on library shim)</font></div><div><font face=3D"courier new, monospace">&nb=
sp; constexpr auto attr1 =3D std::reflect::attribute_v&lt;std::reflect::mem=
ber&lt;bar, 0&gt;, 0&gt;;</font></div><div><br></div><div>This system has s=
everal benefits: (1) spelling mistakes are compile-time detected, (2) zero =
run-time overhead is mandated, (3) zero compiled-binary-size overhead is ma=
ndated, (4) integrates with tools, and (5) provides flexibility to users wh=
o understand their problem domains far better than could be expected of us =
or the committee.</div><div><br></div><div>(4) is a super huge primary reas=
on that I utterly reject a string-based approach. We really want to use a t=
ools-first mentality to any language or library extension. Code isn't text.=
 Code is structure and semantics. Text is just the way we express program s=
ource and make it easy to read and write. The very first thing a compiler, =
or a tool, or your human brain does is convert that textual representation =
into structured semantics. A text-based attribute language would still let =
our brains do that but utterly subverts the ability for tools to do it, esp=
ecially for user-defined attributes.</div><div><br></div><div>In order to h=
elp with the problems noted in the aside in that code sample, it may also b=
e useful to let user-defined attributes explicitly declare whether they app=
ly to types definitions, declared types in other definitions, variable/memb=
er definitions, variables or functions, etc. Then at least a misplaced attr=
ibute could raise a helpful compile-time warning/error.</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 />

------=_Part_2734_753548564.1411941158756--

.

This is a multi-part message in MIME format.
--------------060405090409010902060402
Content-Type: text/plain; charset=UTF-8; format=flowed

I kinda like the fact that in .NET every attribute has to exist as a
type. Not sure how it would apply to C++ considering the recent debate
but it's certainly a sane approach at the whole attribute reflection
thing without having to standardize everything. We don't have many
standard attributes yet, so if we were to say that attributes must be
represented by concrete types (retroactively adding types for the
attribues we now have) it could add a lot of value to any attribute
reflection mechanic and the compiler gets a well defined set of rules
how these attributes are represented (and error out if the used
attributes aren't declared as types anywhere).

Am 28.09.2014 um 23:52 schrieb Sean Middleditch:
> Lots of interesting debate, but to be utterly frank, user-defined
> attributes are all but required for reflection to actually be useful
> for any of the interesting use cases for reflection.
>
> The bare basic bog-standard example of reflection is serialization. A
> simple actually-usable-in-practice XML serialization library needs to
> allow uses to note which fields are serializable, what names to use,
> whether to serialize members as elements or attributes, options for
> how containers are serialized, etc. deserialization semantics for
> smart pointers as well as dynamic types, etc. Without a way to specify
> all that users will just be forced to build their own library-based
> reflection systems (using macros and templates and lots of manual
> repetition, like we already do today in C++03) in order to actually do
> anything interesting.
>
> I don't think there's any realistic debate here about whether
> reflection of user-defined attributes are needed. They are. The only
> question is "what should it look like" ?
>
> I for one am in favor of explicit definitions. Something like (the
> syntax itself is irrelevant):
>
>   namespace serialization {
>     // an attribute, which must be usable as a constexpr value type
>     struct xml attribute
>     {
>       // std::string name;  // not allowed, not constexpr-constructible
>       char const* name; // allowed for constexpr
>
>       // xml (char const*); // not allowed, not constexpr
>       constexpr xml(char const* name, enum node_type = element); //
> allowed
>     };
>   }
>
>   // specify the XML element name this class with serialize with
>   // as an aside, I think the C++ generalized attribute syntax is
> terrible; it's totally non-obvious to normal users
>   // that placing the [[]] before `class` is valid code but has an
> entirely different and unintended meaning. that ship has sailed, though.
>   class [[serialization::xml{"ns::Bar"}]] bar {
>     // specify that this member serializes as an XML attribute with
> the given name
>     int [[serialization::xml{"ns::BaxValue",
> serialization::attribute}]] bax;
>   };
>
>   // querying attributes is also constexpr
>   // attr0 here is an instance of serialization::xml constructed with
> xml{"bar", element}
>   constexpr auto attr0 = std::reflect::attribute_v<bar, 0>;
>
>   // attr1 should be obvious (ignoring the strawman reflection library
> shim)
>   constexpr auto attr1 =
> std::reflect::attribute_v<std::reflect::member<bar, 0>, 0>;
>
> This system has several benefits: (1) spelling mistakes are
> compile-time detected, (2) zero run-time overhead is mandated, (3)
> zero compiled-binary-size overhead is mandated, (4) integrates with
> tools, and (5) provides flexibility to users who understand their
> problem domains far better than could be expected of us or the committee.
>
> (4) is a super huge primary reason that I utterly reject a
> string-based approach. We really want to use a tools-first mentality
> to any language or library extension. Code isn't text. Code is
> structure and semantics. Text is just the way we express program
> source and make it easy to read and write. The very first thing a
> compiler, or a tool, or your human brain does is convert that textual
> representation into structured semantics. A text-based attribute
> language would still let our brains do that but utterly subverts the
> ability for tools to do it, especially for user-defined attributes.
>
> In order to help with the problems noted in the aside in that code
> sample, it may also be useful to let user-defined attributes
> explicitly declare whether they apply to types definitions, declared
> types in other definitions, variable/member definitions, variables or
> functions, etc. Then at least a misplaced attribute could raise a
> helpful compile-time warning/error.
> --
>
> ---
> 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
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

--

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

--------------060405090409010902060402
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">
    I kinda like the fact that in .NET every attribute has to exist as a
    type. Not sure how it would apply to C++ considering the recent
    debate but it's certainly a sane approach at the whole attribute
    reflection thing without having to standardize everything. We don't
    have many standard attributes yet, so if we were to say that
    attributes must be represented by concrete types (retroactively
    adding types for the attribues we now have) it could add a lot of
    value to any attribute reflection mechanic and the compiler gets a
    well defined set of rules how these attributes are represented (and
    error out if the used attributes aren't declared as types anywhere).<br=
>
    <br>
    <div class=3D"moz-cite-prefix">Am 28.09.2014 um 23:52 schrieb Sean
      Middleditch:<br>
    </div>
    <blockquote
      cite=3D"mid:79e7453b-8897-4f4d-a661-321e13741b7a@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">Lots of interesting debate, but to be utterly
        frank, user-defined attributes are all but required for
        reflection to actually be useful for any of the interesting use
        cases for reflection.
        <div><br>
        </div>
        <div>The bare basic bog-standard example of reflection is
          serialization. A simple actually-usable-in-practice XML
          serialization library needs to allow uses to note which fields
          are serializable, what names to use, whether to serialize
          members as elements or attributes, options for how containers
          are serialized, etc. deserialization semantics for smart
          pointers as well as dynamic types, etc. Without a way to
          specify all that users will just be forced to build their own
          library-based reflection systems (using macros and templates
          and lots of manual repetition, like we already do today in
          C++03) in order to actually do anything interesting.</div>
        <div><br>
        </div>
        <div>I don't think there's any realistic debate here about
          whether reflection of user-defined attributes are needed. They
          are. The only question is "what should it look like" ?</div>
        <div><br>
        </div>
        <div>I for one am in favor of explicit definitions. Something
          like (the syntax itself is irrelevant):</div>
        <div><br>
        </div>
        <div><font face=3D"courier new, monospace">=C2=A0 namespace
            serialization {</font></div>
        <div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 // an attr=
ibute,
            which must be usable as a constexpr value type</font></div>
        <div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 struct xml
            attribute</font></div>
        <div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 {</font></=
div>
        <div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 // =
std::string
            name; =C2=A0// not allowed, not constexpr-constructible</font><=
/div>
        <div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 cha=
r const* name;
            // allowed for constexpr</font></div>
        <div><font face=3D"courier new, monospace"><br>
          </font></div>
        <div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 //=
=C2=A0</font><span
            style=3D"font-family: 'courier new', monospace;">xml=C2=A0</spa=
n><font
            face=3D"courier new, monospace">(char const*); // not allowed,
            not constexpr</font></div>
        <div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 con=
stexpr=C2=A0</font><span
            style=3D"font-family: 'courier new', monospace;">xml</span><fon=
t
            face=3D"courier new, monospace">(char const* name, enum
            node_type =3D element); // allowed</font></div>
        <div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 };</font><=
/div>
        <div><font face=3D"courier new, monospace">=C2=A0 }</font></div>
        <div><font face=3D"courier new, monospace"><br>
          </font></div>
        <div><font face=3D"courier new, monospace">=C2=A0 // specify the XM=
L
            element name this class with serialize with</font></div>
        <div><font face=3D"courier new, monospace">=C2=A0 // as an aside, I
            think the C++ generalized attribute syntax is terrible; it's
            totally non-obvious to normal users</font></div>
        <div><font face=3D"courier new, monospace">=C2=A0 // that placing t=
he
            [[]] before `class` is valid code but has an entirely
            different and unintended meaning. that ship has sailed,
            though.</font></div>
        <div><font face=3D"courier new, monospace">=C2=A0 class=C2=A0</font=
><span
            style=3D"font-family: 'courier new', monospace;">[[serializatio=
n::xml{"ns::Bar"}]]=C2=A0</span><span
            style=3D"font-family: 'courier new', monospace;">bar {</span><b=
r>
        </div>
        <div><span style=3D"font-family: 'courier new', monospace;">=C2=A0 =
=C2=A0 //
            specify that this member serializes as an XML attribute with
            the given name</span><br>
        </div>
        <div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 int
            [[serialization::xml{"ns::BaxValue",
            serialization::attribute}]] bax;</font></div>
        <div><font face=3D"courier new, monospace">=C2=A0 };</font></div>
        <div><font face=3D"courier new, monospace"><br>
          </font></div>
        <div><font face=3D"courier new, monospace">=C2=A0 // querying
            attributes is also constexpr</font></div>
        <div><font face=3D"courier new, monospace">=C2=A0 // attr0 here is =
an
            instance of serialization::</font><span style=3D"font-family:
            'courier new', monospace;">xml=C2=A0</span><font face=3D"courie=
r
            new, monospace">constructed with=C2=A0</font><span
            style=3D"font-family: 'courier new', monospace;">xml</span><fon=
t
            face=3D"courier new, monospace">{"bar", element}<br>
          </font></div>
        <div><font face=3D"courier new, monospace">=C2=A0 constexpr auto at=
tr0
            =3D std::reflect::attribute_v&lt;bar, 0&gt;;</font></div>
        <div><font face=3D"courier new, monospace"><br>
          </font></div>
        <div><font face=3D"courier new, monospace">=C2=A0 // attr1 should b=
e
            obvious (ignoring the strawman reflection library shim)</font><=
/div>
        <div><font face=3D"courier new, monospace">=C2=A0 constexpr auto at=
tr1
            =3D std::reflect::attribute_v&lt;std::reflect::member&lt;bar,
            0&gt;, 0&gt;;</font></div>
        <div><br>
        </div>
        <div>This system has several benefits: (1) spelling mistakes are
          compile-time detected, (2) zero run-time overhead is mandated,
          (3) zero compiled-binary-size overhead is mandated, (4)
          integrates with tools, and (5) provides flexibility to users
          who understand their problem domains far better than could be
          expected of us or the committee.</div>
        <div><br>
        </div>
        <div>(4) is a super huge primary reason that I utterly reject a
          string-based approach. We really want to use a tools-first
          mentality to any language or library extension. Code isn't
          text. Code is structure and semantics. Text is just the way we
          express program source and make it easy to read and write. The
          very first thing a compiler, or a tool, or your human brain
          does is convert that textual representation into structured
          semantics. A text-based attribute language would still let our
          brains do that but utterly subverts the ability for tools to
          do it, especially for user-defined attributes.</div>
        <div><br>
        </div>
        <div>In order to help with the problems noted in the aside in
          that code sample, it may also be useful to let user-defined
          attributes explicitly declare whether they apply to types
          definitions, declared types in other definitions,
          variable/member definitions, variables or functions, etc. Then
          at least a misplaced attribute could raise a helpful
          compile-time warning/error.</div>
      </div>
      -- <br>
      <br>
      --- <br>
      You received this message because you are subscribed to the Google
      Groups "ISO C++ Standard - Future Proposals" group.<br>
      To unsubscribe from this group and stop receiving emails from it,
      send an email to <a moz-do-not-send=3D"true"
        href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+=
unsubscribe@isocpp.org</a>.<br>
      To post to this group, send email to <a moz-do-not-send=3D"true"
        href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</=
a>.<br>
      Visit this group at <a moz-do-not-send=3D"true"
        href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
>http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
    </blockquote>
    <br>
  </body>
</html>

<p></p>

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

--------------060405090409010902060402--

.

------=_Part_2167_986577055.1411944158963
Content-Type: text/plain; charset=UTF-8

On Sunday, September 28, 2014 6:52:38 PM UTC-3, Sean Middleditch wrote:
>
> This system has several benefits: (1) spelling mistakes are compile-time
> detected, (2) zero run-time overhead is mandated, (3) zero
> compiled-binary-size overhead is mandated, (4) integrates with tools, and
> (5) provides flexibility to users who understand their problem domains far
> better than could be expected of us or the committee.
>

I agree with that approach, if user defined attributes must be supported,
then there has to be a way to declare them first before use, otherwise they
are too dangerous to use.
But that is too radical a change from what attributes were designed to be
used, that they can be safely ignored in all circumstances.

I think a less intrusive approach would be one that still let's the current
behavior persist, and introduces a new syntax that allows attributes to be
used in a way that compilers would be forced to diagnose in case they don't
know about it.
And so user-defined attributes would always be required to use this new
syntax, and reflection would only work on attributes when using this new
syntax.
The idea I proposed a few posts back about 'required' attributes be
prefixed with '!' is one such example, but I am open for suggestions.


> (4) is a super huge primary reason that I utterly reject a string-based
> approach. We really want to use a tools-first mentality to any language or
> library extension. Code isn't text. Code is structure and semantics. Text
> is just the way we express program source and make it easy to read and
> write. The very first thing a compiler, or a tool, or your human brain does
> is convert that textual representation into structured semantics. A
> text-based attribute language would still let our brains do that but
> utterly subverts the ability for tools to do it, especially for
> user-defined attributes.
>

I agree a solution using user defined classes is a good approach, but there
are concerns about how easy would it be to implement on current compilers,
and about name clashes.
Would noreturn, deprecated and carries_dependency be introduced as classes
in the root namespace, or would they be special cased somehow? What about
vendor attributes?


> In order to help with the problems noted in the aside in that code sample,
> it may also be useful to let user-defined attributes explicitly declare
> whether they apply to types definitions, declared types in other
> definitions, variable/member definitions, variables or functions, etc. Then
> at least a misplaced attribute could raise a helpful compile-time
> warning/error.
>

That's also a valid point.

--

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

<div dir=3D"ltr">On Sunday, September 28, 2014 6:52:38 PM UTC-3, Sean Middl=
editch wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div></div><div>This system has several benefits: (1) spelling mistakes are=
 compile-time detected, (2) zero run-time overhead is mandated, (3) zero co=
mpiled-binary-size overhead is mandated, (4) integrates with tools, and (5)=
 provides flexibility to users who understand their problem domains far bet=
ter than could be expected of us or the committee.</div></div></blockquote>=
<div><br>I agree with that approach, if user defined attributes must be sup=
ported, then there has to be a way to declare them first before use, otherw=
ise they are too dangerous to use.<br>But that is too radical a change from=
 what attributes were designed to be used, that they can be safely ignored =
in all circumstances.<br><br>I think a less intrusive approach would be one=
 that still let's the current behavior persist, and introduces a new syntax=
 that allows attributes to be used in a way that compilers would be forced =
to diagnose in case they don't know about it.<br>And so user-defined attrib=
utes would always be required to use this new syntax, and reflection would =
only work on attributes when using this new syntax.<br>The idea I proposed =
a few posts back about 'required' attributes be prefixed with '!' is one su=
ch example, but I am open for suggestions.<br>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>(4) is a super=
 huge primary reason that I utterly reject a string-based approach. We real=
ly want to use a tools-first mentality to any language or library extension=
.. Code isn't text. Code is structure and semantics. Text is just the way we=
 express program source and make it easy to read and write. The very first =
thing a compiler, or a tool, or your human brain does is convert that textu=
al representation into structured semantics. A text-based attribute languag=
e would still let our brains do that but utterly subverts the ability for t=
ools to do it, especially for user-defined attributes.</div></div></blockqu=
ote><div><br>I agree a solution using user defined classes is a good approa=
ch, but there are concerns about how easy would it be to implement on curre=
nt compilers, and about name clashes.<br>Would noreturn, deprecated and car=
ries_dependency be introduced as classes in the root namespace, or would th=
ey be special cased somehow? What about vendor attributes?<br>&nbsp;</div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><di=
v>In order to help with the problems noted in the aside in that code sample=
, it may also be useful to let user-defined attributes explicitly declare w=
hether they apply to types definitions, declared types in other definitions=
, variable/member definitions, variables or functions, etc. Then at least a=
 misplaced attribute could raise a helpful compile-time warning/error.</div=
></div></blockquote><div><br>That's also a valid point. <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 />

------=_Part_2167_986577055.1411944158963--

.

--001a11c3ce641c30870504296b0a
Content-Type: text/plain; charset=UTF-8

On Sun, Sep 28, 2014 at 11:52 PM, Sean Middleditch <
sean.middleditch@gmail.com> wrote:

> This system has several benefits: (1) spelling mistakes are compile-time
> detected, (2) zero run-time overhead is mandated, (3) zero
> compiled-binary-size overhead is mandated, (4) integrates with tools, and
> (5) provides flexibility to users who understand their problem domains far
> better than could be expected of us or the committee.
>

What you are missing is that compile-time strings can, and are, processed
during translation.  Consequently all 5 of requirements can be met by such
a system.  Google "tomazos has_member_function" for a demo/paper that shows
how this works.

--

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

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

<div dir=3D"ltr">On Sun, Sep 28, 2014 at 11:52 PM, Sean Middleditch <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:sean.middleditch@gmail.com" target=3D"_bla=
nk">sean.middleditch@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail=
_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">This system has several benefits: (1) spelling mistakes are compil=
e-time detected, (2) zero run-time overhead is mandated, (3) zero compiled-=
binary-size overhead is mandated, (4) integrates with tools, and (5) provid=
es flexibility to users who understand their problem domains far better tha=
n could be expected of us or the committee.</div></blockquote><div><br></di=
v><div>What you are missing is that compile-time strings can, and are, proc=
essed during translation.=C2=A0 Consequently all 5 of requirements can be m=
et by such a system.=C2=A0 Google &quot;tomazos has_member_function&quot; f=
or a demo/paper that shows how this works.<br><br></div></div></div></div>

<p></p>

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

--001a11c3ce641c30870504296b0a--

.

------=_Part_435_1727775289.1411951609120
Content-Type: text/plain; charset=UTF-8

On Sunday, September 28, 2014 9:33:45 PM UTC-3, Andrew Tomazos wrote:
>
> What you are missing is that compile-time strings can, and are, processed
> during translation.  Consequently all 5 of requirements can be met by such
> a system.  Google "tomazos has_member_function" for a demo/paper that shows
> how this works.
>

But how would such a system differentiate an attribute that is absent
because it was mistyped, from one that is absent because the user intended
it to be so?
Would the programmer have to litter his code also with checks for
attributes with "similar but different" names, which would be diagnosed by
his own static_assert, instead of the compiler performing that diagnostic?

--

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

<div dir=3D"ltr">On Sunday, September 28, 2014 9:33:45 PM UTC-3, Andrew Tom=
azos wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><d=
iv><div class=3D"gmail_quote"><div>What you are missing is that compile-tim=
e strings can, and are, processed during translation.&nbsp; Consequently al=
l 5 of requirements can be met by such a system.&nbsp; Google "tomazos has_=
member_function" for a demo/paper that shows how this works.<br></div></div=
></div></div></blockquote><div><br>But how would such a system differentiat=
e an attribute that is absent because it was mistyped, from one that is abs=
ent because the user intended it to be so?<br>Would the programmer have to =
litter his code also with checks for attributes with "similar but different=
" names, which would be diagnosed by his own static_assert, instead of the =
compiler performing that diagnostic?<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 />

------=_Part_435_1727775289.1411951609120--

.

--001a11c3557ae589c205042b6174
Content-Type: text/plain; charset=UTF-8

On Mon, Sep 29, 2014 at 2:46 AM, Matheus Izvekov <mizvekov@gmail.com> wrote:

> On Sunday, September 28, 2014 9:33:45 PM UTC-3, Andrew Tomazos wrote:
>>
>> What you are missing is that compile-time strings can, and are, processed
>> during translation.  Consequently all 5 of requirements can be met by such
>> a system.  Google "tomazos has_member_function" for a demo/paper that shows
>> how this works.
>>
>
> But how would such a system differentiate an attribute that is absent
> because it was mistyped, from one that is absent because the user intended
> it to be so?
> Would the programmer have to litter his code also with checks for
> attributes with "similar but different" names, which would be diagnosed by
> his own static_assert, instead of the compiler performing that diagnostic?
>

I guess the intention of the current attribute specification is that
implementations are encouraged (or at least allowed) to ignore attributes
they don't recognize.  If they do - they risk not diagnosing mistyped
attributes.  C'est la vie.  You can implement it likewise, either way, on
top of attribute reflection.  If the returned compile-time string contains
an attribute you don't recognize, you can either ignore it or static error,
with the same associated tradeoff.

--

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

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

<div dir=3D"ltr">On Mon, Sep 29, 2014 at 2:46 AM, Matheus Izvekov <span dir=
=3D"ltr">&lt;<a href=3D"mailto:mizvekov@gmail.com" target=3D"_blank">mizvek=
ov@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span clas=
s=3D"">On Sunday, September 28, 2014 9:33:45 PM UTC-3, Andrew Tomazos wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote"><div>What you are missing is that compile-time strings can=
, and are, processed during translation.=C2=A0 Consequently all 5 of requir=
ements can be met by such a system.=C2=A0 Google &quot;tomazos has_member_f=
unction&quot; for a demo/paper that shows how this works.<br></div></div></=
div></div></blockquote></span><div><br>But how would such a system differen=
tiate an attribute that is absent because it was mistyped, from one that is=
 absent because the user intended it to be so?<br>Would the programmer have=
 to litter his code also with checks for attributes with &quot;similar but =
different&quot; names, which would be diagnosed by his own static_assert, i=
nstead of the compiler performing that diagnostic?<br></div></div></blockqu=
ote><div><br></div>I guess the intention of the current attribute specifica=
tion is that implementations are encouraged (or at least allowed) to ignore=
 attributes they don&#39;t recognize.=C2=A0 If they do - they risk not diag=
nosing mistyped attributes.=C2=A0 C&#39;est la vie.=C2=A0 You can implement=
 it likewise, either way, on top of attribute reflection.=C2=A0 If the retu=
rned compile-time string contains an attribute you don&#39;t recognize, you=
 can either ignore it or static error, with the same associated tradeoff.<b=
r></div></div></div>

<p></p>

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

--001a11c3557ae589c205042b6174--

.

------=_Part_2311_1711378481.1411961827962
Content-Type: text/plain; charset=UTF-8

On Sunday, September 28, 2014 11:54:20 PM UTC-3, Andrew Tomazos wrote:
>
> I guess the intention of the current attribute specification is that
> implementations are encouraged (or at least allowed) to ignore attributes
> they don't recognize.  If they do - they risk not diagnosing mistyped
> attributes.  C'est la vie.  You can implement it likewise, either way, on
> top of attribute reflection.  If the returned compile-time string contains
> an attribute you don't recognize, you can either ignore it or static error,
> with the same associated tradeoff.
>

That's a far from ideal situation... Suppose there are multiple isolated
parts of the system which use their own attributes, and you create a class
that's supposed to interact with more than one, and so will likely use
attributes from several different independent entities.
They would somehow have to know each others attributes in order to ignore
them... This would increase coupling a lot.
Not including implementation-specific attributes like gnu::whatever which
would also need to be ignored somehow, but this could be mitigated if it
was enforced that user attributes must always belong in an exclusive
namespace (for example "user::")

In practice users would probably start creating their own global 'attribute
registries', which would serve as a poor man's stand in for having a proper
standardized way of declaring attributes before use.

--

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

<div dir=3D"ltr">On Sunday, September 28, 2014 11:54:20 PM UTC-3, Andrew To=
mazos wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div><div class=3D"gmail_quote"><div></div>I guess the intention of the curr=
ent attribute specification is that implementations are encouraged (or at l=
east allowed) to ignore attributes they don't recognize.&nbsp; If they do -=
 they risk not diagnosing mistyped attributes.&nbsp; C'est la vie.&nbsp; Yo=
u can implement it likewise, either way, on top of attribute reflection.&nb=
sp; If the returned compile-time string contains an attribute you don't rec=
ognize, you can either ignore it or static error, with the same associated =
tradeoff.<br></div></div></div></blockquote><div><br>That's a far from idea=
l situation... Suppose there are multiple isolated parts of the system whic=
h use their own attributes, and you create a class that's supposed to inter=
act with more than one, and so will likely use attributes from several diff=
erent independent entities.<br>They would somehow have to know each others =
attributes in order to ignore them... This would increase coupling a lot.<b=
r>Not including implementation-specific attributes like gnu::whatever which=
 would also need to be ignored somehow, but this could be mitigated if it w=
as enforced that user attributes must always belong in an exclusive namespa=
ce (for example "user::")<br><br>In practice users would probably start cre=
ating their own global 'attribute registries', which would serve as a poor =
man's stand in for having a proper standardized way of declaring attributes=
 before use.<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 />

------=_Part_2311_1711378481.1411961827962--

.

On Monday 29 September 2014 04:54:16 Andrew Tomazos wrote:
> I guess the intention of the current attribute specification is that
> implementations are encouraged (or at least allowed) to ignore attributes
> they don't recognize.  If they do - they risk not diagnosing mistyped
> attributes.  C'est la vie.  You can implement it likewise, either way, on
> top of attribute reflection.  If the returned compile-time string contain=
s
> an attribute you don't recognize, you can either ignore it or static erro=
r,
> with the same associated tradeoff.

The current intention is that implementations should understand all attribu=
tes=20
they see or should instead produce a diagnostic.

clang: warning: unknown attribute 'foo' ignored [-Wattributes]
gcc: warning: =E2=80=98foo=E2=80=99 attribute directive ignored [-Wattribut=
es]
ICC: warning #1292: unknown attribute "foo"

--=20
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

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

.

------=_Part_2180_246175277.1411963005547
Content-Type: text/plain; charset=UTF-8

On Monday, September 29, 2014 12:42:13 AM UTC-3, Thiago Macieira wrote:
>
> The current intention is that implementations should understand all
> attributes
> they see or should instead produce a diagnostic


That's not even necessarily so, the intent is that implementations may
choose to ignore attributes altogether.

Check out [dcs.attr.grammar] paragraph 5:

For an attribute-token not specified in this International Standard, the
> behavior is implementation-defined.
>

That diagnostic is not even required. And of course, if the implementation
chooses to perform that diagnostic, it would have very unpleasant results
when user defined attributes are in game.


--

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

<div dir=3D"ltr">On Monday, September 29, 2014 12:42:13 AM UTC-3, Thiago Ma=
cieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">The current inten=
tion is that implementations should understand all attributes=20
<br>they see or should instead produce a diagnostic</blockquote><div><br>Th=
at's not even necessarily so, the intent is that implementations may choose=
 to ignore attributes altogether.<br><br>Check out [dcs.attr.grammar] parag=
raph 5: <br><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left=
: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">F=
or an attribute-token not specified in this International Standard, the beh=
avior is implementation-defined.<br></blockquote><div><br>That diagnostic i=
s not even required. And of course, if the implementation chooses to perfor=
m that diagnostic, it would have very unpleasant results when user defined =
attributes are in game.<br>&nbsp;</div></div></div>

<p></p>

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

------=_Part_2180_246175277.1411963005547--

.

On Sunday 28 September 2014 20:56:45 Matheus Izvekov wrote:
> That diagnostic is not even required. And of course, if the implementation
> chooses to perform that diagnostic, it would have very unpleasant results
> when user defined attributes are in game.
>

Well, it's reasonable to expect those implementations will adapt their
diagnostics before or at the time they support user-defined attributes.

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

On Monday, September 29, 2014 1:42:07 AM UTC-3, Thiago Macieira wrote:
>
> Well, it's reasonable to expect those implementations will adapt their
> diagnostics before or at the time they support user-defined attributes.
>

Sure, you could even say that they do already "support" it, they are just
not useful because they have no effect whatsoever.
They would only make sense when used together with reflection.

The problem is that without some way of declaring attributes, the
implementation has no way of telling the difference between a mistyped
attribute
and a "true" user-defined attribute.
The programmers would be left to their own devices so they can reinvent
multiple shoddy ways of diagnosing those errors.

--

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

<div dir=3D"ltr">On Monday, September 29, 2014 1:42:07 AM UTC-3, Thiago Mac=
ieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Well, it's reasona=
ble to expect those implementations will adapt their=20
<br>diagnostics before or at the time they support user-defined attributes.
<br></blockquote><div><br>Sure, you could even say that they do already "su=
pport" it, they are just not useful because they have no effect whatsoever.=
<br>They would only make sense when used together with reflection.<br><br>T=
he problem is that without some way of declaring attributes, the implementa=
tion has no way of telling the difference between a mistyped attribute<br>a=
nd a "true" user-defined attribute.<br>The programmers would be left to the=
ir own devices so they can reinvent multiple shoddy ways of diagnosing thos=
e errors.<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 />

------=_Part_15_1773851155.1411966675632--

.

On 09/28/2014 11:52 PM, Sean Middleditch wrote:

>    class [[serialization::xml{"ns::Bar"}]] bar {
>      // specify that this member serializes as an XML attribute with the
> given name
>      int [[serialization::xml{"ns::BaxValue",
> serialization::attribute}]] bax;
>    };

How do you handle multiple formats, e.g. let us say that we want to
serialize bar to XML in one context, and to JSON or Google Protobuf in
another?

How do you handle non-intrusive serialization, e.g. of std or
third-party containers?

--

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

.

On Mon, Sep 29, 2014 at 4:12 AM, Bjorn Reese <breese@mail1.stofanet.dk> wrote:
>
> How do you handle multiple formats, e.g. let us say that we want to
> serialize bar to XML in one context, and to JSON or Google Protobuf in
> another?

I leave that up to the serialization library writers to determine.
It's not like this is an entirely new idea, though; Java, C#, Python,
etc. all use attributes or their equivalent for these purposes.
ProtoBuf-Net uses attributes for example, if you want to see how they
did it.

In general, attributes like these are used to specify behavior when
used in the right context (e.g. serialize::xml is used if present only
when tossed to the XML serialization writer, serialize::json would be
used only if tossed to the JSON serialization writer, etc.).

>
> How do you handle non-intrusive serialization, e.g. of std or
> third-party containers?

The same you have to deal with them today - function overloads,
template specializations, and/or proxy types. These are details that
are the day-to-day usage of the serialization library doesn't have to
care about (you're not often serialization a whole new special
container). The std:: types would likely be supported by any such
library out of the box, it may be that any container with the right
type traits are automatically supported, and hopefully the
serialization library author makes it easy-ish to add support for
custom containers.

Some libraries might require you to use their container types only.
These happen in other languages. The idea there is that the serialized
struct/class is meant only to be used for serialization (not use
in-memory), so you'd copy your data into the serialization struct,
serialize, copy out, etc. I don't personally feel that's a good design
but it's one that exists already with code-generation-based C++
serialization tools (ProtoBuf, Cap'N Proto, Avro, etc.).

Many serialization libraries let you add container-relevant markup to
the members of that type rather than the type itself, e.g. something
like:

  struct foo {
    std::vector<int> [[serialize::xml("foos", as_elements,
inner_element="item")]] foo_list;
  };

Again, strawman syntax/names just to illustrate the point. The library
author would figure out what options are available and what extension
points are available. The attribute serve to make day-to-day use by
regular folks possible, especially for things like members (which you
can't specialize a template on nor make a type trait for as they are
not themselves types).

--

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

did anybody, by chance looked at N3984
<https://github.com/cleitonsantoia/reflection/blob/master/N3984.pdf> ? please
comment...

Em sexta-feira, 26 de setembro de 2014 05h39min14s UTC-3, Myriachan
escreveu:
>
> How useful would it be to have a way at compile-time to retrieve
> attributes attached to a class, function, variable, etc.?  It would be a
> way to detect [[carries_dependency]] or to implement an equivalent to
> Microsoft's __declspec(uuid(...)) + __uuidof(T), but I don't know whether
> that's worth it =)
>
> Melissa
>

--

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

<div dir=3D"ltr">did anybody, by chance looked at&nbsp;<a href=3D"https://g=
ithub.com/cleitonsantoia/reflection/blob/master/N3984.pdf">N3984</a>&nbsp;?=
&nbsp;please comment...<br><br>Em sexta-feira, 26 de setembro de 2014 05h39=
min14s UTC-3, Myriachan  escreveu:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr">How useful would it be to have a way at compile-time=
 to retrieve attributes attached to a class, function, variable, etc.?&nbsp=
; It would be a way to detect [[carries_dependency]] or to implement an equ=
ivalent to Microsoft's __declspec(uuid(...)) + __uuidof(T), but I don't kno=
w whether that's worth it =3D)<br><br>Melissa<br></div></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&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_5248_1998680351.1414569469013--

.

On 29 October 2014 09:57, Cleiton Santoia <cleitonsantoia@gmail.com> wrote:
> did anybody, by chance looked at N3984 ? please comment...

SG7 said
"No presenters for N3984 or N3987, we will notify the authors that
they will have to solicit a presenter within the committee if they are
unable to attend. "

--

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


Sorry for that, I promise next time we send something, we will attend ;).

anyway.... we still could discuss these ideas in the forum couldn't we ?




Em quarta-feira, 29 de outubro de 2014 20h25min49s UTC-2, Ville Voutilainen
escreveu:
>
> On 29 October 2014 09:57, Cleiton Santoia <cleiton...@gmail.com
> <javascript:>> wrote:
> > did anybody, by chance looked at N3984 ? please comment...
>
> SG7 said
> "No presenters for N3984 or N3987, we will notify the authors that
> they will have to solicit a presenter within the committee if they are
> unable to attend. "
>

--

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

<div dir=3D"ltr"><div><br></div><div>Sorry for that, I promise next time we=
 send something, we will attend ;).&nbsp;</div><div><br></div><div>anyway..=
... we still could discuss these ideas in the forum couldn't we ?</div><div>=
<br></div><div><br></div><br><br>Em quarta-feira, 29 de outubro de 2014 20h=
25min49s UTC-2, Ville Voutilainen  escreveu:<blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;">On 29 October 2014 09:57, Cleiton Santoia &lt;<a href=3D"java=
script:" target=3D"_blank" gdf-obfuscated-mailto=3D"C5G8UUsqoHsJ" onmousedo=
wn=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javas=
cript:';return true;">cleiton...@gmail.com</a>&gt; wrote:
<br>&gt; did anybody, by chance looked at N3984 ? please comment...
<br>
<br>SG7 said
<br>"No presenters for N3984 or N3987, we will notify the authors that
<br>they will have to solicit a presenter within the committee if they are
<br>unable to attend. "
<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&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_628_1396934417.1414689428437--

.