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>&gt; c)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;What about a DEP=
 used within a DEP of a subsidary function?
<br>&gt; The DEP should not automatically be calculated, but if it has not
<br>&gt; been calculated, the subsidiary function would be responsible for
<br>&gt; 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>&nbsp; int bar(inline int a) { return a; }
<br>
<br>&nbsp; void foo(inline int b)
<br>&nbsp; {
<br>&nbsp; &nbsp; // b has not been evaluated yet
<br>&nbsp; &nbsp; bar(b);
<br>&nbsp; &nbsp; // foo sees that b has been evaluated and has access to t=
he value
<br>&nbsp; }
<br><br></blockquote><div>Done&nbsp;</div><blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;">&gt; f)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;What par=
ameters would be allowed to be DEPs?
<br>&gt; Initially, ths proposal allows DEPs for all parameters, except
<br>&gt; 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.&nbsp;</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 :)&nbsp;</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.&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_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--

.