------=_Part_3009_719822805.1424122900432
Content-Type: multipart/alternative;
 boundary="----=_Part_3010_1286500084.1424122900432"

------=_Part_3010_1286500084.1424122900432
Content-Type: text/plain; charset=UTF-8

Hi all,

some days ago I went across N4129. After reading that proposal, there is
some things wich annoys me. In particular, this citation troubles me:



*"Previous discussions considered a language feature to indicate whether
the default-variable expression should be evaluated at the call-site."*It
troubles me for several reasons:
- I had exactly this idea about parameters evaluated at the call site in
the past, and it was quite for the same problems.
- The proposal seems to want to add a "magical" source_context class with
the data we need. The fact is that I don't like "magical" classes.
- This magical classe seems to need the behaviour mentionned above. From
the paper :
*"When used as a default-variable expression, (dcl.fct.default) the
resulting values shall be as-if it were instantiated at the call-site."*

In the end, all the required mechanics to be able to evaluate parameters at
the call site will be required for this sole classe. So my question is :
Why don't we want it to be included as a language feature?
- It solves the base problems. (the source _context() could be an addition
to it, but from my point of view it should come only as a bonus).
- It can also be used in other contexts. One context I thought about was
exception, were one could want to get a complete stacktrace in order to be
able to debug his code more easily. Such a langage feature is enough for
solving most of the problem. (There is still the fact that there is no
standart way to get the stacktrace itself, but it's another problem wich
could (should?) potentially be addressed through another proposal).

What do you think of 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_3010_1286500084.1424122900432
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi all,<br><br>some days ago I went across N4129. After re=
ading that proposal, there is some things wich annoys me. In particular, th=
is citation troubles me:<br><br><i>"Previous discussions considered a langu=
age feature to indicate whether=20
the default-variable expression should be evaluated at the call-site."<br><=
br></i>It troubles me for several reasons:<br>- I had exactly this idea abo=
ut parameters evaluated at the call site in the past, and it was quite for =
the same problems. <br>- The proposal seems to want to add a "magical" sour=
ce_context class with the data we need. The fact is that I don't like "magi=
cal" classes.<br>- This magical classe seems to need the behaviour mentionn=
ed above. From the paper :<br><i>"When used as a default-variable expressio=
n, (dcl.fct.default) the resulting values shall be as-if it were instantiat=
ed at the call-site."</i><br><br>In the end, all the required mechanics to =
be able to evaluate parameters at the call site will be required for this s=
ole classe. So my question is :<br>Why don't we want it to be included as a=
 language feature? <br>- It solves the base problems. (the source _context(=
) could be an addition to it, but from my point of view it should come only=
 as a bonus).<br>- It can also be used in other contexts. One context I tho=
ught about was exception, were one could want to get a complete stacktrace =
in order to be able to debug his code more easily. Such a langage feature i=
s enough for solving most of the problem. (There is still the fact that the=
re is no standart way to get the stacktrace itself, but it's another proble=
m wich could (should?) potentially be addressed through another proposal).<=
br><br>What do you think of that?<br><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_3010_1286500084.1424122900432--
------=_Part_3009_719822805.1424122900432--

.

------=_Part_2798_879762129.1424140253965
Content-Type: multipart/alternative;
 boundary="----=_Part_2799_737192508.1424140253965"

------=_Part_2799_737192508.1424140253965
Content-Type: text/plain; charset=UTF-8

Thank you for the interest in the proposal.

After presenting it to the rest of committee at the Urbana meeting, the
design changed in some fairly subtle, yet significant, ways. For one, the
construction of the object was requested to be done by a separate magic
function. This makes source_context (bike shedded current name of the data
store) no longer magical. This special function will be magical, instead.
Setting that aside, I had a discussion separately with some of the CWG
members, and the consensus seemed to be that this feature could be done
without needing CWG wording. That simplifies my life. The motivation in
keeping it simpler at this stage, is that the data store can presumably
merge in nicely with a more complete reflection proposal, should anyone
figure out what that should look like, in a way that others like. Since
this is the first reflection proposal to make it out of the Reflection
Study Group, I opted to keep it simple: to leave the design space open as
we move forward.

The biggest downfall with default variables as a means to capture
information, is that they do not work with variadic templates. (makes me
very sad) Thus, it is best to think of this means of capturing source-code
information, as simply stating what happens when it IS used as a default
variable, rather than expecting that default variables will be the all time
best way to get this info. Teaser: I am working on a paper to get that
discussion going, but I am saddled with other projects. I expect to have it
out in a month or so in the reflection reflector, with an intent to discuss
it in Lenexa.

FWIW, I very much liked the idea of adding wording to determine how default
variables handle code-location aware data, but alas, in the end, it was too
ambitious, too early. That is not to say it cannot be there in the future,
though. =) I would welcome further exploration of that design space, and
the discussion of further source-location aware information objects, and
would love to see a way to make variadics work with default variables.

Lastly, I suspect the feature seems magical because we've never had this
sort of reflection information available. Once people get a hold of it, I
hope to see more discussion about what the best ways are to express the
intent to capture that class of information. But there's no need to wait!
If you have any ideas, please write a paper. If that sounds boring or
tedious, then let me know and I'd be happy to include new ideas in my
upcoming design-exploration paper.


On Monday, February 16, 2015 at 3:41:40 PM UTC-6, masse....@gmail.com wrote:
>
> Hi all,
>
> some days ago I went across N4129. After reading that proposal, there is
> some things wich annoys me. In particular, this citation troubles me:
>
>
>
> *"Previous discussions considered a language feature to indicate whether
> the default-variable expression should be evaluated at the call-site."*It
> troubles me for several reasons:
> - I had exactly this idea about parameters evaluated at the call site in
> the past, and it was quite for the same problems.
> - The proposal seems to want to add a "magical" source_context class with
> the data we need. The fact is that I don't like "magical" classes.
> - This magical classe seems to need the behaviour mentionned above. From
> the paper :
> *"When used as a default-variable expression, (dcl.fct.default) the
> resulting values shall be as-if it were instantiated at the call-site."*
>
> In the end, all the required mechanics to be able to evaluate parameters
> at the call site will be required for this sole classe. So my question is :
> Why don't we want it to be included as a language feature?
> - It solves the base problems. (the source _context() could be an addition
> to it, but from my point of view it should come only as a bonus).
> - It can also be used in other contexts. One context I thought about was
> exception, were one could want to get a complete stacktrace in order to be
> able to debug his code more easily. Such a langage feature is enough for
> solving most of the problem. (There is still the fact that there is no
> standart way to get the stacktrace itself, but it's another problem wich
> could (should?) potentially be addressed through another proposal).
>
> What do you think of 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_2799_737192508.1424140253965
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thank you for the interest in the proposal.<div><br></div>=
<div>After presenting it to the rest of committee at the Urbana meeting, th=
e design changed in some fairly subtle, yet significant, ways. For one, the=
 construction of the object was requested to be done by a separate magic fu=
nction. This makes source_context (bike shedded current name of the data st=
ore) no longer magical. This special function will be magical, instead. Set=
ting that aside, I had a discussion separately with some of the CWG members=
, and the consensus seemed to be that this feature could be done without ne=
eding CWG wording. That simplifies my life. The motivation in keeping it si=
mpler at this stage, is that the data store can presumably merge in nicely =
with a more complete reflection proposal, should anyone figure out what tha=
t should look like, in a way that others like. Since this is the first refl=
ection proposal to make it out of the Reflection Study Group, I opted to ke=
ep it simple: to leave the design space open as we move forward.<div><br></=
div><div>The biggest downfall with default variables as a means to capture =
information, is that they do not work with variadic templates. (makes me ve=
ry sad) Thus, it is best to think of this means of capturing source-code in=
formation, as simply stating what happens when it IS used as a default vari=
able, rather than expecting that default variables will be the all time bes=
t way to get this info. Teaser: I am working on a paper to get that discuss=
ion going, but I am saddled with other projects. I expect to have it out in=
 a month or so in the reflection reflector, with an intent to discuss it in=
 Lenexa.</div><div><br></div><div>FWIW, I very much liked the idea of addin=
g wording to determine how default variables handle code-location aware dat=
a, but alas, in the end, it was too ambitious, too early. That is not to sa=
y it cannot be there in the future, though. =3D) I would welcome further ex=
ploration of that design space, and the discussion of further source-locati=
on aware information objects, and would love to see a way to make variadics=
 work with default variables.</div><div><br></div><div>Lastly, I suspect th=
e feature seems magical because we've never had this sort of reflection inf=
ormation available. Once people get a hold of it, I hope to see more discus=
sion about what the best ways are to express the intent to capture that cla=
ss of information. But there's no need to wait! If you have any ideas, plea=
se write a paper. If that sounds boring or tedious, then let me know and I'=
d be happy to include new ideas in my upcoming design-exploration paper.</d=
iv><div><br><br>On Monday, February 16, 2015 at 3:41:40 PM UTC-6, masse....=
@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">Hi all,<br><br>some days ago I went across N4129. After reading that pr=
oposal, there is some things wich annoys me. In particular, this citation t=
roubles me:<br><br><i>"Previous discussions considered a language feature t=
o indicate whether=20
the default-variable expression should be evaluated at the call-site."<br><=
br></i>It troubles me for several reasons:<br>- I had exactly this idea abo=
ut parameters evaluated at the call site in the past, and it was quite for =
the same problems. <br>- The proposal seems to want to add a "magical" sour=
ce_context class with the data we need. The fact is that I don't like "magi=
cal" classes.<br>- This magical classe seems to need the behaviour mentionn=
ed above. From the paper :<br><i>"When used as a default-variable expressio=
n, (dcl.fct.default) the resulting values shall be as-if it were instantiat=
ed at the call-site."</i><br><br>In the end, all the required mechanics to =
be able to evaluate parameters at the call site will be required for this s=
ole classe. So my question is :<br>Why don't we want it to be included as a=
 language feature? <br>- It solves the base problems. (the source _context(=
) could be an addition to it, but from my point of view it should come only=
 as a bonus).<br>- It can also be used in other contexts. One context I tho=
ught about was exception, were one could want to get a complete stacktrace =
in order to be able to debug his code more easily. Such a langage feature i=
s enough for solving most of the problem. (There is still the fact that the=
re is no standart way to get the stacktrace itself, but it's another proble=
m wich could (should?) potentially be addressed through another proposal).<=
br><br>What do you think of that?<br><br></div></blockquote></div></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_2799_737192508.1424140253965--
------=_Part_2798_879762129.1424140253965--

.

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

On 16 February 2015 at 15:41, <masse.nicolas@gmail.com> wrote:

> some days ago I went across N4129. After reading that proposal, there is
> some things wich annoys me. In particular, this citation troubles me:
>
>
>
> *"Previous discussions considered a language feature to indicate whether
> the default-variable expression should be evaluated at the call-site."*It
> troubles me for several reasons:
> - I had exactly this idea about parameters evaluated at the call site in
> the past, and it was quite for the same problems.
> - The proposal seems to want to add a "magical" source_context class with
> the data we need. The fact is that I don't like "magical" classes.
>

FYI: It is generally easier to get a proposal with a "magic" class through
the committee (initializer_list, type traits, etc.) than something which
requires syntactical changes.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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

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

<div dir=3D"ltr">On 16 February 2015 at 15:41,  <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:masse.nicolas@gmail.com" target=3D"_blank">masse.nicolas@gmail=
..com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmai=
l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">some days ago I we=
nt across N4129. After reading that proposal, there is some things wich ann=
oys me. In particular, this citation troubles me:<br><br><i>&quot;Previous =
discussions considered a language feature to indicate whether=20
the default-variable expression should be evaluated at the call-site.&quot;=
<br><br></i>It troubles me for several reasons:<br>- I had exactly this ide=
a about parameters evaluated at the call site in the past, and it was quite=
 for the same problems. <br>- The proposal seems to want to add a &quot;mag=
ical&quot; source_context class with the data we need. The fact is that I d=
on&#39;t like &quot;magical&quot; classes.<br></div></blockquote><div><br><=
/div><div>FYI: It is generally easier to get a proposal with a &quot;magic&=
quot; class through the committee (initializer_list, type traits, etc.) tha=
n something which requires syntactical changes.</div></div>-- <br><div clas=
s=3D"gmail_signature">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a=
 href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlor=
d.com</a>&gt;=C2=A0 (847) 691-1404</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 />

--089e013c63e0039887050f426cbe--

.

--20cf304271b2d58c63050f44802f
Content-Type: text/plain; charset=UTF-8

On Mon, Feb 16, 2015 at 1:41 PM, <masse.nicolas@gmail.com> wrote:

> Hi all,
>
> some days ago I went across N4129. After reading that proposal, there is
> some things wich annoys me. In particular, this citation troubles me:
>
>
>
> *"Previous discussions considered a language feature to indicate whether
> the default-variable expression should be evaluated at the call-site."*It
> troubles me for several reasons:
> - I had exactly this idea about parameters evaluated at the call site in
> the past, and it was quite for the same problems.
> - The proposal seems to want to add a "magical" source_context class with
> the data we need. The fact is that I don't like "magical" classes.
> - This magical classe seems to need the behaviour mentionned above. From
> the paper :
> *"When used as a default-variable expression, (dcl.fct.default) the
> resulting values shall be as-if it were instantiated at the call-site."*
>
> In the end, all the required mechanics to be able to evaluate parameters
> at the call site will be required for this sole classe. So my question is :
> Why don't we want it to be included as a language feature?
> - It solves the base problems. (the source _context() could be an addition
> to it, but from my point of view it should come only as a bonus).
> - It can also be used in other contexts. One context I thought about was
> exception, were one could want to get a complete stacktrace in order to be
> able to debug his code more easily. Such a langage feature is enough for
> solving most of the problem. (There is still the fact that there is no
> standart way to get the stacktrace itself, but it's another problem wich
> could (should?) potentially be addressed through another proposal).
>
> What do you think of that?
>

What do you mean? The language currently provides no way to observe whether
default arguments are evaluated "at the call site" -- there is no notion of
a "location" where an expression is evaluated today. This proposal is
adding a way to observe this, so it needs to specify the behavior with
regard to default arguments. What is this more general language feature are
you suggesting?

--

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

--20cf304271b2d58c63050f44802f
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 M=
on, Feb 16, 2015 at 1:41 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:masse=
..nicolas@gmail.com" target=3D"_blank">masse.nicolas@gmail.com</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi all,<br><br>=
some days ago I went across N4129. After reading that proposal, there is so=
me things wich annoys me. In particular, this citation troubles me:<br><br>=
<i>&quot;Previous discussions considered a language feature to indicate whe=
ther=20
the default-variable expression should be evaluated at the call-site.&quot;=
<br><br></i>It troubles me for several reasons:<br>- I had exactly this ide=
a about parameters evaluated at the call site in the past, and it was quite=
 for the same problems. <br>- The proposal seems to want to add a &quot;mag=
ical&quot; source_context class with the data we need. The fact is that I d=
on&#39;t like &quot;magical&quot; classes.<br>- This magical classe seems t=
o need the behaviour mentionned above. From the paper :<br><i>&quot;When us=
ed as a default-variable expression, (dcl.fct.default) the resulting values=
 shall be as-if it were instantiated at the call-site.&quot;</i><br><br>In =
the end, all the required mechanics to be able to evaluate parameters at th=
e call site will be required for this sole classe. So my question is :<br>W=
hy don&#39;t we want it to be included as a language feature? <br>- It solv=
es the base problems. (the source _context() could be an addition to it, bu=
t from my point of view it should come only as a bonus).<br>- It can also b=
e used in other contexts. One context I thought about was exception, were o=
ne could want to get a complete stacktrace in order to be able to debug his=
 code more easily. Such a langage feature is enough for solving most of the=
 problem. (There is still the fact that there is no standart way to get the=
 stacktrace itself, but it&#39;s another problem wich could (should?) poten=
tially be addressed through another proposal).<br><br>What do you think of =
that?</div></blockquote><div><br></div><div>What do you mean? The language =
currently provides no way to observe whether default arguments are evaluate=
d &quot;at the call site&quot; -- there is no notion of a &quot;location&qu=
ot; where an expression is evaluated today. This proposal is adding a way t=
o observe this, so it needs to specify the behavior with regard to default =
arguments. What is this more general language feature are you suggesting?</=
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 />

--20cf304271b2d58c63050f44802f--

.

------=_Part_1583_609199864.1424782985371
Content-Type: multipart/alternative;
 boundary="----=_Part_1584_1767568999.1424782985371"

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

So if I understand well, you focused on specifying what should the=20
source_context class be, while the way this class can be construct will be=
=20
debated later with the=20
reflection study group.
Ok for that. If I have any idea, i'll let you know.

Thanks for your reply,
Masse NIcolas.




Le mardi 17 f=C3=A9vrier 2015 03:30:54 UTC+1, Robert Douglas a =C3=A9crit :
>
> Thank you for the interest in the proposal.
>
> After presenting it to the rest of committee at the Urbana meeting, the=
=20
> design changed in some fairly subtle, yet significant, ways. For one, the=
=20
> construction of the object was requested to be done by a separate magic=
=20
> function. This makes source_context (bike shedded current name of the dat=
a=20
> store) no longer magical. This special function will be magical, instead.=
=20
> Setting that aside, I had a discussion separately with some of the CWG=20
> members, and the consensus seemed to be that this feature could be done=
=20
> without needing CWG wording. That simplifies my life. The motivation in=
=20
> keeping it simpler at this stage, is that the data store can presumably=
=20
> merge in nicely with a more complete reflection proposal, should anyone=
=20
> figure out what that should look like, in a way that others like. Since=
=20
> this is the first reflection proposal to make it out of the Reflection=20
> Study Group, I opted to keep it simple: to leave the design space open as=
=20
> we move forward.
>
> The biggest downfall with default variables as a means to capture=20
> information, is that they do not work with variadic templates. (makes me=
=20
> very sad) Thus, it is best to think of this means of capturing source-cod=
e=20
> information, as simply stating what happens when it IS used as a default=
=20
> variable, rather than expecting that default variables will be the all ti=
me=20
> best way to get this info. Teaser: I am working on a paper to get that=20
> discussion going, but I am saddled with other projects. I expect to have =
it=20
> out in a month or so in the reflection reflector, with an intent to discu=
ss=20
> it in Lenexa.
>
> FWIW, I very much liked the idea of adding wording to determine how=20
> default variables handle code-location aware data, but alas, in the end, =
it=20
> was too ambitious, too early. That is not to say it cannot be there in th=
e=20
> future, though. =3D) I would welcome further exploration of that design=
=20
> space, and the discussion of further source-location aware information=20
> objects, and would love to see a way to make variadics work with default=
=20
> variables.
>
> Lastly, I suspect the feature seems magical because we've never had this=
=20
> sort of reflection information available. Once people get a hold of it, I=
=20
> hope to see more discussion about what the best ways are to express the=
=20
> intent to capture that class of information. But there's no need to wait!=
=20
> If you have any ideas, please write a paper. If that sounds boring or=20
> tedious, then let me know and I'd be happy to include new ideas in my=20
> upcoming design-exploration paper.
>
>
> On Monday, February 16, 2015 at 3:41:40 PM UTC-6, masse....@gmail.com=20
> wrote:
>>
>> Hi all,
>>
>> some days ago I went across N4129. After reading that proposal, there is=
=20
>> some things wich annoys me. In particular, this citation troubles me:
>>
>>
>>
>> *"Previous discussions considered a language feature to indicate whether=
=20
>> the default-variable expression should be evaluated at the call-site."*I=
t=20
>> troubles me for several reasons:
>> - I had exactly this idea about parameters evaluated at the call site in=
=20
>> the past, and it was quite for the same problems.=20
>> - The proposal seems to want to add a "magical" source_context class wit=
h=20
>> the data we need. The fact is that I don't like "magical" classes.
>> - This magical classe seems to need the behaviour mentionned above. From=
=20
>> the paper :
>> *"When used as a default-variable expression, (dcl.fct.default) the=20
>> resulting values shall be as-if it were instantiated at the call-site."*
>>
>> In the end, all the required mechanics to be able to evaluate parameters=
=20
>> at the call site will be required for this sole classe. So my question i=
s :
>> Why don't we want it to be included as a language feature?=20
>> - It solves the base problems. (the source _context() could be an=20
>> addition to it, but from my point of view it should come only as a bonus=
).
>> - It can also be used in other contexts. One context I thought about was=
=20
>> exception, were one could want to get a complete stacktrace in order to =
be=20
>> able to debug his code more easily. Such a langage feature is enough for=
=20
>> solving most of the problem. (There is still the fact that there is no=
=20
>> standart way to get the stacktrace itself, but it's another problem wich=
=20
>> could (should?) potentially be addressed through another proposal).
>>
>> What do you think of that?
>>
>>

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

<div dir=3D"ltr">So if I understand well, you focused on specifying what sh=
ould the source_context class be, while the way this class can be construct=
 will be debated later with the <br>reflection study group.<br>Ok for that.=
 If I have any idea, i'll let you know.<br><br>Thanks for your reply,<br>Ma=
sse NIcolas.<br><br><br><br><br>Le mardi 17 f=C3=A9vrier 2015 03:30:54 UTC+=
1, Robert Douglas a =C3=A9crit&nbsp;:<blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;"><div dir=3D"ltr">Thank you for the interest in the proposal.<div><br=
></div><div>After presenting it to the rest of committee at the Urbana meet=
ing, the design changed in some fairly subtle, yet significant, ways. For o=
ne, the construction of the object was requested to be done by a separate m=
agic function. This makes source_context (bike shedded current name of the =
data store) no longer magical. This special function will be magical, inste=
ad. Setting that aside, I had a discussion separately with some of the CWG =
members, and the consensus seemed to be that this feature could be done wit=
hout needing CWG wording. That simplifies my life. The motivation in keepin=
g it simpler at this stage, is that the data store can presumably merge in =
nicely with a more complete reflection proposal, should anyone figure out w=
hat that should look like, in a way that others like. Since this is the fir=
st reflection proposal to make it out of the Reflection Study Group, I opte=
d to keep it simple: to leave the design space open as we move forward.<div=
><br></div><div>The biggest downfall with default variables as a means to c=
apture information, is that they do not work with variadic templates. (make=
s me very sad) Thus, it is best to think of this means of capturing source-=
code information, as simply stating what happens when it IS used as a defau=
lt variable, rather than expecting that default variables will be the all t=
ime best way to get this info. Teaser: I am working on a paper to get that =
discussion going, but I am saddled with other projects. I expect to have it=
 out in a month or so in the reflection reflector, with an intent to discus=
s it in Lenexa.</div><div><br></div><div>FWIW, I very much liked the idea o=
f adding wording to determine how default variables handle code-location aw=
are data, but alas, in the end, it was too ambitious, too early. That is no=
t to say it cannot be there in the future, though. =3D) I would welcome fur=
ther exploration of that design space, and the discussion of further source=
-location aware information objects, and would love to see a way to make va=
riadics work with default variables.</div><div><br></div><div>Lastly, I sus=
pect the feature seems magical because we've never had this sort of reflect=
ion information available. Once people get a hold of it, I hope to see more=
 discussion about what the best ways are to express the intent to capture t=
hat class of information. But there's no need to wait! If you have any idea=
s, please write a paper. If that sounds boring or tedious, then let me know=
 and I'd be happy to include new ideas in my upcoming design-exploration pa=
per.</div><div><br><br>On Monday, February 16, 2015 at 3:41:40 PM UTC-6, <a=
>masse....@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr">Hi all,<br><br>some days ago I went across N4129. After readin=
g that proposal, there is some things wich annoys me. In particular, this c=
itation troubles me:<br><br><i>"Previous discussions considered a language =
feature to indicate whether=20
the default-variable expression should be evaluated at the call-site."<br><=
br></i>It troubles me for several reasons:<br>- I had exactly this idea abo=
ut parameters evaluated at the call site in the past, and it was quite for =
the same problems. <br>- The proposal seems to want to add a "magical" sour=
ce_context class with the data we need. The fact is that I don't like "magi=
cal" classes.<br>- This magical classe seems to need the behaviour mentionn=
ed above. From the paper :<br><i>"When used as a default-variable expressio=
n, (dcl.fct.default) the resulting values shall be as-if it were instantiat=
ed at the call-site."</i><br><br>In the end, all the required mechanics to =
be able to evaluate parameters at the call site will be required for this s=
ole classe. So my question is :<br>Why don't we want it to be included as a=
 language feature? <br>- It solves the base problems. (the source _context(=
) could be an addition to it, but from my point of view it should come only=
 as a bonus).<br>- It can also be used in other contexts. One context I tho=
ught about was exception, were one could want to get a complete stacktrace =
in order to be able to debug his code more easily. Such a langage feature i=
s enough for solving most of the problem. (There is still the fact that the=
re is no standart way to get the stacktrace itself, but it's another proble=
m wich could (should?) potentially be addressed through another proposal).<=
br><br>What do you think of that?<br><br></div></blockquote></div></div></d=
iv></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_1584_1767568999.1424782985371--
------=_Part_1583_609199864.1424782985371--

.