Topic: Delayed evaluation parameters
Author: Douglas Boffey <douglas.boffey@gmail.com>
Date: Tue, 23 Dec 2014 15:14:25 -0800 (PST)
Raw View
------=_Part_923_1053906359.1419376465408
Content-Type: multipart/alternative;
boundary="----=_Part_924_559055257.1419376465409"
------=_Part_924_559055257.1419376465409
Content-Type: text/plain; charset=UTF-8
On Tuesday, 23 December 2014 22:32:13 UTC, Matthew Woehlke wrote:
>
> On 2014-12-23 16:48, Douglas Boffey wrote:
> > c) What about a DEP used within a DEP of a subsidary function?
> > The DEP should not automatically be calculated, but if it has not
> > been calculated, the subsidiary function would be responsible for
> > calculating it.
>
> Maybe this follows, but for clarity, I would also state that if the
> subsidary function evaluates the DEP, that evaluation is visible in the
> outer function.
>
> For example:
>
> int bar(inline int a) { return a; }
>
> void foo(inline int b)
> {
> // b has not been evaluated yet
> bar(b);
> // foo sees that b has been evaluated and has access to the value
> }
>
> Done
> > f) What parameters would be allowed to be DEPs?
> > Initially, ths proposal allows DEPs for all parameters, except
> > template variadic parameters and parameter packs.
>
> Mentioned of course in Future Enhancements, but FWIW this feels like an
> unnecessary restriction. Maybe we could simply refrain from either
> requiring or forbidding this, and leave it to implementations if they
> want to support it initially.
>
> Probably will alter in next revision.
> p.s. Thanks!
>
> No problem :)
> --
> Matthew
>
> Doug.
--
---
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_924_559055257.1419376465409
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, 23 December 2014 22:32:13 UTC, Matthew=
Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2014-12-23 =
16:48, Douglas Boffey wrote:
<br>> c) What about a DEP=
used within a DEP of a subsidary function?
<br>> The DEP should not automatically be calculated, but if it has not
<br>> been calculated, the subsidiary function would be responsible for
<br>> calculating it.
<br>
<br>Maybe this follows, but for clarity, I would also state that if the
<br>subsidary function evaluates the DEP, that evaluation is visible in the
<br>outer function.
<br>
<br>For example:
<br>
<br> int bar(inline int a) { return a; }
<br>
<br> void foo(inline int b)
<br> {
<br> // b has not been evaluated yet
<br> bar(b);
<br> // foo sees that b has been evaluated and has access to t=
he value
<br> }
<br><br></blockquote><div>Done </div><blockquote class=3D"gmail_quote"=
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;">> f) What par=
ameters would be allowed to be DEPs?
<br>> Initially, ths proposal allows DEPs for all parameters, except
<br>> template variadic parameters and parameter packs.
<br>
<br>Mentioned of course in Future Enhancements, but FWIW this feels like an
<br>unnecessary restriction. Maybe we could simply refrain from either
<br>requiring or forbidding this, and leave it to implementations if they
<br>want to support it initially.
<br>
<br></blockquote><div>Probably will alter in next revision. </div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">p.s. Thanks!
<br>
<br></blockquote><div>No problem :) </div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;">--=20
<br>Matthew
<br>
<br></blockquote><div>Doug. </div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_924_559055257.1419376465409--
------=_Part_923_1053906359.1419376465408
Content-Type: text/plain; charset=UTF-8; name="delayed evaluation parameters.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="delayed evaluation parameters.txt"
X-Attachment-Id: 42f7e6a8-24e0-4236-9108-c6e0fcf86af9
Content-ID: <42f7e6a8-24e0-4236-9108-c6e0fcf86af9>
Document number: Dxxx=3Dxx-xxxx
Date: xxxx-xx-xx
Project: Programming language C++, Core Working Group
Reply-to: Douglas Boffey <douglas.boffey@gmail.com>
Table of Contents
-----------------
1. Introduction
2. Motivation and Scope
3. Impact on the Standard
4. Design Decisions
5. Technical Specifications
6. Future Enhancements
7. Acknowledgements
8. References
Introduction
------------
This proposal provides Delayed Expression Parameters (DEPs), which are para=
meters to a constructor, function or member function that are only evaluate=
d on first use.
Motivation and Scope
--------------------
Most of the time, function parameters are evaluated prior to invocation of =
a function, but there are occasions where that is not what is needed.
Some of the reasons are:
a) evaluation of a parameter might invoke undefined behaviour in some circu=
mstances. Take, for example, the idiom:
if (a && /* some expression involving *a */)
where a is a pointer to memory, or nullptr.
b) a parameter might be expensive to construct and then destruct. If it is=
only sometimes needed, it would make sense only to evaluate it in those ci=
rcumstances.
c) code might need to be included in some builds, e.g. debug builds, that s=
houldn=E2=80=99t be included in other builds, e.g. production builds. For =
example, code that checks preconditions, postconditions and invariants.
d) it may be that only details of a variable type are required. For exampl=
e, a user-implementation of sizeof for variables would look like:
template <typename T>
std::size_t my_sizeof(inline T t) {
return sizeof(T);
}
e) logging may be optionally enabled. Given, for example,
log(level) << expensive_expression
it is convenient not to evaluate expensive_expression.
Currently, c) and e) are usually achieved by using macro functions, expandi=
ng to something like:
if (/* enabled */) /* something potentially involving an expensive expressi=
on */
Impact on the Standard
----------------------
This code introduces no breaking behaviour.
Design Decisions
----------------
There are a number of decisions:
a) Should the parameter be evaluated once only (cache-like), or on every oc=
curance (instance-like)?
This proposal is for a cache-like solution, because:
* efficiency
- an instance-like solution might require multiple constructions or assig=
nements
- an instance-like solution might inhibit optimisations, e.g. moving code=
out of loop
* effect
- there could be problems if the DEP was an rvalue
- multiple evaluations might produce unexpected behaviour. Take, for ins=
tance,
void fn(inline int a) {/* =E2=80=A6 */}
// =E2=80=A6
int a{1};
fn(++a);
It could be difficult to predict what a would end up as.
* documentation: it would be easier to document the conditions under which=
the DEP is evaluated rather than the number of times it is evaluated.
b) When should the parameter be evaluated?
A parameter needs to be evaluated whenever the value is needed, a reference=
of it is taken, or a pointer is made to point to it. The functions =E2=80=
=98sizeof=E2=80=99, =E2=80=98typeid=E2=80=99, =E2=80=98alignas=E2=80=99 and=
=E2=80=98decltype=E2=80=99 would not cause the DEP to be evaluated, as onl=
y the type of the DEP is required. Any references or pointers to the param=
eter should be to the cached value, not the code generating the value.
c) What about a DEP used within a DEP of a subsidary function?
The DEP should not automatically be evaluated, but if it has not been evalu=
ated, the subsidiary function would be responsible for evaluating it.
If the subsidiary function evaluates the DEP, that evaluation is visible in=
the outer function.
For example:
int bar(inline int a) {
return a;
}
void foo(inline int b) {
// b has not been evaluated yet
bar(b);
// foo sees that b has been evaluated and has access to the value
}
d) Should the DEP be a wrapper (like std::function) or a separate object (l=
ike a lambda)?
AS it would not make sense to refer to the code evaluating the value, the c=
ode should be as if it were a wrapper around the parameter.
e) What nomenclature should be used?
Three options:
1. a symbol: this would be inconsistent with existing practice, where symb=
ols are part of the type.
2. introduce a new keyword, e.g. lazy: any new keyword is a potential for =
breaking code, and there is no obvious way, consistent with the current syn=
tax, of introducing a context-sensitive keyword.
3. use an existing keyword: the keyword, =E2=80=98inline=E2=80=99 bests de=
scribes the effect of a DEP. It is proposed that it should be put at the b=
eginning of a DEP declaration, to mirror inline variables.
f) What parameters would be allowed to be DEPs?
Initially, ths proposal allows DEPs for all parameters, except template var=
iadic parameters and parameter packs.
Technical Specifications
------------------------
TBD
Future Enhancements
-------------------
There are a number of extensions that could be addad:
- unless the parameter is evaluated in a try block, it would be subject to =
any exception restrictions of the callee, although the code is owned by the=
caller. It might be better to permit an exception specification with the =
DEP.
- in this proposal, DEPs are not allowed for parameter packs.
- in this proposal, DEPs are not allowed for variadic template parameters.
Acknowledgements
----------------
My thanks go to sasho648, whose proposal inspired this proposal. Also to N=
icole Gigante, David Krauss and Matthew Woehlke for their insightful commen=
ts.
References
----------
See https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/ftrF=
qbyu7pQ for a discussion on this
Other, similar proposals can be found on https://groups.google.com/a/isocpp=
..org/forum/#!topic/std-proposals/ftrFqbyu7pQ and https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/DnxRfo_uQl8/discussion
--=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_923_1053906359.1419376465408--
.