------=_Part_1293_1702203488.1444070586180
Content-Type: multipart/alternative;
 boundary="----=_Part_1294_23423644.1444070586180"

------=_Part_1294_23423644.1444070586180
Content-Type: text/plain; charset=UTF-8

Following the "Allow values of void" discussion, I've put together a
proposal[1] for updating void to be a Regular type. I'm starting a new
thread for this paper specifically to get feedback on this proposal, which
will be presented at Kona. If there are questions or criticisms of the
idea, try to keep them in the context of this paper. In particular, I'd
like to keep this discussion a bit more grounded than the other and more
specific to precisely what is proposed here -- what might this proposal
break (apart from what is already explicitly covered in the paper unless
there is more to add), are there examples of problems that people expect to
be solved by void that are not addressed here, do people see problems with
any of the more subtle issues regarding the details of the proposed changes
to the standard itself, etc.. I'm not strictly against tangents about void
remaining a non-instantiable type, but if you are of that camp, please
present your argument in the context of this paper and with real world
examples, for instance how such an approach would apply to the logging
examples presented in the paper, what problems, if any, such an approach
might solve that this cannot, etc..

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div>Following the &quot;Allow values of void&quot; discus=
sion, I&#39;ve put together a proposal[1] for updating void to be a Regular=
 type. I&#39;m starting a new thread for this paper specifically to get fee=
dback on this proposal, which will be presented at Kona. If there are quest=
ions or criticisms of the idea, try to keep them in the context of this pap=
er. In particular, I&#39;d like to keep this discussion a bit more grounded=
 than the other and more specific to precisely what is proposed here -- wha=
t might this proposal break (apart from what is already explicitly covered =
in the paper unless there is more to add),=C2=A0are there examples of probl=
ems that people expect to be solved by void that are not addressed here, do=
 people see problems with any of the more subtle issues regarding the detai=
ls of the proposed changes to the standard itself, etc.. I&#39;m not strict=
ly against tangents about void remaining a non-instantiable type, but if yo=
u are of that camp, please present your argument in the context of this pap=
er and with real world examples, for instance how such an approach would ap=
ply to the logging examples presented in the paper, what problems, if any, =
such an approach might solve that this cannot, etc..</div><div><br></div>[1=
] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html<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_1294_23423644.1444070586180--
------=_Part_1293_1702203488.1444070586180--

.

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

On Mon, Oct 5, 2015 at 2:43 PM, Matt Calabrese <calabrese@google.com> wrote:

> Following the "Allow values of void" discussion, I've put together a
> proposal[1] for updating void to be a Regular type. I'm starting a new
> thread for this paper specifically to get feedback on this proposal, which
> will be presented at Kona. If there are questions or criticisms of the
> idea, try to keep them in the context of this paper. In particular, I'd
> like to keep this discussion a bit more grounded than the other and more
> specific to precisely what is proposed here -- what might this proposal
> break (apart from what is already explicitly covered in the paper unless
> there is more to add), are there examples of problems that people expect to
> be solved by void that are not addressed here, do people see problems with
> any of the more subtle issues regarding the details of the proposed changes
> to the standard itself, etc.. I'm not strictly against tangents about void
> remaining a non-instantiable type, but if you are of that camp, please
> present your argument in the context of this paper and with real world
> examples, for instance how such an approach would apply to the logging
> examples presented in the paper, what problems, if any, such an approach
> might solve that this cannot, etc..
>
> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html
>
> --
>

"For instance, if you were to make an array of such a void type, a pointer,
at least in the traditional sense, would no longer be able to be used as an
iterator into that array (notably meaning that generic code which relies on
this would now fail for such a size 0 type)."

You could still iterate.  Since ptr++ would add 0 to the pointer, you would
still always point to a/the void.
What you can't do is take the distance.  Or reach the end.

Some Ranges have similar problems.

Anyhow, I think the main purpose of the proposal will be to just see how
the committee reacts to the idea.  I think you've done a good job at "it's
not as big/scary as it sounds", but the reaction might still be "too
scary", regardless of the details.  I almost don't think there's much sense
discussing it here until we get a feel from the committee as to whether ANY
regularized-void idea has a chance.

Tony

--

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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Oct 5, 2015 at 2:43 PM, Matt Calabrese <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:calabrese@google.com" target=3D"_blank">calabrese@google.co=
m</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div dir=3D"ltr"><div>Following the &quot;Allow values of void&quot; disc=
ussion, I&#39;ve put together a proposal[1] for updating void to be a Regul=
ar type. I&#39;m starting a new thread for this paper specifically to get f=
eedback on this proposal, which will be presented at Kona. If there are que=
stions or criticisms of the idea, try to keep them in the context of this p=
aper. In particular, I&#39;d like to keep this discussion a bit more ground=
ed than the other and more specific to precisely what is proposed here -- w=
hat might this proposal break (apart from what is already explicitly covere=
d in the paper unless there is more to add),=C2=A0are there examples of pro=
blems that people expect to be solved by void that are not addressed here, =
do people see problems with any of the more subtle issues regarding the det=
ails of the proposed changes to the standard itself, etc.. I&#39;m not stri=
ctly against tangents about void remaining a non-instantiable type, but if =
you are of that camp, please present your argument in the context of this p=
aper and with real world examples, for instance how such an approach would =
apply to the logging examples presented in the paper, what problems, if any=
, such an approach might solve that this cannot, etc..</div><div><br></div>=
[1] <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p014=
6r0.html" target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/pap=
ers/2015/p0146r0.html</a><span class=3D""><font color=3D"#888888"><br></fon=
t></span></div><span class=3D""><font color=3D"#888888">

<p></p>

-- <br></font></span></blockquote><div><br>&quot;For instance, if you were =
to make an array of such a <code>void</code>=20
type, a pointer, at least in the traditional sense, would no longer be=20
able to be used as an iterator into that array (notably meaning that=20
generic code which relies on this would now fail for such a size <code>0</c=
ode> type).&quot;<br><br></div><div>You could still iterate.=C2=A0 Since pt=
r++ would add 0 to the pointer, you would still always point to a/the void.=
<br></div><div>What you can&#39;t do is take the distance.=C2=A0 Or reach t=
he end.<br><br></div><div>Some Ranges have similar problems.<br><br></div><=
div>Anyhow, I think the main purpose of the proposal will be to just see ho=
w the committee reacts to the idea.=C2=A0 I think you&#39;ve done a good jo=
b at &quot;it&#39;s not as big/scary as it sounds&quot;, but the reaction m=
ight still be &quot;too scary&quot;, regardless of the details.=C2=A0 I alm=
ost don&#39;t think there&#39;s much sense discussing it here until we get =
a feel from the committee as to whether ANY regularized-void idea has a cha=
nce.<br><br></div><div>Tony<br></div><div><br></div></div><br></div></div>

<p></p>

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

--001a11403592723b55052160a315--

.

------=_Part_3877_1425291839.1444075997616
Content-Type: multipart/alternative;
 boundary="----=_Part_3878_1702139413.1444075997624"

------=_Part_3878_1702139413.1444075997624
Content-Type: text/plain; charset=UTF-8

>You could still iterate.  Since ptr++ would add 0 to the pointer, you
would still always point to a/the void.

First class zero sized types are totally possible, they just require
nontrivial amount of work.
As an example, Rust have them and uses them ubiquitously. They are quite
handy - no need for empty base optimization, compressed pairs, void is a
regular zero sized type indeed, etc. but they have really be accounted for
in various places including collections and algorithms, moreover C++ has
ABI stability considerations. So, they have to be a separate proposal and
keeping this void proposal focused is a good idea.

On Monday, October 5, 2015 at 10:37:08 PM UTC+3, Tony V E wrote:
>
>
>
> On Mon, Oct 5, 2015 at 2:43 PM, Matt Calabrese <cala...@google.com
> <javascript:>> wrote:
>
>> Following the "Allow values of void" discussion, I've put together a
>> proposal[1] for updating void to be a Regular type. I'm starting a new
>> thread for this paper specifically to get feedback on this proposal, which
>> will be presented at Kona. If there are questions or criticisms of the
>> idea, try to keep them in the context of this paper. In particular, I'd
>> like to keep this discussion a bit more grounded than the other and more
>> specific to precisely what is proposed here -- what might this proposal
>> break (apart from what is already explicitly covered in the paper unless
>> there is more to add), are there examples of problems that people expect to
>> be solved by void that are not addressed here, do people see problems with
>> any of the more subtle issues regarding the details of the proposed changes
>> to the standard itself, etc.. I'm not strictly against tangents about void
>> remaining a non-instantiable type, but if you are of that camp, please
>> present your argument in the context of this paper and with real world
>> examples, for instance how such an approach would apply to the logging
>> examples presented in the paper, what problems, if any, such an approach
>> might solve that this cannot, etc..
>>
>> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html
>>
>> --
>>
>
> "For instance, if you were to make an array of such a void type, a
> pointer, at least in the traditional sense, would no longer be able to be
> used as an iterator into that array (notably meaning that generic code
> which relies on this would now fail for such a size 0 type)."
>
> You could still iterate.  Since ptr++ would add 0 to the pointer, you
> would still always point to a/the void.
> What you can't do is take the distance.  Or reach the end.
>
> Some Ranges have similar problems.
>
> Anyhow, I think the main purpose of the proposal will be to just see how
> the committee reacts to the idea.  I think you've done a good job at "it's
> not as big/scary as it sounds", but the reaction might still be "too
> scary", regardless of the details.  I almost don't think there's much sense
> discussing it here until we get a feel from the committee as to whether ANY
> regularized-void idea has a chance.
>
> Tony
>
>
>

--

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

<div dir=3D"ltr">&gt;You could still iterate.=C2=A0 Since ptr++ would add 0=
 to the pointer, you would still always point to a/the void.<div><br></div>=
<div>First class zero sized types are totally possible, they just require n=
ontrivial amount of work.</div><div>As an example, Rust have them and uses =
them=C2=A0ubiquitously. They are quite handy - no need for empty base optim=
ization, compressed pairs, void is a regular zero sized type indeed, etc. b=
ut they have really be accounted for in various places including collection=
s and algorithms, moreover C++ has ABI stability considerations. So, they h=
ave to be a separate proposal and keeping this void proposal focused is a g=
ood idea.<br><br>On Monday, October 5, 2015 at 10:37:08 PM UTC+3, Tony V E =
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"><br><di=
v><br><div class=3D"gmail_quote">On Mon, Oct 5, 2015 at 2:43 PM, Matt Calab=
rese <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-ob=
fuscated-mailto=3D"w5ZAF1TmCwAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">cala...@google.com</a>&gt;</span> wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Following t=
he &quot;Allow values of void&quot; discussion, I&#39;ve put together a pro=
posal[1] for updating void to be a Regular type. I&#39;m starting a new thr=
ead for this paper specifically to get feedback on this proposal, which wil=
l be presented at Kona. If there are questions or criticisms of the idea, t=
ry to keep them in the context of this paper. In particular, I&#39;d like t=
o keep this discussion a bit more grounded than the other and more specific=
 to precisely what is proposed here -- what might this proposal break (apar=
t from what is already explicitly covered in the paper unless there is more=
 to add),=C2=A0are there examples of problems that people expect to be solv=
ed by void that are not addressed here, do people see problems with any of =
the more subtle issues regarding the details of the proposed changes to the=
 standard itself, etc.. I&#39;m not strictly against tangents about void re=
maining a non-instantiable type, but if you are of that camp, please presen=
t your argument in the context of this paper and with real world examples, =
for instance how such an approach would apply to the logging examples prese=
nted in the paper, what problems, if any, such an approach might solve that=
 this cannot, etc..</div><div><br></div>[1] <a href=3D"http://www.open-std.=
org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html" target=3D"_blank" rel=3D"=
nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\75htt=
p%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0=
146r0.html\46sa\75D\46sntz\0751\46usg\75AFQjCNGFFGHgHIThkaWY3MV5oL4IIccqCA&=
#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\=
75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015=
%2Fp0146r0.html\46sa\75D\46sntz\0751\46usg\75AFQjCNGFFGHgHIThkaWY3MV5oL4IIc=
cqCA&#39;;return true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/pa=
pers/2015/<wbr>p0146r0.html</a><span><font color=3D"#888888"><br></font></s=
pan></div><span><font color=3D"#888888">

<p></p>

-- <br></font></span></blockquote><div><br>&quot;For instance, if you were =
to make an array of such a <code>void</code>=20
type, a pointer, at least in the traditional sense, would no longer be=20
able to be used as an iterator into that array (notably meaning that=20
generic code which relies on this would now fail for such a size <code>0</c=
ode> type).&quot;<br><br></div><div>You could still iterate.=C2=A0 Since pt=
r++ would add 0 to the pointer, you would still always point to a/the void.=
<br></div><div>What you can&#39;t do is take the distance.=C2=A0 Or reach t=
he end.<br><br></div><div>Some Ranges have similar problems.<br><br></div><=
div>Anyhow, I think the main purpose of the proposal will be to just see ho=
w the committee reacts to the idea.=C2=A0 I think you&#39;ve done a good jo=
b at &quot;it&#39;s not as big/scary as it sounds&quot;, but the reaction m=
ight still be &quot;too scary&quot;, regardless of the details.=C2=A0 I alm=
ost don&#39;t think there&#39;s much sense discussing it here until we get =
a feel from the committee as to whether ANY regularized-void idea has a cha=
nce.<br><br></div><div>Tony<br></div><div><br></div></div><br></div></div>
</blockquote></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_3878_1702139413.1444075997624--
------=_Part_3877_1425291839.1444075997616--

.

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

On Mon, Oct 5, 2015 at 12:37 PM, Tony V E <tvaneerd@gmail.com> wrote:
>
> On Mon, Oct 5, 2015 at 2:43 PM, Matt Calabrese <calabrese@google.com>
> wrote:
>
>> Following the "Allow values of void" discussion, I've put together a
>> proposal[1] for updating void to be a Regular type. I'm starting a new
>> thread for this paper specifically to get feedback on this proposal, which
>> will be presented at Kona. If there are questions or criticisms of the
>> idea, try to keep them in the context of this paper. In particular, I'd
>> like to keep this discussion a bit more grounded than the other and more
>> specific to precisely what is proposed here -- what might this proposal
>> break (apart from what is already explicitly covered in the paper unless
>> there is more to add), are there examples of problems that people expect to
>> be solved by void that are not addressed here, do people see problems with
>> any of the more subtle issues regarding the details of the proposed changes
>> to the standard itself, etc.. I'm not strictly against tangents about void
>> remaining a non-instantiable type, but if you are of that camp, please
>> present your argument in the context of this paper and with real world
>> examples, for instance how such an approach would apply to the logging
>> examples presented in the paper, what problems, if any, such an approach
>> might solve that this cannot, etc..
>>
>> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html
>>
>> --
>>
>
> "For instance, if you were to make an array of such a void type, a
> pointer, at least in the traditional sense, would no longer be able to be
> used as an iterator into that array (notably meaning that generic code
> which relies on this would now fail for such a size 0 type)."
>
> You could still iterate.  Since ptr++ would add 0 to the pointer, you
> would still always point to a/the void.
> What you can't do is take the distance.  Or reach the end.
>

Right, but in other places where you have infinite ranges, whether or not
the range is infinite does not usually simply depend on the element type.
That makes things really difficult. The main concern is code like the
following:

//////////
template<class T>
void foo()
{
  T bar[10];
  for(T* curr = bar, end = curr + 10; curr != end; ++curr) {}
}
//////////

For most Ts (all T's that can appear as an array element, currently) this
would iterate over each element. For void, if you make it size 0, this
would be an infinite loop. In places where void comes up as a dependent
type, you shouldn't be expected to special-case. It should just work. In
this case you could use range-based-for and the standard could have
std::begin/std::end yield something other than a pointer, but that is only
a partial solution.

My personal thoughts are that, at a higher level (outside of the scope of
this paper) we shouldn't assume that pointers are valid array iterators,
which would break down for size 0 types. I'm not about to make this
proposal try to tackle this and other issues since these problems are
somewhat orthogonal. Sean really wants size 0 void (and size 0 other
types), and I do as well, I just don't think it's feasible at this point in
time as a part of this proposal. It can still happen, but solving that
problem is much more difficult and there are many more subtle issues that
come from size 0 types regarding assumptions people are allowed to make in
current code (that type + address is unique for each object, for example).
Leaving void just unspecified on size for now (but still >= 1 as other
types) is fine, I think, and if we ever get size 0 types, I'd expect
implementations to make void be one of those types.


On Mon, Oct 5, 2015 at 12:37 PM, Tony V E <tvaneerd@gmail.com> wrote:

> Anyhow, I think the main purpose of the proposal will be to just see how
> the committee reacts to the idea.  I think you've done a good job at "it's
> not as big/scary as it sounds", but the reaction might still be "too
> scary", regardless of the details.  I almost don't think there's much sense
> discussing it here until we get a feel from the committee as to whether ANY
> regularized-void idea has a chance.
>

Yeah, that's my hope, though I'd like to have a better understanding of
reasons for push back prior to the meeting. In the other thread and
elsewhere, it seems as though some people have more philosophical concerns,
and I'd like to see these concerns explored in the context of this
proposal, especially regarding the two logging code snippets. Further, the
actual textual changes to the standard can be examined for any unintended
consequences.

--

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

--001a11c182266986ce052161716a
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, Oct 5, 2015 at 12:37 PM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mail=
to:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s=
olid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote"><span class=3D"">On Mon, Oct 5, 2015 at 2:43 PM, Matt Ca=
labrese <span dir=3D"ltr">&lt;<a href=3D"mailto:calabrese@google.com" targe=
t=3D"_blank">calabrese@google.com</a>&gt;</span> wrote:<br></span><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-le=
ft:1ex"><span class=3D""><div dir=3D"ltr"><div>Following the &quot;Allow va=
lues of void&quot; discussion, I&#39;ve put together a proposal[1] for upda=
ting void to be a Regular type. I&#39;m starting a new thread for this pape=
r specifically to get feedback on this proposal, which will be presented at=
 Kona. If there are questions or criticisms of the idea, try to keep them i=
n the context of this paper. In particular, I&#39;d like to keep this discu=
ssion a bit more grounded than the other and more specific to precisely wha=
t is proposed here -- what might this proposal break (apart from what is al=
ready explicitly covered in the paper unless there is more to add),=C2=A0ar=
e there examples of problems that people expect to be solved by void that a=
re not addressed here, do people see problems with any of the more subtle i=
ssues regarding the details of the proposed changes to the standard itself,=
 etc.. I&#39;m not strictly against tangents about void remaining a non-ins=
tantiable type, but if you are of that camp, please present your argument i=
n the context of this paper and with real world examples, for instance how =
such an approach would apply to the logging examples presented in the paper=
, what problems, if any, such an approach might solve that this cannot, etc=
...</div><div><br></div>[1] <a href=3D"http://www.open-std.org/jtc1/sc22/wg2=
1/docs/papers/2015/p0146r0.html" target=3D"_blank">http://www.open-std.org/=
jtc1/sc22/wg21/docs/papers/2015/p0146r0.html</a><span><font color=3D"#88888=
8"><br></font></span></div></span><span><font color=3D"#888888">

<p></p>

-- <br></font></span></blockquote><div><br>&quot;For instance, if you were =
to make an array of such a <code>void</code>=20
type, a pointer, at least in the traditional sense, would no longer be=20
able to be used as an iterator into that array (notably meaning that=20
generic code which relies on this would now fail for such a size <code>0</c=
ode> type).&quot;<br><br></div><div>You could still iterate.=C2=A0 Since pt=
r++ would add 0 to the pointer, you would still always point to a/the void.=
<br></div><div>What you can&#39;t do is take the distance.=C2=A0 Or reach t=
he end.<br></div></div></div></div></blockquote><div><br></div><div>Right, =
but in other places where you have infinite ranges, whether or not the rang=
e is infinite does not usually simply depend on the element type. That make=
s things really difficult. The main concern is code like the following:</di=
v><div><br></div><div>//////////</div><div>template&lt;class T&gt;</div><di=
v>void foo()</div><div>{</div><div>=C2=A0 T bar[10];</div><div>=C2=A0 for(T=
* curr =3D bar, end =3D curr + 10; curr !=3D end; ++curr) {}</div><div>}</d=
iv><div>//////////</div><div><br></div><div>For most Ts (all T&#39;s that c=
an appear as an array element, currently) this would iterate over each elem=
ent. For void, if you make it size 0, this would be an infinite loop. In pl=
aces where void comes up as a dependent type, you shouldn&#39;t be expected=
 to special-case. It should just work. In this case you could use range-bas=
ed-for and the standard could have std::begin/std::end yield something othe=
r than a pointer, but that is only a partial solution.</div><div><br></div>=
<div>My personal thoughts are that, at a higher level (outside of the scope=
 of this paper) we shouldn&#39;t assume that pointers are valid array itera=
tors, which would break down for size 0 types. I&#39;m not about to make th=
is proposal try to tackle this and other issues since these problems are so=
mewhat orthogonal. Sean really wants size 0 void (and size 0 other types), =
and I do as well, I just don&#39;t think it&#39;s feasible at this point in=
 time as a part of this proposal. It can still happen, but solving that pro=
blem is much more difficult and there are many more subtle issues that come=
 from size 0 types regarding assumptions people are allowed to make in curr=
ent code (that type + address is unique for each object, for example). Leav=
ing void just unspecified on size for now (but still &gt;=3D 1 as other typ=
es) is fine, I think, and if we ever get size 0 types, I&#39;d expect imple=
mentations to make void be one of those types.</div><div><br></div><div><br=
></div><div>On Mon, Oct 5, 2015 at 12:37 PM, Tony V E=C2=A0<span dir=3D"ltr=
">&lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmai=
l.com</a>&gt;</span>=C2=A0wrote:</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(=
204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><di=
v class=3D"gmail_extra"><div class=3D"gmail_quote"><div>Anyhow, I think the=
 main purpose of the proposal will be to just see how the committee reacts =
to the idea.=C2=A0 I think you&#39;ve done a good job at &quot;it&#39;s not=
 as big/scary as it sounds&quot;, but the reaction might still be &quot;too=
 scary&quot;, regardless of the details.=C2=A0 I almost don&#39;t think the=
re&#39;s much sense discussing it here until we get a feel from the committ=
ee as to whether ANY regularized-void idea has a chance.</div></div></div><=
/div></blockquote><div><br></div><div>Yeah, that&#39;s my hope, though I&#3=
9;d like to have a better understanding of reasons for push back prior to t=
he meeting. In the other thread and elsewhere, it seems as though some peop=
le have more philosophical concerns, and I&#39;d like to see these concerns=
 explored in the context of this proposal, especially regarding the two log=
ging code snippets. Further, the actual textual changes to the standard can=
 be examined for any unintended consequences.</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 />

--001a11c182266986ce052161716a--

.

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

You specifically mention possibly re-introducing the int "foo(void)"
syntax but note that it may create problems because it isn't an unary
function. Now I think this can be solved with three adjustments, let me
see if I missed anything:

(1) Let any function declared with no formal parameters "int foo()" be a
shortcut for and implicitly identical to "int foo(void)".
(2) Let any function that only takes a single formal parameter of type
void be callable with an empty argument list.
(3) When matching template arguments an explicit overload/specialization
of "int()" binds stronger than "int(T)" (where T <- void)

Rule (3) is only there to not change behavior of existing code that is
already specialized for nullary functions. I think this would make
"int()" and "int(void)" interchangable in every context and
(conceptually) remove all nullary functions from the language which IMHO
is a Good Thing.

Does this make sense?

Am 05.10.2015 um 20:43 schrieb Matt Calabrese:
> Following the "Allow values of void" discussion, I've put together a
> proposal[1] for updating void to be a Regular type. I'm starting a new
> thread for this paper specifically to get feedback on this proposal,
> which will be presented at Kona. If there are questions or criticisms
> of the idea, try to keep them in the context of this paper. In
> particular, I'd like to keep this discussion a bit more grounded than
> the other and more specific to precisely what is proposed here -- what
> might this proposal break (apart from what is already explicitly
> covered in the paper unless there is more to add), are there examples
> of problems that people expect to be solved by void that are not
> addressed here, do people see problems with any of the more subtle
> issues regarding the details of the proposed changes to the standard
> itself, etc.. I'm not strictly against tangents about void remaining a
> non-instantiable type, but if you are of that camp, please present
> your argument in the context of this paper and with real world
> examples, for instance how such an approach would apply to the logging
> examples presented in the paper, what problems, if any, such an
> approach might solve that this cannot, etc..
>
> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html
> --
>
> ---
> You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to std-proposals+unsubscribe@isocpp.org
> <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/.

--------------080700060804080403010009
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">
    You specifically mention possibly re-introducing the int "foo(void)"
    syntax but note that it may create problems because it isn't an
    unary function. Now I think this can be solved with three
    adjustments, let me see if I missed anything:<br>
    <br>
    (1) Let any function declared with no formal parameters "int foo()"
    be a shortcut for and implicitly identical to "int foo(void)".<br>
    (2) Let any function that only takes a single formal parameter of
    type void be callable with an empty argument list.<br>
    (3) When matching template arguments an explicit
    overload/specialization of "int()" binds stronger than "int(T)"
    (where T &lt;- void)<br>
    <br>
    Rule (3) is only there to not change behavior of existing code that
    is already specialized for nullary functions. I think this would
    make "int()" and "int(void)" interchangable in every context and
    (conceptually) remove all nullary functions from the language which
    IMHO is a Good Thing.<br>
    <br>
    Does this make sense?<br>
    <br>
    <div class=3D"moz-cite-prefix">Am 05.10.2015 um 20:43 schrieb Matt
      Calabrese:<br>
    </div>
    <blockquote
      cite=3D"mid:79f3023e-87e9-411d-b1cd-2acdb94fcdc6@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>Following the "Allow values of void" discussion, I've put
          together a proposal[1] for updating void to be a Regular type.
          I'm starting a new thread for this paper specifically to get
          feedback on this proposal, which will be presented at Kona. If
          there are questions or criticisms of the idea, try to keep
          them in the context of this paper. In particular, I'd like to
          keep this discussion a bit more grounded than the other and
          more specific to precisely what is proposed here -- what might
          this proposal break (apart from what is already explicitly
          covered in the paper unless there is more to add),=C2=A0are there
          examples of problems that people expect to be solved by void
          that are not addressed here, do people see problems with any
          of the more subtle issues regarding the details of the
          proposed changes to the standard itself, etc.. I'm not
          strictly against tangents about void remaining a
          non-instantiable type, but if you are of that camp, please
          present your argument in the context of this paper and with
          real world examples, for instance how such an approach would
          apply to the logging examples presented in the paper, what
          problems, if any, such an approach might solve that this
          cannot, etc..</div>
        <div><br>
        </div>
        [1]
        <a class=3D"moz-txt-link-freetext" href=3D"http://www.open-std.org/=
jtc1/sc22/wg21/docs/papers/2015/p0146r0.html">http://www.open-std.org/jtc1/=
sc22/wg21/docs/papers/2015/p0146r0.html</a><br>
      </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 />

--------------080700060804080403010009--

.

On 2015-10-05 15:37, Tony V E wrote:
> On Mon, Oct 5, 2015 at 2:43 PM, Matt Calabrese wrote:
>> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html
>
> "For instance, if you were to make an array of such a void type, a pointer,
> at least in the traditional sense, would no longer be able to be used as an
> iterator into that array (notably meaning that generic code which relies on
> this would now fail for such a size 0 type)."
>
> You could still iterate.  Since ptr++ would add 0 to the pointer, you would
> still always point to a/the void.
> What you can't do is take the distance.  Or reach the end.

Or, alternatively, the distance is always 0 and you are always already
*at* the end.

That said, I still think trying to solve the problem that templates only
handle the one-value case by removing the zero case from the existing
zero-or-one that is presently allowed is the wrong solution (and wrong
direction, i.e. a regression rather than progress), and we should
instead be working towards zero-or-many support. Languages with first
class multiple return values and language level multi-value support
(e.g. unpacking) do much better in this realm.

Perhaps the largest questions I would keep in mind are:

- How do we deal with the implications of claiming that void is a
regular type, when a void function *has no return value* (keep in mind
this may have ABI and/or register allocation implications).

- If at some point we add first class multiple return values from
functions, how will we reconcile that 'void foo()' returns *zero* values
and not one value? Related, how do we explain away 'return;' as a
zero-value return in a function whose return type is specified as
"void", especially in the face of syntax to actually return multiple values?

I don't see in the changes how you reconcile claiming that void is a
regular type with the fact that a void function *doesn't return a
value*, or for that matter how 'void foo() { return; }' is still
supposed to work.

--
Matthew

--

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

.

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

On Mon, Oct 5, 2015 at 1:34 PM, Matt Calabrese <calabrese@google.com> wrote:
>
> Right, but in other places where you have infinite ranges, whether or not
> the range is infinite does not usually simply depend on the element type.
> That makes things really difficult. The main concern is code like the
> following:
>
> //////////
> template<class T>
> void foo()
> {
>   T bar[10];
>   for(T* curr = bar, end = curr + 10; curr != end; ++curr) {}
> }
> //////////
>
> For most Ts (all T's that can appear as an array element, currently) this
> would iterate over each element. For void, if you make it size 0, this
> would be an infinite loop.
>

Woops, sorry, this would have the opposite problem -- it wouldn't execute
*any* iterations of the loop. Either way, the issue is that there is a
change in meaning based on the element type. The overall problem, in my
opinion, again, is our direct usage of pointers as iterators for all T,
instead of some more general abstraction (which could happen to be
implemented exactly as an iterator when the element size != 0). I don't
think it's appropriate to try to address that problem as a part of this
proposal, and I fear that it may end up being too difficult of an
assumption to ever change, and it may not even be worth it. The current
proposal would be compatible with such a hypothetical change to the
language, but it's not dependent on such a change. It's just more of a
nice-to-have.

--

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

--001a1142e648500fac052161bb99
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, Oct 5, 2015 at 1:34 PM, Matt Calabrese <span dir=3D"ltr">&lt;<a href=3D=
"mailto:calabrese@google.com" target=3D"_blank">calabrese@google.com</a>&gt=
;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div>Right, but in other places=
 where you have infinite ranges, whether or not the range is infinite does =
not usually simply depend on the element type. That makes things really dif=
ficult. The main concern is code like the following:</div><div><br></div><d=
iv>//////////</div><div>template&lt;class T&gt;</div><div>void foo()</div><=
div>{</div><div>=C2=A0 T bar[10];</div><div>=C2=A0 for(T* curr =3D bar, end=
 =3D curr + 10; curr !=3D end; ++curr) {}</div><div>}</div><div>//////////<=
/div><div><br></div><div>For most Ts (all T&#39;s that can appear as an arr=
ay element, currently) this would iterate over each element. For void, if y=
ou make it size 0, this would be an infinite loop.</div></div></div></div><=
/blockquote><div><br></div><div>Woops, sorry, this would have the opposite =
problem -- it wouldn&#39;t execute <i>any</i> iterations of the loop. Eithe=
r way, the issue is that there is a change in meaning based on the element =
type. The overall problem, in my opinion, again, is our direct usage of poi=
nters as iterators for all T, instead of some more general abstraction (whi=
ch could happen to be implemented exactly as an iterator when the element s=
ize !=3D 0). I don&#39;t think it&#39;s appropriate to try to address that =
problem as a part of this proposal, and I fear that it may end up being too=
 difficult of an assumption to ever change, and it may not even be worth it=
.. The current proposal would be compatible with such a hypothetical change =
to the language, but it&#39;s not dependent on such a change. It&#39;s just=
 more of a nice-to-have.</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 />

--001a1142e648500fac052161bb99--

.

------=_Part_926_1005607094.1444078753156
Content-Type: multipart/alternative;
 boundary="----=_Part_927_508052707.1444078753156"

------=_Part_927_508052707.1444078753156
Content-Type: text/plain; charset=UTF-8

On Monday, October 5, 2015 at 4:34:43 PM UTC-4, Matt Calabrese wrote:
>
> On Mon, Oct 5, 2015 at 12:37 PM, Tony V E <tvan...@gmail.com <javascript:>
> > wrote:
>>
>> On Mon, Oct 5, 2015 at 2:43 PM, Matt Calabrese <cala...@google.com
>> <javascript:>> wrote:
>>
>>> Following the "Allow values of void" discussion, I've put together a
>>> proposal[1] for updating void to be a Regular type. I'm starting a new
>>> thread for this paper specifically to get feedback on this proposal, which
>>> will be presented at Kona. If there are questions or criticisms of the
>>> idea, try to keep them in the context of this paper. In particular, I'd
>>> like to keep this discussion a bit more grounded than the other and more
>>> specific to precisely what is proposed here -- what might this proposal
>>> break (apart from what is already explicitly covered in the paper unless
>>> there is more to add), are there examples of problems that people expect to
>>> be solved by void that are not addressed here, do people see problems with
>>> any of the more subtle issues regarding the details of the proposed changes
>>> to the standard itself, etc.. I'm not strictly against tangents about void
>>> remaining a non-instantiable type, but if you are of that camp, please
>>> present your argument in the context of this paper and with real world
>>> examples, for instance how such an approach would apply to the logging
>>> examples presented in the paper, what problems, if any, such an approach
>>> might solve that this cannot, etc..
>>>
>>> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html
>>>
>>> --
>>>
>>
>> "For instance, if you were to make an array of such a void type, a
>> pointer, at least in the traditional sense, would no longer be able to be
>> used as an iterator into that array (notably meaning that generic code
>> which relies on this would now fail for such a size 0 type)."
>>
>> You could still iterate.  Since ptr++ would add 0 to the pointer, you
>> would still always point to a/the void.
>> What you can't do is take the distance.  Or reach the end.
>>
>
> Right, but in other places where you have infinite ranges, whether or not
> the range is infinite does not usually simply depend on the element type.
> That makes things really difficult. The main concern is code like the
> following:
>
> //////////
> template<class T>
> void foo()
> {
>   T bar[10];
>   for(T* curr = bar, end = curr + 10; curr != end; ++curr) {}
> }
> //////////
>
> For most Ts (all T's that can appear as an array element, currently) this
> would iterate over each element. For void, if you make it size 0, this
> would be an infinite loop. In places where void comes up as a dependent
> type, you shouldn't be expected to special-case. It should just work. In
> this case you could use range-based-for and the standard could have
> std::begin/std::end yield something other than a pointer, but that is only
> a partial solution.
>
> My personal thoughts are that, at a higher level (outside of the scope of
> this paper) we shouldn't assume that pointers are valid array iterators,
> which would break down for size 0 types.
>

Pointers not being valid iterators breaks pretty much the world at this
point. At the very least, you'd royally honk-off SG14 if you suddenly
declare that std::vector and std::array cannot use pointers for their
iterators.


> I'm not about to make this proposal try to tackle this and other issues
> since these problems are somewhat orthogonal. Sean really wants size 0 void
> (and size 0 other types), and I do as well, I just don't think it's
> feasible at this point in time as a part of this proposal. It can still
> happen, but solving that problem is much more difficult and there are many
> more subtle issues that come from size 0 types regarding assumptions people
> are allowed to make in current code (that type + address is unique for each
> object, for example). Leaving void just unspecified on size for now (but
> still >= 1 as other types) is fine, I think, and if we ever get size 0
> types, I'd expect implementations to make void be one of those types.
>

Well, when I was working through the issues with defining stateless types
<https://groups.google.com/a/isocpp.org/d/msg/std-proposals/u35GIuJECcQ/gxAxe5xBAQAJ>
(which are guaranteed to not take up space as members or base-classes of a
struct), I used the general rule that the type should work like regular
types as much as possible. They would have a non-zero size, for example, so
you could legitimately allocate them dynamically on the heap if you had
some reason to do so.

I ran into a fundamental problem with arrays through. At some point, you
have to violate *something*. These were the options:

1) stateless members that are arrayed take up space (thus sometimes
violating the "don't take up space" principle)

2) stateless members that are arrayed all have the same address (thus
violating the rules of pointer arithmetic and arrays)

3) stateless members cannot be arrayed (thus violating the rule of behaving
like regular types)

4) stateless types actually have sizeof return 0 (thus violating... well,
all kinds of things)

I considered #3 to be the less onerous solution. We both seemed to come to
the same conclusion on that one.

--

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

On Monday, October 5, 2015 at 4:34:43 PM UTC-4, Matt Calabrese wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"=
gmail_quote">On Mon, Oct 5, 2015 at 12:37 PM, Tony V E <span dir=3D"ltr">&l=
t;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"mwv4c3=
jpCwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;r=
eturn true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">tva=
n...@gmail.com</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>=
<div class=3D"gmail_quote"><span>On Mon, Oct 5, 2015 at 2:43 PM, Matt Calab=
rese <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-ob=
fuscated-mailto=3D"mwv4c3jpCwAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">cala...@google.com</a>&gt;</span> wrote:<br></span><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa=
dding-left:1ex"><span><div dir=3D"ltr"><div>Following the &quot;Allow value=
s of void&quot; discussion, I&#39;ve put together a proposal[1] for updatin=
g void to be a Regular type. I&#39;m starting a new thread for this paper s=
pecifically to get feedback on this proposal, which will be presented at Ko=
na. If there are questions or criticisms of the idea, try to keep them in t=
he context of this paper. In particular, I&#39;d like to keep this discussi=
on a bit more grounded than the other and more specific to precisely what i=
s proposed here -- what might this proposal break (apart from what is alrea=
dy explicitly covered in the paper unless there is more to add),=C2=A0are t=
here examples of problems that people expect to be solved by void that are =
not addressed here, do people see problems with any of the more subtle issu=
es regarding the details of the proposed changes to the standard itself, et=
c.. I&#39;m not strictly against tangents about void remaining a non-instan=
tiable type, but if you are of that camp, please present your argument in t=
he context of this paper and with real world examples, for instance how suc=
h an approach would apply to the logging examples presented in the paper, w=
hat problems, if any, such an approach might solve that this cannot, etc..<=
/div><div><br></div>[1] <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/d=
ocs/papers/2015/p0146r0.html" target=3D"_blank" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-s=
td.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0146r0.html\46sa\75D\=
46sntz\0751\46usg\75AFQjCNGFFGHgHIThkaWY3MV5oL4IIccqCA&#39;;return true;" o=
nclick=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwww.o=
pen-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0146r0.html\46sa=
\75D\46sntz\0751\46usg\75AFQjCNGFFGHgHIThkaWY3MV5oL4IIccqCA&#39;;return tru=
e;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2015/<wbr>p0146=
r0.html</a><span><font color=3D"#888888"><br></font></span></div></span><sp=
an><font color=3D"#888888">

<p></p>

-- <br></font></span></blockquote><div><br>&quot;For instance, if you were =
to make an array of such a <code>void</code>=20
type, a pointer, at least in the traditional sense, would no longer be=20
able to be used as an iterator into that array (notably meaning that=20
generic code which relies on this would now fail for such a size <code>0</c=
ode> type).&quot;<br><br></div><div>You could still iterate.=C2=A0 Since pt=
r++ would add 0 to the pointer, you would still always point to a/the void.=
<br></div><div>What you can&#39;t do is take the distance.=C2=A0 Or reach t=
he end.<br></div></div></div></div></blockquote><div><br></div><div>Right, =
but in other places where you have infinite ranges, whether or not the rang=
e is infinite does not usually simply depend on the element type. That make=
s things really difficult. The main concern is code like the following:</di=
v><div><br></div><div>//////////</div><div>template&lt;class T&gt;</div><di=
v>void foo()</div><div>{</div><div>=C2=A0 T bar[10];</div><div>=C2=A0 for(T=
* curr =3D bar, end =3D curr + 10; curr !=3D end; ++curr) {}</div><div>}</d=
iv><div>//////////</div><div><br></div><div>For most Ts (all T&#39;s that c=
an appear as an array element, currently) this would iterate over each elem=
ent. For void, if you make it size 0, this would be an infinite loop. In pl=
aces where void comes up as a dependent type, you shouldn&#39;t be expected=
 to special-case. It should just work. In this case you could use range-bas=
ed-for and the standard could have std::begin/std::end yield something othe=
r than a pointer, but that is only a partial solution.</div><div><br></div>=
<div>My personal thoughts are that, at a higher level (outside of the scope=
 of this paper) we shouldn&#39;t assume that pointers are valid array itera=
tors, which would break down for size 0 types.</div></div></div></div></blo=
ckquote><div><br>Pointers not being valid iterators breaks pretty much the =
world at this point. At the very least, you&#39;d royally honk-off SG14 if =
you suddenly declare that std::vector and std::array cannot use pointers fo=
r their iterators.<br>=C2=A0</div><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"><div><div class=3D"gmail_quote"><div>I&#39;m not abo=
ut to make this proposal try to tackle this and other issues since these pr=
oblems are somewhat orthogonal. Sean really wants size 0 void (and size 0 o=
ther types), and I do as well, I just don&#39;t think it&#39;s feasible at =
this point in time as a part of this proposal. It can still happen, but sol=
ving that problem is much more difficult and there are many more subtle iss=
ues that come from size 0 types regarding assumptions people are allowed to=
 make in current code (that type + address is unique for each object, for e=
xample). Leaving void just unspecified on size for now (but still &gt;=3D 1=
 as other types) is fine, I think, and if we ever get size 0 types, I&#39;d=
 expect implementations to make void be one of those types.</div></div></di=
v></div></blockquote><div><br>Well, when I was <a href=3D"https://groups.go=
ogle.com/a/isocpp.org/d/msg/std-proposals/u35GIuJECcQ/gxAxe5xBAQAJ">working=
 through the issues with defining stateless types</a>  (which are guarantee=
d to not take up space as members or base-classes of a struct), I used the =
general rule that the type should work like regular types as much as possib=
le. They would have a non-zero size, for example, so you could legitimately=
 allocate them dynamically on the heap if you had some reason to do so.<br>=
<br>I ran into a fundamental problem with arrays through. At some point, yo=
u have to violate <i>something</i>. These were the options:<br><br>1) state=
less members that are arrayed take up space (thus sometimes violating the &=
quot;don&#39;t take up space&quot; principle)<br><br>2) stateless members t=
hat are arrayed all have the same address (thus violating the rules of poin=
ter arithmetic and arrays)<br><br>3) stateless members cannot be arrayed (t=
hus violating the rule of behaving like regular types)<br><br>4) stateless =
types actually have sizeof return 0 (thus violating... well, all kinds of t=
hings)<br><br>I considered #3 to be the less onerous solution. We both seem=
ed to come to the same conclusion on that one.<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_927_508052707.1444078753156--
------=_Part_926_1005607094.1444078753156--

.

Am 05.10.2015 um 22:53 schrieb Matthew Woehlke:
> On 2015-10-05 15:37, Tony V E wrote:
>> On Mon, Oct 5, 2015 at 2:43 PM, Matt Calabrese wrote:
>>> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html
>> "For instance, if you were to make an array of such a void type, a pointer,
>> at least in the traditional sense, would no longer be able to be used as an
>> iterator into that array (notably meaning that generic code which relies on
>> this would now fail for such a size 0 type)."
>>
>> You could still iterate.  Since ptr++ would add 0 to the pointer, you would
>> still always point to a/the void.
>> What you can't do is take the distance.  Or reach the end.
> Or, alternatively, the distance is always 0 and you are always already
> *at* the end.
>
> That said, I still think trying to solve the problem that templates only
> handle the one-value case by removing the zero case from the existing
> zero-or-one that is presently allowed is the wrong solution (and wrong
> direction, i.e. a regression rather than progress), and we should
> instead be working towards zero-or-many support. Languages with first
> class multiple return values and language level multi-value support
> (e.g. unpacking) do much better in this realm.
And some of these languages use the unit type to represent the 0-tuple.
>
> Perhaps the largest questions I would keep in mind are:
>
> - How do we deal with the implications of claiming that void is a
> regular type, when a void function *has no return value* (keep in mind
> this may have ABI and/or register allocation implications).
It is still a builtin type the compiler can handle under the as-if rule.
Since the void type, even if a regular unit type, has only a single
possible state it can exist in, the compiler can create one out of thin
air if required. It's existence doesn't have to be acknowledged in the
generated code or at the ABI level. It is a language-level thing only.
Yes, if you start taking a void variable's address or make it a member
variable that is where code generation may be affected, but until then
the compiler does not need to waste a single cycle or register on void
variables because they all have the same value. It still doesn't change
anything at the call/return site.
>
> - If at some point we add first class multiple return values from
> functions, how will we reconcile that 'void foo()' returns *zero* values
> and not one value? Related, how do we explain away 'return;' as a
> zero-value return in a function whose return type is specified as
> "void", especially in the face of syntax to actually return multiple values?
This is a red herring. If we look at type theory then a function
returning *no value* is a function that does not terminate by returning
to its caller (look up bottom type and unit type). The unit type is used
to identify functions that return to the caller but have no return value
that holds any meaningful information besides "I'm done". This is why
void in its current form is neither bottom nor unit type but something
inbetween.
>
> I don't see in the changes how you reconcile claiming that void is a
> regular type with the fact that a void function *doesn't return a
> value*, or for that matter how 'void foo() { return; }' is still
> supposed to work.
>
With this proposal void becomes a unit type. It can have only one
possible value. At the language level the compiler can just create it if
omitted in a return or call statement. There is no impact on code
generation or ABI breakage, it's a purely language-level abstraction
with no runtime implications unless ODR-used.

--

---
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_1974_989330230.1444081116220
Content-Type: multipart/alternative;
 boundary="----=_Part_1975_1262166682.1444081116220"

------=_Part_1975_1262166682.1444081116220
Content-Type: text/plain; charset=UTF-8

On Monday, October 5, 2015 at 1:43:06 PM UTC-5, Matt Calabrese wrote:
>
>
> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html
>

You're going to have to do something about the last sentence in
stmt.return/2: "Flowing off the end of a function is equivalent to a return
with no value; this results in undefined behavior in a value-returning
function." The consequence of the proposed change is that all existing
functions that return void will have undefined behavior.

--

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

<div dir=3D"ltr">On Monday, October 5, 2015 at 1:43:06 PM UTC-5, Matt Calab=
rese 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><br></div>[1] <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/pap=
ers/2015/p0146r0.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"th=
is.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%=
2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0146r0.html\46sa\75D\46sntz\=
0751\46usg\75AFQjCNGFFGHgHIThkaWY3MV5oL4IIccqCA&#39;;return true;" onclick=
=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-st=
d.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0146r0.html\46sa\75D\4=
6sntz\0751\46usg\75AFQjCNGFFGHgHIThkaWY3MV5oL4IIccqCA&#39;;return true;">ht=
tp://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2015/<wbr>p0146r0.htm=
l</a></div></blockquote><div><br></div><div>You&#39;re going to have to do =
something about the last sentence in stmt.return/2: &quot;Flowing off the e=
nd of a function is equivalent to a return with no value; this results in u=
ndefined behavior in a value-returning function.&quot; The consequence of t=
he proposed change is that all existing functions that return void will hav=
e undefined behavior.</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_1975_1262166682.1444081116220--
------=_Part_1974_989330230.1444081116220--

.

--94eb2c0961c4483c9f05216258a5
Content-Type: text/plain; charset=UTF-8

On Mon, Oct 5, 2015 at 1:38 PM, Miro Knejp <miro.knejp@gmail.com> wrote:

> You specifically mention possibly re-introducing the int "foo(void)"
> syntax but note that it may create problems because it isn't an unary
> function. Now I think this can be solved with three adjustments, let me see
> if I missed anything:
>

I think you get it. To restate, the idea is that right now, void foo(void)
is equivalent to void foo(), which we'd want to change. void foo(void)
should really mean what it says, assuming that void is an object type (in
other words it should be a unary function instead of a nullary function). I
just don't propose that we change the meaning just yet.

 On Mon, Oct 5, 2015 at 1:38 PM, Miro Knejp <miro.knejp@gmail.com> wrote:

> (1) Let any function declared with no formal parameters "int foo()" be a
> shortcut for and implicitly identical to "int foo(void)".
> (2) Let any function that only takes a single formal parameter of type
> void be callable with an empty argument list.
> (3) When matching template arguments an explicit overload/specialization
> of "int()" binds stronger than "int(T)" (where T <- void)
>

I should have maybe mentioned this in the proposal. I suggested a solution
sort of similar to this in the middle of the long thread "Allow values of
void," but I've since decided it's somewhat questionable (I further
suggested generalizing it so that any "empty" argument, regardless of the
location in the argument list, can be considered to be equivalent to doing
void{}, making something like foo(5, 'a', , 3.0) valid, with the third
argument being void{}). The difference between what you are suggesting and
what I was suggesting is that I still think that we'd *need* to keep the
function types separate between int foo(void) and int foo(). If we didn't,
we could have really subtle differences between void and other types here
that can still break generic code. With the function types being equal, for
instance, if you had both of those declarations you'd now be producing two
overloads for all types T except void, but for void it would re-declare the
same function and can cause other problems, such as if those declarations
were both definitions. When void is a dependent type there, this becomes
particularly subtle and can require special-casing. As well, if you agree
with my rationale for why the function declarations would need to be
separate types, then this also now implies that existing code is
potentially broken, since right now it is allowable to do: void foo(); void
foo(void) {} and the definition is the definition of the declared function.
If we changed this, it means that any existing code that does this would
now likely break. This can really be bad if the code that does this is a
part of a compiled dependency.

In addition to that, the other reason I strayed from this type of approach
is that it requires an altered kind of overload set to be considered when
there is a single argument of type void. So there is more special-casing on
the implementation side, and potentially this needs to be understood by
callers to avoid subtleties. Ultimately, the language would be simpler
without this rule, and I think if we designed the language from scratch we
wouldn't have such a rule, so we should ideally try to more directly get
what we want, only accounting for compatibility in the places where it is
strictly necessary. I don't think we gain much by trying to do this sort of
thing, but we definitely make the language more complex and add some
subtleties that are special to void.

On Mon, Oct 5, 2015 at 1:38 PM, Miro Knejp <miro.knejp@gmail.com> wrote:

> Does this make sense?
>

Yes. I may bring this up at the meeting and I don't know why I left it out
of the paper since I did seriously consider it early on. My thoughts at the
moment are still that we should avoid this, but that was not always my
intuition.

--

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

--94eb2c0961c4483c9f05216258a5
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, Oct 5, 2015 at 1:38 PM, Miro Knejp <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:miro.knejp@gmail.com" target=3D"_blank">miro.knejp@gmail.com</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    You specifically mention possibly re-introducing the int &quot;foo(void=
)&quot;
    syntax but note that it may create problems because it isn&#39;t an
    unary function. Now I think this can be solved with three
    adjustments, let me see if I missed anything:<br></div></blockquote><di=
v><br></div><div>I think you get it. To restate, the idea is that right now=
, void foo(void) is equivalent to void foo(), which we&#39;d want to change=
.. void foo(void) should really mean what it says, assuming that void is an =
object type (in other words it should be a unary function instead of a null=
ary function). I just don&#39;t propose that we change the meaning just yet=
..</div><div><br></div><div>=C2=A0On Mon, Oct 5, 2015 at 1:38 PM, Miro Knejp=
=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:miro.knejp@gmail.com" target=
=3D"_blank">miro.knejp@gmail.com</a>&gt;</span>=C2=A0wrote:</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width=
:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-lef=
t:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
    (1) Let any function declared with no formal parameters &quot;int foo()=
&quot;
    be a shortcut for and implicitly identical to &quot;int foo(void)&quot;=
..<br>
    (2) Let any function that only takes a single formal parameter of
    type void be callable with an empty argument list.<br>
    (3) When matching template arguments an explicit
    overload/specialization of &quot;int()&quot; binds stronger than &quot;=
int(T)&quot;
    (where T &lt;- void)<br></div></blockquote><div><br></div><div>I should=
 have maybe mentioned this in the proposal. I suggested a solution sort of =
similar to this in the middle of the long thread &quot;Allow values of void=
,&quot; but I&#39;ve since decided it&#39;s somewhat questionable (I furthe=
r suggested generalizing it so that any &quot;empty&quot; argument, regardl=
ess of the location in the argument list, can be considered to be equivalen=
t to doing void{}, making something like foo(5, &#39;a&#39;, , 3.0) valid, =
with the third argument being void{}). The difference between what you are =
suggesting and what I was suggesting is that I still think that we&#39;d <i=
>need</i> to keep the function types separate between int foo(void) and int=
 foo(). If we didn&#39;t, we could have really subtle differences between v=
oid and other types here that can still break generic code. With the functi=
on types being equal, for instance, if you had both of those declarations y=
ou&#39;d now be producing two overloads for all types T except void, but fo=
r void it would re-declare the same function and can cause other problems, =
such as if those declarations were both definitions.=C2=A0When void is a de=
pendent type there, this becomes particularly subtle and can require specia=
l-casing. As well, if you agree with my rationale for why the function decl=
arations would need to be separate types, then this also now implies that e=
xisting code is potentially broken, since right now it is allowable to do: =
void foo(); void foo(void) {} and the definition is the definition of the d=
eclared function. If we changed this, it means that any existing code that =
does this would now likely break. This can really be bad if the code that d=
oes this is a part of a compiled dependency.</div><div><br></div><div>In ad=
dition to that, the other reason I strayed from this type of approach is th=
at it requires an altered kind of overload set to be considered when there =
is a single argument of type void. So there is more special-casing on the i=
mplementation side, and potentially this needs to be understood by callers =
to avoid subtleties. Ultimately, the language would be simpler without this=
 rule, and I think if we designed the language from scratch we wouldn&#39;t=
 have such a rule, so we should ideally try to more directly get what we wa=
nt, only accounting for compatibility in the places where it is strictly ne=
cessary. I don&#39;t think we gain much by trying to do this sort of thing,=
 but we definitely make the language more complex and add some subtleties t=
hat are special to void.</div><div><br></div><div>On Mon, Oct 5, 2015 at 1:=
38 PM, Miro Knejp=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:miro.knejp@g=
mail.com" target=3D"_blank">miro.knejp@gmail.com</a>&gt;</span>=C2=A0wrote:=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s=
olid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
    Does this make sense?</div></blockquote></div><br></div><div class=3D"g=
mail_extra">Yes. I may bring this up at the meeting and I don&#39;t know wh=
y I left it out of the paper since I did seriously consider it early on. My=
 thoughts at the moment are still that we should avoid this, but that was n=
ot always my intuition.</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 />

--94eb2c0961c4483c9f05216258a5--

.

------=_Part_883_1565109771.1444081259304
Content-Type: multipart/alternative;
 boundary="----=_Part_884_2038859909.1444081259304"

------=_Part_884_2038859909.1444081259304
Content-Type: text/plain; charset=UTF-8

On Monday, October 5, 2015 at 4:38:36 PM UTC-5, Casey Carter wrote:
>
> On Monday, October 5, 2015 at 1:43:06 PM UTC-5, Matt Calabrese wrote:
>>
>>
>> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html
>>
>
> You're going to have to do something about the last sentence in
> stmt.return/2: "Flowing off the end of a function is equivalent to a return
> with no value; this results in undefined behavior in a value-returning
> function." The consequence of the proposed change is that all existing
> functions that return void will have undefined behavior.
>

Sorry, I meant "all existing functions with return type void that return
with no value, or by flowing off the end of the function, will have
undefined behavior with the proposed change." Obviously there are currently
valid cases in the language where return can be used with an expression of
void type that would continue to have defined behavior.

--

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

On Monday, October 5, 2015 at 4:38:36 PM UTC-5, Casey Carter wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Monday, October 5,=
 2015 at 1:43:06 PM UTC-5, Matt Calabrese wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><div><br></div>[1] <a href=3D"http://www.open=
-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html" rel=3D"nofollow" tar=
get=3D"_blank" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\=
75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015=
%2Fp0146r0.html\46sa\75D\46sntz\0751\46usg\75AFQjCNGFFGHgHIThkaWY3MV5oL4IIc=
cqCA&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/u=
rl?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2=
F2015%2Fp0146r0.html\46sa\75D\46sntz\0751\46usg\75AFQjCNGFFGHgHIThkaWY3MV5o=
L4IIccqCA&#39;;return true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/do=
cs/papers/2015/<wbr>p0146r0.html</a></div></blockquote><div><br></div><div>=
You&#39;re going to have to do something about the last sentence in stmt.re=
turn/2: &quot;Flowing off the end of a function is equivalent to a return w=
ith no value; this results in undefined behavior in a value-returning funct=
ion.&quot; The consequence of the proposed change is that all existing func=
tions that return void will have undefined behavior.</div></div></blockquot=
e><div><br></div><div>Sorry, I meant &quot;all existing functions with retu=
rn type void that return with no value, or by flowing off the end of the fu=
nction, will have undefined behavior with the proposed change.&quot; Obviou=
sly there are currently valid cases in the language where return can be use=
d with an expression of void type that would continue to have defined behav=
ior.=C2=A0</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_884_2038859909.1444081259304--
------=_Part_883_1565109771.1444081259304--

.

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

On Mon, Oct 5, 2015 at 1:59 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> Pointers not being valid iterators breaks pretty much the world at this
> point. At the very least, you'd royally honk-off SG14 if you suddenly
> declare that std::vector and std::array cannot use pointers for their
> iterators.
>

To be clear, I don't recommend making pointers not valid iterators, I just
mean separating out the abstractions. For example, already in C++ a
std::vector's iterator type may or may not be a pointer, though it *can* be
a pointer. In a sort of similar fashion, in my hypothetical future
proposal, an array iterator for most types *may* be the same type as the
iterator type, however, in the case of a size 0 type, the iterator type
would end up being different. In other words, if we allowed size 0 types,
generic code that deals with things like arrays shouldn't be using T* as
the iterator type *directly*, but rather, it should use an iterator type
that may end up being a pointer type in most cases, but isn't required to
be.

Again, that is a much bigger alteration to the standard and requires people
to understand and make these changes in their own generic code, and the
benefits, imo, are much less than some people imagine. Whether it's viable
or not, or whether people even share my view on such a hypothetical change,
are outside of the scope of the "Regular Void" proposal. Unless someone
sees some simple way to solve all of these problems with respect to size 0
types, I think it's best that we punt on the idea until some future point
in time. It doesn't impact the usability of void in generic code, it just
means in practice that in some very special cases, likely the product of
metaprogramming, we'd have slightly less memory-efficient types unless
people take special consideration (similar to the types of considerations
people make when exploiting the empty base optimization in generic code). I
think that's acceptable for the time being until/unless someone tackles the
harder problem of properly retrofitting support for size 0 types into the
language. I don't have particularly high hopes for that right now, but who
knows?

On Mon, Oct 5, 2015 at 1:59 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> Well, when I was working through the issues with defining stateless types
> <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/u35GIuJECcQ/gxAxe5xBAQAJ>
> (which are guaranteed to not take up space as members or base-classes of a
> struct), I used the general rule that the type should work like regular
> types as much as possible. They would have a non-zero size, for example, so
> you could legitimately allocate them dynamically on the heap if you had
> some reason to do so.
>

I think if we get size 0 types, you'd still be able to "allocate" them on
the heap in the sense that the operation would be a valid operation. I
don't think there is anything in conflict there. The main thing that is in
conflict with respect to C++ right now are assumptions surrounding
pointers, aliasing, etc..

On Mon, Oct 5, 2015 at 1:59 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> I ran into a fundamental problem with arrays through. At some point, you
> have to violate *something*. These were the options:
>
> 1) stateless members that are arrayed take up space (thus sometimes
> violating the "don't take up space" principle)
>
> 2) stateless members that are arrayed all have the same address (thus
> violating the rules of pointer arithmetic and arrays)
>
> 3) stateless members cannot be arrayed (thus violating the rule of
> behaving like regular types)
>
> 4) stateless types actually have sizeof return 0 (thus violating... well,
> all kinds of things)
>
> I considered #3 to be the less onerous solution. We both seemed to come to
> the same conclusion on that one.
>

Right, this is why my personal conclusion is that, in generic code, we
really shouldn't be assuming that a pointer is an iterator into an array.
It should be a separate abstraction. In other words, if we started from
scratch with the language, I'd say that we'd have pointers that you cannot
do any arithmetic on at all, and we'd have array iterators which you could
do pointer arithmetic on, and they'd be different types (maybe with
explicit convertibility in some cases). In practice, the implementation of
an array iterator would be exactly the same in most cases, though for types
of size 0, the iterator would be more like an integer. We'd also drop the
assumption of an object's type + address being unique. Hypothetically, all
instances, whether on the stack, heap, namespace scope, etc. could share
the same address and it wouldn't matter. We'd just have been starting
without the assumption that an address is meaningful as a part of the
object's identity. Unfortunately, I'm not too optimistic that we'd be able
to move the language in this direction even though I genuinely believe that
if we'd started from scratch this would be ideal.

--

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

--001a1137bdd0e7ac9a05216269b7
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, Oct 5, 2015 at 1:59 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</sp=
an> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-sty=
le:solid;padding-left:1ex"><div>Pointers not being valid iterators breaks p=
retty much the world at this point. At the very least, you&#39;d royally ho=
nk-off SG14 if you suddenly declare that std::vector and std::array cannot =
use pointers for their iterators.<br></div></blockquote><div><br></div><div=
>To be clear, I don&#39;t recommend making pointers not valid iterators, I =
just mean separating out the abstractions. For example, already in C++ a st=
d::vector&#39;s iterator type may or may not be a pointer, though it <i>can=
</i> be a pointer. In a sort of similar fashion, in my hypothetical future =
proposal, an array iterator for most types <i>may</i> be the same type as t=
he iterator type, however, in the case of a size 0 type, the iterator type =
would end up being different. In other words, if we allowed size 0 types, g=
eneric code that deals with things like arrays shouldn&#39;t be using T* as=
 the iterator type <i>directly</i>, but rather, it should use an iterator t=
ype that may end up being a pointer type in most cases, but isn&#39;t requi=
red to be.</div><div><br></div><div>Again, that is a much bigger alteration=
 to the standard and requires people to understand and make these changes i=
n their own generic code, and the benefits, imo, are much less than some pe=
ople imagine. Whether it&#39;s viable or not, or whether people even share =
my view on such a hypothetical change, are outside of the scope of the &quo=
t;Regular Void&quot; proposal. Unless someone sees some simple way to solve=
 all of these problems with respect to size 0 types, I think it&#39;s best =
that we punt on the idea until some future point in time. It doesn&#39;t im=
pact the usability of void in generic code, it just means in practice that =
in some very special cases, likely the product of metaprogramming, we&#39;d=
 have slightly less memory-efficient types unless people take special consi=
deration (similar to the types of considerations people make when exploitin=
g the empty base optimization in generic code). I think that&#39;s acceptab=
le for the time being until/unless someone tackles the harder problem of pr=
operly retrofitting support for size 0 types into the language. I don&#39;t=
 have particularly high hopes for that right now, but who knows?</div><div>=
<br></div><div>On Mon, Oct 5, 2015 at 1:59 PM, Nicol Bolas=C2=A0<span dir=
=3D"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmcke=
sson@gmail.com</a>&gt;</span>=C2=A0wrote:</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-c=
olor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>Well, =
when I was <a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-prop=
osals/u35GIuJECcQ/gxAxe5xBAQAJ" target=3D"_blank">working through the issue=
s with defining stateless types</a>  (which are guaranteed to not take up s=
pace as members or base-classes of a struct), I used the general rule that =
the type should work like regular types as much as possible. They would hav=
e a non-zero size, for example, so you could legitimately allocate them dyn=
amically on the heap if you had some reason to do so.<br></div></blockquote=
><div><br></div><div>I think if we get size 0 types, you&#39;d still be abl=
e to &quot;allocate&quot; them on the heap in the sense that the operation =
would be a valid operation. I don&#39;t think there is anything in conflict=
 there. The main thing that is in conflict with respect to C++ right now ar=
e assumptions surrounding pointers, aliasing, etc..</div><div>=C2=A0</div><=
div>On Mon, Oct 5, 2015 at 1:59 PM, Nicol Bolas=C2=A0<span dir=3D"ltr">&lt;=
<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.co=
m</a>&gt;</span>=C2=A0wrote:</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div>I ran into a fund=
amental problem with arrays through. At some point, you have to violate <i>=
something</i>. These were the options:<br><br>1) stateless members that are=
 arrayed take up space (thus sometimes violating the &quot;don&#39;t take u=
p space&quot; principle)<br><br>2) stateless members that are arrayed all h=
ave the same address (thus violating the rules of pointer arithmetic and ar=
rays)<br><br>3) stateless members cannot be arrayed (thus violating the rul=
e of behaving like regular types)<br><br>4) stateless types actually have s=
izeof return 0 (thus violating... well, all kinds of things)<br><br>I consi=
dered #3 to be the less onerous solution. We both seemed to come to the sam=
e conclusion on that one.<br></div></blockquote><div><br></div><div>Right, =
this is why my personal conclusion is that, in generic code, we really shou=
ldn&#39;t be assuming that a pointer is an iterator into an array. It shoul=
d be a separate abstraction. In other words, if we started from scratch wit=
h the language, I&#39;d say that we&#39;d have pointers that you cannot do =
any arithmetic on at all, and we&#39;d have array iterators which you could=
 do pointer arithmetic on, and they&#39;d be different types (maybe with ex=
plicit convertibility in some cases). In practice, the implementation of an=
 array iterator would be exactly the same in most cases, though for types o=
f size 0, the iterator would be more like an integer. We&#39;d also drop th=
e assumption of an object&#39;s type + address being unique. Hypothetically=
, all instances, whether on the stack, heap, namespace scope, etc. could sh=
are the same address and it wouldn&#39;t matter. We&#39;d just have been st=
arting without the assumption that an address is meaningful as a part of th=
e object&#39;s identity. Unfortunately, I&#39;m not too optimistic that we&=
#39;d be able to move the language in this direction even though I genuinel=
y believe that if we&#39;d started from scratch this would be ideal.</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 />

--001a1137bdd0e7ac9a05216269b7--

.

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

On Mon, Oct 5, 2015 at 2:38 PM, Casey Carter <cartec69@gmail.com> wrote:

> On Monday, October 5, 2015 at 1:43:06 PM UTC-5, Matt Calabrese wrote:
>>
>>
>> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html
>>
>
> You're going to have to do something about the last sentence in
> stmt.return/2: "Flowing off the end of a function is equivalent to a return
> with no value; this results in undefined behavior in a value-returning
> function." The consequence of the proposed change is that all existing
> functions that return void will have undefined behavior.
>

I didn't change anything that would [directly] affect the special-casing of
functions returning void in this respect. Is there something specific in my
listed changes that would make this no longer true that you can point to,
or is otherwise implied?

--

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

--001a1134b962a904b40521628754
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, Oct 5, 2015 at 2:38 PM, Casey Carter <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:cartec69@gmail.com" target=3D"_blank">cartec69@gmail.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D=
"">On Monday, October 5, 2015 at 1:43:06 PM UTC-5, Matt Calabrese wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div>[1] <a=
 href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.ht=
ml" rel=3D"nofollow" target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg=
21/docs/papers/2015/p0146r0.html</a></div></blockquote><div><br></div></spa=
n><div>You&#39;re going to have to do something about the last sentence in =
stmt.return/2: &quot;Flowing off the end of a function is equivalent to a r=
eturn with no value; this results in undefined behavior in a value-returnin=
g function.&quot; The consequence of the proposed change is that all existi=
ng functions that return void will have undefined behavior.</div></div></bl=
ockquote><div><br></div><div>I didn&#39;t change anything that would [direc=
tly] affect the special-casing of functions returning void in this respect.=
 Is there something specific in my listed changes that would make this no l=
onger true that you can point to, or is otherwise implied?=C2=A0</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 />

--001a1134b962a904b40521628754--

.

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

Am 05.10.2015 um 23:39 schrieb 'Matt Calabrese' via ISO C++ Standard -
Future Proposals:
>
> I should have maybe mentioned this in the proposal. I suggested a
> solution sort of similar to this in the middle of the long thread
> "Allow values of void," but I've since decided it's somewhat
> questionable (I further suggested generalizing it so that any "empty"
> argument, regardless of the location in the argument list, can be
> considered to be equivalent to doing void{}, making something like
> foo(5, 'a', , 3.0) valid, with the third argument being void{}). The
> difference between what you are suggesting and what I was suggesting
> is that I still think that we'd /need/ to keep the function types
> separate between int foo(void) and int foo(). If we didn't, we could
> have really subtle differences between void and other types here that
> can still break generic code. With the function types being equal, for
> instance, if you had both of those declarations you'd now be producing
> two overloads for all types T except void, but for void it would
> re-declare the same function and can cause other problems, such as if
> those declarations were both definitions. When void is a dependent
> type there, this becomes particularly subtle and can require
> special-casing. As well, if you agree with my rationale for why the
> function declarations would need to be separate types, then this also
> now implies that existing code is potentially broken, since right now
> it is allowable to do: void foo(); void foo(void) {} and the
> definition is the definition of the declared function. If we changed
> this, it means that any existing code that does this would now likely
> break. This can really be bad if the code that does this is a part of
> a compiled dependency.
Hmm maybe I didn't get this over well enough. In my approach "void
foo(); void foo(void) { }" defines the *same* function. There is no
breaking here. My implication is that we treat any function that is
declared/defined as "void foo()" as if it were declared/defined as "void
foo(void)". The two refer to the same entity and are interchangeable.
That alone would break existing code at the call site, unless we also
say that calling a "void foo(void)" function as "foo()" is equivalent to
"foo(void{})".

The (I think) only point where treating "void()" and "void(void)" as
identical signatures would break is in in template argument matching:

template<class R>
void foo(std::function<R()> f);

template<class R, class T>
void foo(std::function<R(T)> f);

Here we either have to specify that the "R()" overload binds stronger
than "R(T)" (where T=void), or that the signature "R()" is a shorthand
for "R(void)" (as it is in function decls/defs), because that is how
existing code works. I prefer the latter option. New code would ideally
no longer require the "R()" overload at all.

In summary, I propose to make "void()" just a typing-lazy shorthand for
"void(void)" in all contexts. It makes existing functions immediately
compatible with new libraries. What I am not sure about is how
frequently the expression "foo()" is used in SFINAE checks to filter out
nullary function types, as those might break under this change. I cannot
imagine a use case that wouldn't be solved easier with regular good ol'
overload matching though.

> In addition to that, the other reason I strayed from this type of
> approach is that it requires an altered kind of overload set to be
> considered when there is a single argument of type void. So there is
> more special-casing on the implementation side, and potentially this
> needs to be understood by callers to avoid subtleties. Ultimately, the
> language would be simpler without this rule, and I think if we
> designed the language from scratch we wouldn't have such a rule, so we
> should ideally try to more directly get what we want, only accounting
> for compatibility in the places where it is strictly necessary. I
> don't think we gain much by trying to do this sort of thing, but we
> definitely make the language more complex and add some subtleties that
> are special to void.
I agree that not having this rule would be better, but as with many
things in C++, we can teach people to not use old constructs that have
new and better alternatives. We can teach them that void foo() is really
just a shorthand for void foo(void) and that the remaining language
"just 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/.

--------------020308060402020803020305
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">
    Am 05.10.2015 um 23:39 schrieb 'Matt Calabrese' via ISO C++ Standard
    - Future Proposals:<br>
    <blockquote
cite=3D"mid:CANh8DE=3DHTiEGPtvK_G9zn-5iXXRnnUufUQKnzUFYpOahMbrNgw@mail.gmai=
l.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote"><br>
            <div>I should have maybe mentioned this in the proposal. I
              suggested a solution sort of similar to this in the middle
              of the long thread "Allow values of void," but I've since
              decided it's somewhat questionable (I further suggested
              generalizing it so that any "empty" argument, regardless
              of the location in the argument list, can be considered to
              be equivalent to doing void{}, making something like
              foo(5, 'a', , 3.0) valid, with the third argument being
              void{}). The difference between what you are suggesting
              and what I was suggesting is that I still think that we'd
              <i>need</i> to keep the function types separate between
              int foo(void) and int foo(). If we didn't, we could have
              really subtle differences between void and other types
              here that can still break generic code. With the function
              types being equal, for instance, if you had both of those
              declarations you'd now be producing two overloads for all
              types T except void, but for void it would re-declare the
              same function and can cause other problems, such as if
              those declarations were both definitions.=C2=A0When void is a
              dependent type there, this becomes particularly subtle and
              can require special-casing. As well, if you agree with my
              rationale for why the function declarations would need to
              be separate types, then this also now implies that
              existing code is potentially broken, since right now it is
              allowable to do: void foo(); void foo(void) {} and the
              definition is the definition of the declared function. If
              we changed this, it means that any existing code that does
              this would now likely break. This can really be bad if the
              code that does this is a part of a compiled dependency.</div>
          </div>
        </div>
      </div>
    </blockquote>
    Hmm maybe I didn't get this over well enough. In my approach "void
    foo(); void foo(void) { }" defines the *same* function. There is no
    breaking here. My implication is that we treat any function that is
    declared/defined as "void foo()" as if it were declared/defined as
    "void foo(void)". The two refer to the same entity and are
    interchangeable. That alone would break existing code at the call
    site, unless we also say that calling a "void foo(void)" function as
    "foo()" is equivalent to "foo(void{})".<br>
    <br>
    The (I think) only point where treating "void()" and "void(void)" as
    identical signatures would break is in in template argument
    matching:<br>
    <br>
    template&lt;class R&gt;<br>
    void foo(std::function&lt;R()&gt; f);<br>
    <br>
    template&lt;class R, class T&gt;<br>
    void foo(std::function&lt;R(T)&gt; f);<br>
    <br>
    Here we either have to specify that the "R()" overload binds
    stronger than "R(T)" (where T=3Dvoid), or that the signature "R()" is
    a shorthand for "R(void)" (as it is in function decls/defs), because
    that is how existing code works. I prefer the latter option. New
    code would ideally no longer require the "R()" overload at all.<br>
    <br>
    In summary, I propose to make "void()" just a typing-lazy shorthand
    for "void(void)" in all contexts. It makes existing functions
    immediately compatible with new libraries. What I am not sure about
    is how frequently the expression "foo()" is used in SFINAE checks to
    filter out nullary function types, as those might break under this
    change. I cannot imagine a use case that wouldn't be solved easier
    with regular good ol' overload matching though.<br>
    <br>
    <blockquote
cite=3D"mid:CANh8DE=3DHTiEGPtvK_G9zn-5iXXRnnUufUQKnzUFYpOahMbrNgw@mail.gmai=
l.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <div>In addition to that, the other reason I strayed from
              this type of approach is that it requires an altered kind
              of overload set to be considered when there is a single
              argument of type void. So there is more special-casing on
              the implementation side, and potentially this needs to be
              understood by callers to avoid subtleties. Ultimately, the
              language would be simpler without this rule, and I think
              if we designed the language from scratch we wouldn't have
              such a rule, so we should ideally try to more directly get
              what we want, only accounting for compatibility in the
              places where it is strictly necessary. I don't think we
              gain much by trying to do this sort of thing, but we
              definitely make the language more complex and add some
              subtleties that are special to void.</div>
          </div>
        </div>
      </div>
    </blockquote>
    I agree that not having this rule would be better, but as with many
    things in C++, we can teach people to not use old constructs that
    have new and better alternatives. We can teach them that void foo()
    is really just a shorthand for void foo(void) and that the remaining
    language "just works".<br>
    <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 />

--------------020308060402020803020305--

.

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

On Mon, Oct 5, 2015 at 1:53 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:
>
> I still think trying to solve the problem that templates only
> handle the one-value case by removing the zero case from the existing
> zero-or-one that is presently allowed is the wrong solution (and wrong
> direction, i.e. a regression rather than progress), and we should
> instead be working towards zero-or-many support. Languages with first
> class multiple return values and language level multi-value support
> (e.g. unpacking) do much better in this realm.
>

On some level I get what you're saying, but in practice we have 0-N support
by the way of tuples, and I think that is a reasonable solution (short of
the practical difficulties regarding copy/move elision). If you compare C++
functions to functions in mathematics (normally a questionable comparison,
but one that I think is fine in this particular context), this makes sense,
too, where your functions always map to some result, unless they are
undefined for certain input (analogous in C++ to input where preconditions
are violated). In mathematics, returning "multiple" values is really
returning a single vector of values. You don't actually lose anything by
that abstraction (I'd personally argue that you gain), it's just that when
you represent a function returning some fixed N different values in C++,
you analogously return it as a tuple of size N, where it's perfectly
acceptable for N to be 0. Further, even if we had a language-level solution
for returning N different values, you'd still want to be able to pass these
entities around as a single object *without* unpacking them as separate
arguments, otherwise examples like my second logging example (the one with
the verbosity option) break down. As well, without being able to pass
around such entities without unpacking them, generic code would become
difficult to write regarding forwarding of function return values to
functions as arguments, especially when such function results would appear
in the middle of a parameter list, and even more so if two different kinds
of results appear as parameter types of the same function (both of these
can easily come up in generic code). It's a much simpler abstraction to
deal with if the representation of 0-N results is just a single object that
*contains* 0-N components. Notably, with tuples like we already have, this
would work, because tuples are already object types that you can pass
around as a single entity (and you can unpack them, though with some more
effort than what a language-level facility can provide). Either way, that
top-level notion of the result being a single entity that can be passed
around as a whole like any other object is important.

In short, I'd argue that the language-level solution for 0-N return values
that you describe would likely be equivalent in functionality and similar
in usage tuples only with nicer syntax and possibly better ways of taking
advantage of copy/move elision. In practice they'd need to be a single,
first class object that may have multiple components (where "multiple" can
happen to be 0), not dissimilar from how I suggest void should be a
first-class object. You'd still want to have that top-level single object
abstraction regardless, and you'd want to be able to "store" the result on
the stack, pass it around packed or unpacked, and deal with it in all of
the same ways that you can deal with any other object in C++.

Finally, let's say we had hypothetical functions that could return 0-N
values by way of something like a language-level tuple-like construct. Even
in this case, I'm not certain that the implication is that "void" would or
should be equivalent to the "tuple with no elements" type. The reason I say
this is because in generic code that may yield 0-N results, the result
would be expressed using some tuple-like syntax (though now at the language
level), and an "empty" tuple there wouldn't usually appear simply as a type
written as "void," but rather it would end up looking much more like
current-day tuple<T...>., where sizeof...(T) would happen to be 0. If we
wanted void to *be* that empty tuple type, we'd really just be specifying
it as an alias to this type. At that point, I'd argue that we're not really
gaining anything from this alias, because users could just use the type
directly, and there's no reason to believe that we need these two types to
be the same or that void should logically be considered to be an empty
tuple as opposed to a monostate type. So even if we had language-level
support for 0-N return values, I'd argue that it's not necessarily true
that void should mean a 0-sized list of return types .

On Mon, Oct 5, 2015 at 1:53 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
 wrote:

> - How do we deal with the implications of claiming that void is a
> regular type, when a void function *has no return value* (keep in mind
> this may have ABI and/or register allocation implications).
>

The changes I've proposed should not be ABI breaking in practice, which I
briefly mention in the proposal.

On Mon, Oct 5, 2015 at 1:53 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
 wrote:

> - If at some point we add first class multiple return values from
> functions, how will we reconcile that 'void foo()' returns *zero* values
> and not one value? Related, how do we explain away 'return;' as a
> zero-value return in a function whose return type is specified as
> "void", especially in the face of syntax to actually return multiple
> values?
>

Assuming you don't completely disagree with my above analysis, I think that
this is not actually an issue. If you still think it is somehow an issue, I
suggest that you provide some more grounded examples in code as to why you
are unable to represent something.

On Mon, Oct 5, 2015 at 1:53 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
 wrote:

> I don't see in the changes how you reconcile claiming that void is a
> regular type with the fact that a void function *doesn't return a
> value*, or for that matter how 'void foo() { return; }' is still
> supposed to work.
>

"return;" still works perfectly fine in this proposal. It's effectively
just syntactic sugar for "return void{};" If we were to design the language
from scratch, *maybe* we wouldn't have this (in practice it's fine with or
without this, unless you really want a non-explicit return of such a
function to still be UB, which isn't an unreasonable consideration), but
it's not actually an issue. Again, this is just syntactic sugar and also
does not impact the ability to write proper generic code.

--

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

--001a1142e648696fbc052163610e
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, Oct 5, 2015 at 1:53 PM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204)=
;border-left-style:solid;padding-left:1ex">I still think trying to solve th=
e problem that templates only<br>
handle the one-value case by removing the zero case from the existing<br>
zero-or-one that is presently allowed is the wrong solution (and wrong<br>
direction, i.e. a regression rather than progress), and we should<br>
instead be working towards zero-or-many support. Languages with first<br>
class multiple return values and language level multi-value support<br>
(e.g. unpacking) do much better in this realm.<br></blockquote><div><br></d=
iv><div>On some level I get what you&#39;re saying, but in practice we have=
 0-N support by the way of tuples, and I think that is a reasonable solutio=
n (short of the practical difficulties regarding copy/move elision). If you=
 compare C++ functions to functions in mathematics (normally a questionable=
 comparison, but one that I think is fine in this particular context), this=
 makes sense, too, where your functions always map to some result,=C2=A0unl=
ess they are undefined for certain input (analogous in C++ to input where p=
reconditions are violated). In mathematics, returning &quot;multiple&quot; =
values is really returning a single vector of values. You don&#39;t actuall=
y lose anything by that abstraction (I&#39;d personally argue that you gain=
), it&#39;s just that when you represent a function returning some fixed N =
different values in C++, you analogously return it as a tuple of size N, wh=
ere it&#39;s perfectly acceptable for N to be 0. Further, even if we had a =
language-level solution for returning N different values, you&#39;d still w=
ant to be able to pass these entities around as a single object <i>without<=
/i> unpacking them as separate arguments, otherwise examples like my second=
 logging example (the one with the verbosity option) break down. As well, w=
ithout being able to pass around such entities without unpacking them, gene=
ric code would become difficult to write regarding forwarding of function r=
eturn values to functions as arguments, especially when such function resul=
ts would appear in the middle of a parameter list, and even more so if two =
different kinds of results appear as parameter types of the same function (=
both of these can easily come up in generic code). It&#39;s a much simpler =
abstraction to deal with if the representation of 0-N results is just a sin=
gle object that <i>contains</i>=C2=A00-N components.=C2=A0Notably, with tup=
les like we already have, this would work, because tuples are already objec=
t types that you can pass around as a single entity (and you can unpack the=
m, though with some more effort than what a language-level facility can pro=
vide). Either way, that top-level notion of the result being a single entit=
y that can be passed around as a whole like any other object is important.<=
/div><div><br></div><div>In short, I&#39;d argue that the language-level so=
lution for 0-N return values that you describe would likely be equivalent i=
n functionality and similar in usage tuples only with nicer syntax and poss=
ibly better ways of taking advantage of copy/move elision. In practice they=
&#39;d need to be a single, first class object that may have multiple compo=
nents (where &quot;multiple&quot; can happen to be 0), not dissimilar from =
how I suggest void should be a first-class object. You&#39;d still want to =
have that top-level single object abstraction regardless, and you&#39;d wan=
t to be able to &quot;store&quot; the result on the stack, pass it around p=
acked or unpacked, and deal with it in all of the same ways that you can de=
al with any other object in C++.</div><div><br></div><div>Finally, let&#39;=
s say we had hypothetical functions that could return 0-N values by way of =
something like a language-level tuple-like construct. Even in this case, I&=
#39;m not certain that the implication is that &quot;void&quot; would or sh=
ould be equivalent to the &quot;tuple with no elements&quot; type. The reas=
on I say this is because in generic code that may yield 0-N results, the re=
sult would be expressed using some tuple-like syntax (though now at the lan=
guage level), and an &quot;empty&quot; tuple there wouldn&#39;t usually app=
ear simply as a type written as &quot;void,&quot; but rather it would end u=
p looking much more like current-day tuple&lt;T...&gt;., where sizeof...(T)=
 would happen to be 0. If we wanted void to <i>be</i> that empty tuple type=
, we&#39;d really just be specifying it as an alias to this type. At that p=
oint, I&#39;d argue that we&#39;re not really gaining anything from this al=
ias, because users could just use the type directly, and there&#39;s no rea=
son to believe that we need these two types to be the same or that void sho=
uld logically be considered to be an empty tuple as opposed to a monostate =
type. So even if we had language-level support for 0-N return values, I&#39=
;d argue that it&#39;s not necessarily true that void should mean a 0-sized=
 list of return types .</div><div>=C2=A0</div><div>On Mon, Oct 5, 2015 at 1=
:53 PM, Matthew Woehlke=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:mwoehl=
ke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail.com</a>&gt;</spa=
n>=C2=A0wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde=
r-left-style:solid;padding-left:1ex">
- How do we deal with the implications of claiming that void is a<br>
regular type, when a void function *has no return value* (keep in mind<br>
this may have ABI and/or register allocation implications).<br></blockquote=
><div><br></div><div>The changes I&#39;ve proposed should not be ABI breaki=
ng in practice, which I briefly mention in the proposal.</div><div><br></di=
v><div>On Mon, Oct 5, 2015 at 1:53 PM, Matthew Woehlke=C2=A0<span dir=3D"lt=
r">&lt;<a href=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehl=
ke.floss@gmail.com</a>&gt;</span>=C2=A0wrote:</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
- If at some point we add first class multiple return values from<br>
functions, how will we reconcile that &#39;void foo()&#39; returns *zero* v=
alues<br>
and not one value? Related, how do we explain away &#39;return;&#39; as a<b=
r>
zero-value return in a function whose return type is specified as<br>
&quot;void&quot;, especially in the face of syntax to actually return multi=
ple values?<br></blockquote><div><br></div><div>Assuming you don&#39;t comp=
letely disagree with my above analysis, I think that this is not actually a=
n issue. If you still think it is somehow an issue, I suggest that you prov=
ide some more grounded examples in code as to why you are unable to represe=
nt something.</div><div><br></div><div>On Mon, Oct 5, 2015 at 1:53 PM, Matt=
hew Woehlke=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:mwoehlke.floss@gma=
il.com" target=3D"_blank">mwoehlke.floss@gmail.com</a>&gt;</span>=C2=A0wrot=
e:</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style=
:solid;padding-left:1ex">
I don&#39;t see in the changes how you reconcile claiming that void is a<br=
>
regular type with the fact that a void function *doesn&#39;t return a<br>
value*, or for that matter how &#39;void foo() { return; }&#39; is still<br=
>
supposed to work.<br></blockquote><div><br></div><div>&quot;return;&quot; s=
till works perfectly fine in this proposal. It&#39;s effectively just synta=
ctic sugar for &quot;return void{};&quot; If we were to design the language=
 from scratch, <i>maybe</i> we wouldn&#39;t have this (in practice it&#39;s=
 fine with or without this, unless you really want a non-explicit return of=
 such a function to still be UB, which isn&#39;t an unreasonable considerat=
ion), but it&#39;s not actually an issue. Again, this is just syntactic sug=
ar and also does not impact the ability to write proper generic code.</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 />

--001a1142e648696fbc052163610e--

.

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

On Mon, Oct 5, 2015 at 3:07 PM, Miro Knejp <miro.knejp@gmail.com> wrote:

> Am 05.10.2015 um 23:39 schrieb 'Matt Calabrese' via ISO C++ Standard -
> Future Proposals:
>
>
> I should have maybe mentioned this in the proposal. I suggested a solution
> sort of similar to this in the middle of the long thread "Allow values of
> void," but I've since decided it's somewhat questionable (I further
> suggested generalizing it so that any "empty" argument, regardless of the
> location in the argument list, can be considered to be equivalent to doing
> void{}, making something like foo(5, 'a', , 3.0) valid, with the third
> argument being void{}). The difference between what you are suggesting and
> what I was suggesting is that I still think that we'd *need* to keep the
> function types separate between int foo(void) and int foo(). If we didn't,
> we could have really subtle differences between void and other types here
> that can still break generic code. With the function types being equal, for
> instance, if you had both of those declarations you'd now be producing two
> overloads for all types T except void, but for void it would re-declare the
> same function and can cause other problems, such as if those declarations
> were both definitions. When void is a dependent type there, this becomes
> particularly subtle and can require special-casing. As well, if you agree
> with my rationale for why the function declarations would need to be
> separate types, then this also now implies that existing code is
> potentially broken, since right now it is allowable to do: void foo(); void
> foo(void) {} and the definition is the definition of the declared function.
> If we changed this, it means that any existing code that does this would
> now likely break. This can really be bad if the code that does this is a
> part of a compiled dependency.
>
> Hmm maybe I didn't get this over well enough. In my approach "void foo();
> void foo(void) { }" defines the *same* function. There is no breaking here.
> My implication is that we treat any function that is declared/defined as
> "void foo()" as if it were declared/defined as "void foo(void)". The two
> refer to the same entity and are interchangeable. That alone would break
> existing code at the call site, unless we also say that calling a "void
> foo(void)" function as "foo()" is equivalent to "foo(void{})".
>

Right, I think I understand what you're saying, but even this has
implications in generic code. Consider the following:

//////////
template<class T>
struct foo
{
  foo() { /**/ } // default constructor
  foo(T init) : bar(std::move(init)) {}

  T bar;
};
//////////

If we were to assume that a single void parameter were equal to no
parameters, then "foo" breaks down for the case that void is T,
unnecessarily. I don't think we should be introducing these kinds of
subtleties. Similarly, what is the arity of the function type "void(T)"
where T is dependent. We now have the somewhat unexpected implication that
the arity depends on what type "T" is. If we were to design the language
from scratch we wouldn't be doing this and I don't think there are many
tangible gains from making the language like this right now. We're not
really getting additional compatibility. It would only really help APIs
that would be transitioning from the old meaning of void to the new meaning
of void (for instance, it could potentially make it easier when
transitioning the std::promise API with respect to the removal of the
specialization, but there are alternatives that also aid in that transition
that do not require introducing more special-case rules for void). I think
simply deprecating the current meaning is better and will more likely lead
us closer to an ideal solution in the long term. It's also notably less
complex to specify in the language if void has no special-casing for things
like this.

On Mon, Oct 5, 2015 at 3:07 PM, Miro Knejp <miro.knejp@gmail.com> wrote:

> The (I think) only point where treating "void()" and "void(void)" as
> identical signatures would break is in in template argument matching:
>
> template<class R>
> void foo(std::function<R()> f);
>
> template<class R, class T>
> void foo(std::function<R(T)> f);
>
> Here we either have to specify that the "R()" overload binds stronger than
> "R(T)" (where T=void), or that the signature "R()" is a shorthand for
> "R(void)" (as it is in function decls/defs), because that is how existing
> code works. I prefer the latter option. New code would ideally no longer
> require the "R()" overload at all.
>

These are really subtle problems that we'd avoid by just not treating void
particularly special. I don't think introducing more special rules for void
will be good in the long term, and I'm not convinced it even really helps
much in the short term.

--

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

--001a1142e648b7f7520521639e85
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, Oct 5, 2015 at 3:07 PM, Miro Knejp <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:miro.knejp@gmail.com" target=3D"_blank">miro.knejp@gmail.com</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000"><span class=3D"">
    Am 05.10.2015 um 23:39 schrieb &#39;Matt Calabrese&#39; via ISO C++ Sta=
ndard
    - Future Proposals:<br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote"><br>
            <div>I should have maybe mentioned this in the proposal. I
              suggested a solution sort of similar to this in the middle
              of the long thread &quot;Allow values of void,&quot; but I&#3=
9;ve since
              decided it&#39;s somewhat questionable (I further suggested
              generalizing it so that any &quot;empty&quot; argument, regar=
dless
              of the location in the argument list, can be considered to
              be equivalent to doing void{}, making something like
              foo(5, &#39;a&#39;, , 3.0) valid, with the third argument bei=
ng
              void{}). The difference between what you are suggesting
              and what I was suggesting is that I still think that we&#39;d
              <i>need</i> to keep the function types separate between
              int foo(void) and int foo(). If we didn&#39;t, we could have
              really subtle differences between void and other types
              here that can still break generic code. With the function
              types being equal, for instance, if you had both of those
              declarations you&#39;d now be producing two overloads for all
              types T except void, but for void it would re-declare the
              same function and can cause other problems, such as if
              those declarations were both definitions.=C2=A0When void is a
              dependent type there, this becomes particularly subtle and
              can require special-casing. As well, if you agree with my
              rationale for why the function declarations would need to
              be separate types, then this also now implies that
              existing code is potentially broken, since right now it is
              allowable to do: void foo(); void foo(void) {} and the
              definition is the definition of the declared function. If
              we changed this, it means that any existing code that does
              this would now likely break. This can really be bad if the
              code that does this is a part of a compiled dependency.</div>
          </div>
        </div>
      </div>
    </blockquote></span>
    Hmm maybe I didn&#39;t get this over well enough. In my approach &quot;=
void
    foo(); void foo(void) { }&quot; defines the *same* function. There is n=
o
    breaking here. My implication is that we treat any function that is
    declared/defined as &quot;void foo()&quot; as if it were declared/defin=
ed as
    &quot;void foo(void)&quot;. The two refer to the same entity and are
    interchangeable. That alone would break existing code at the call
    site, unless we also say that calling a &quot;void foo(void)&quot; func=
tion as
    &quot;foo()&quot; is equivalent to &quot;foo(void{})&quot;.<br></div></=
blockquote><div><br></div><div>Right, I think I understand what you&#39;re =
saying, but even this has implications in generic code. Consider the follow=
ing:</div><div><br></div><div>//////////</div><div>template&lt;class T&gt;<=
/div><div>struct foo</div><div>{</div><div>=C2=A0 foo() { /**/ } // default=
 constructor</div><div>=C2=A0 foo(T init) : bar(std::move(init)) {}</div><d=
iv><br></div><div>=C2=A0 T bar;</div><div>};</div><div>//////////</div><div=
><br></div><div>If we were to assume that a single void parameter were equa=
l to no parameters, then &quot;foo&quot; breaks down for the case that void=
 is T, unnecessarily. I don&#39;t think we should be introducing these kind=
s of subtleties. Similarly, what is the arity of the function type &quot;vo=
id(T)&quot; where T is dependent. We now have the somewhat unexpected impli=
cation that the arity depends on what type &quot;T&quot; is. If we were to =
design the language from scratch we wouldn&#39;t be doing this and I don&#3=
9;t think there are many tangible gains from making the language like this =
right now. We&#39;re not really getting additional compatibility. It would =
only really help APIs that would be transitioning from the old meaning of v=
oid to the new meaning of void (for instance, it could potentially make it =
easier when transitioning the std::promise API with respect to the removal =
of the specialization, but there are alternatives that also aid in that tra=
nsition that do not require introducing more special-case rules for void). =
I think simply deprecating the current meaning is better and will more like=
ly lead us closer to an ideal solution in the long term. It&#39;s also nota=
bly less complex to specify in the language if void has no special-casing f=
or things like this.</div><div>=C2=A0</div><div>On Mon, Oct 5, 2015 at 3:07=
 PM, Miro Knejp=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:miro.knejp@gma=
il.com" target=3D"_blank">miro.knejp@gmail.com</a>&gt;</span>=C2=A0wrote:<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style=
:solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
    The (I think) only point where treating &quot;void()&quot; and &quot;vo=
id(void)&quot; as
    identical signatures would break is in in template argument
    matching:<br>
    <br>
    template&lt;class R&gt;<br>
    void foo(std::function&lt;R()&gt; f);<br>
    <br>
    template&lt;class R, class T&gt;<br>
    void foo(std::function&lt;R(T)&gt; f);<br>
    <br>
    Here we either have to specify that the &quot;R()&quot; overload binds
    stronger than &quot;R(T)&quot; (where T=3Dvoid), or that the signature =
&quot;R()&quot; is
    a shorthand for &quot;R(void)&quot; (as it is in function decls/defs), =
because
    that is how existing code works. I prefer the latter option. New
    code would ideally no longer require the &quot;R()&quot; overload at al=
l.<br></div></blockquote><div><br></div><div>These are really subtle proble=
ms that we&#39;d avoid by just not treating void particularly special. I do=
n&#39;t think introducing more special rules for void will be good in the l=
ong term, and I&#39;m not convinced it even really helps much in the short =
term.</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 />

--001a1142e648b7f7520521639e85--

.

On 10/05/2015 04:39 PM, 'Matt Calabrese' via ISO C++ Standard - Future
Proposals wrote:
> On Mon, Oct 5, 2015 at 1:38 PM, Miro Knejp <miro.knejp@gmail.com
> <mailto:miro.knejp@gmail.com>> wrote:
>
>     You specifically mention possibly re-introducing the int "foo(void)"
>     syntax but note that it may create problems because it isn't an
>     unary function. Now I think this can be solved with three
>     adjustments, let me see if I missed anything:
>
>
> I think you get it. To restate, the idea is that right now, void
> foo(void) is equivalent to void foo(), which we'd want to change. void
> foo(void) should really mean what it says, assuming that void is an
> object type (in other words it should be a unary function instead of a
> nullary function). I just don't propose that we change the meaning just yet.
[snip]
Wouldn't this allow:

  foo(foo())

since foo consumes a void and produces the same type?


--

---
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_30_2096402877.1444137639436
Content-Type: multipart/alternative;
 boundary="----=_Part_31_319303471.1444137639437"

------=_Part_31_319303471.1444137639437
Content-Type: text/plain; charset=UTF-8


On Monday, October 5, 2015 at 4:52:31 PM UTC-5, Matt Calabrese wrote:
>
> On Mon, Oct 5, 2015 at 2:38 PM, Casey Carter <cart...@gmail.com
> <javascript:>> wrote:
>
>> On Monday, October 5, 2015 at 1:43:06 PM UTC-5, Matt Calabrese wrote:
>>>
>>>
>>> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html
>>>
>>
>> You're going to have to do something about the last sentence in
>> stmt.return/2: "Flowing off the end of a function is equivalent to a return
>> with no value; this results in undefined behavior in a value-returning
>> function." The consequence of the proposed change is that all existing
>> functions that return void will have undefined behavior.
>>
>
> I didn't change anything that would [directly] affect the special-casing
> of functions returning void in this respect. Is there something specific in
> my listed changes that would make this no longer true that you can point
> to, or is otherwise implied?
>

You've left the statement "A return statement with no operand shall be used
only in a function whose return type is cv void, a constructor (12.1), or a
destructor (12.4)." in stmt.return, but it's not clear what the effect of
such a return should be. The final sentence clarifies the behavior:
"Flowing off the end of a function is equivalent to a return with no value;
this results in undefined behavior in a value-returning function." Since a
function returning void is now a value-returning function, void f(bool b) {
if (b) return; } has undefined behavior for exactly the same reasons as
std::nullptr_t g(bool b) { if (b) return; }.

--

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

<br>On Monday, October 5, 2015 at 4:52:31 PM UTC-5, Matt Calabrese wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote">On Mon, Oct 5, 2015 at 2:38 PM, Casey Carter <span dir=3D"=
ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D=
"kkA8ULftCwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:=
&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;">cart...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><span>On Monday, October 5, 2015 at 1:43:06 PM UTC-5, M=
att Calabrese wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div><br></div>[1] <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs=
/papers/2015/p0146r0.html" rel=3D"nofollow" target=3D"_blank" onmousedown=
=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-st=
d.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0146r0.html\46sa\75D\4=
6sntz\0751\46usg\75AFQjCNGFFGHgHIThkaWY3MV5oL4IIccqCA&#39;;return true;" on=
click=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwww.op=
en-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0146r0.html\46sa\=
75D\46sntz\0751\46usg\75AFQjCNGFFGHgHIThkaWY3MV5oL4IIccqCA&#39;;return true=
;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2015/<wbr>p0146r=
0.html</a></div></blockquote><div><br></div></span><div>You&#39;re going to=
 have to do something about the last sentence in stmt.return/2: &quot;Flowi=
ng off the end of a function is equivalent to a return with no value; this =
results in undefined behavior in a value-returning function.&quot; The cons=
equence of the proposed change is that all existing functions that return v=
oid will have undefined behavior.</div></div></blockquote><div><br></div><d=
iv>I didn&#39;t change anything that would [directly] affect the special-ca=
sing of functions returning void in this respect. Is there something specif=
ic in my listed changes that would make this no longer true that you can po=
int to, or is otherwise implied?=C2=A0</div></div></div></div></blockquote>=
<div><br></div><div>You&#39;ve left the statement &quot;A return statement =
with no operand shall be used only in a function whose return type is cv vo=
id, a constructor (12.1), or a destructor (12.4).&quot; in stmt.return, but=
 it&#39;s not clear what the effect of such a return should be. The final s=
entence clarifies the behavior: &quot;Flowing off the end of a function is =
equivalent to a return with no value; this results in undefined behavior in=
 a value-returning function.&quot; Since a function returning void is now a=
 value-returning function, <font face=3D"courier new, monospace">void f(boo=
l b) { if (b) return; }=C2=A0</font>has undefined behavior for exactly the =
same reasons as std::nullptr_t g(bool b) { if (b) return; }.</div><div><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_31_319303471.1444137639437--
------=_Part_30_2096402877.1444137639436--

.

On 2015-10-05 17:24, Miro Knejp wrote:
> Am 05.10.2015 um 22:53 schrieb Matthew Woehlke:
>> I don't see in the changes how you reconcile claiming that void is a
>> regular type with the fact that a void function *doesn't return a
>> value*, or for that matter how 'void foo() { return; }' is still
>> supposed to work.
>
> With this proposal void becomes a unit type. It can have only one
> possible value.

Saying "it's there" is nice, but doesn't answer the question. Can you
please point out where the proposal makes the necessary changes for
this? (Or explain why no changes are needed?)

--
Matthew

--

---
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 2015-10-05 18:53, Matt Calabrese wrote:
> Further, even if we had a language-level solution for returning N
> different values, you'd still want to be able to pass these entities
> around as a single object *without* unpacking them as separate
> arguments, otherwise examples like my second logging example (the one
> with the verbosity option) break down.

True, and that's similarly why I think that something like:

  void foo();
  auto x = foo();

....should be supported in any case. But *not* by making void a regular
type. There should be just as much difference between assigning to a
single variable from a 0-value function vs. a 1-value function as from
an N-value function vs. a 1-value function (for N > 1).

For what it's worth, I was strongly in favor of being able to treat
MRV's as a single object. There was also, however, some strong opposition.

> Even in this case, I'm not certain that the implication is that
> "void" would or should be equivalent to the "tuple with no elements"
> type.

I would find it very strange for it to mean otherwise, when this is what
it has meant historically.

Incidentally, I'm sure we would want some way to force a 1-value result
to be "packed" the same as an N-value result. We can't always pack it
for the sake of compatibility, but generic code would need a way to
ensure consistency.

--
Matthew

--

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

.

--Apple-Mail=_55614D76-762E-4EA9-9EC5-706F35710536
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 06 Oct 2015, at 16:00 , Matthew Woehlke <mwoehlke.floss@gmail.com> wro=
te:
>=20
> On 2015-10-05 17:24, Miro Knejp wrote:
>> Am 05.10.2015 um 22:53 schrieb Matthew Woehlke:
>>> I don't see in the changes how you reconcile claiming that void is a
>>> regular type with the fact that a void function *doesn't return a
>>> value*, or for that matter how 'void foo() { return; }' is still
>>> supposed to work.
>>=20
>> With this proposal void becomes a unit type. It can have only one
>> possible value.
>=20
> Saying "it's there" is nice, but doesn't answer the question. Can you
> please point out where the proposal makes the necessary changes for
> this? (Or explain why no changes are needed?)
Whether one says =E2=80=9Ca function returns no value=E2=80=9D or =E2=80=9C=
a function returns a value that represents nothing=E2=80=9D is a matter of =
perspective and only relevant at the language level. In a functional enviro=
nment functions have to return *something* to the caller, otherwise they te=
rminate in a different manner (like throwing). The unit type represents tha=
t the function finished its side effects and terminated by returning to the=
 caller.

void as a regular type compared to an empty user-defined struct has the adv=
antage that it is builtin and the compiler can sprinkle some fairy dust to =
make it disappear from the assembly as long as you don=E2=80=99t take its a=
ddress or make it a member variable. If the user-defined empty struct is tr=
ivial same applies under the as-if rule.

There is no point passing a regular void in registers because it has only *=
one* possible value. It is not a value you need to waste bits in a register=
 on, because the only value it can have is exactly =E2=80=9Cvoid{}=E2=80=9D=
 and nothing else. There is no actual bit-representable information that is=
 returned from a function that returns a unit-type void. The fact the funct=
ion returns means it produced a void value. If you need it, the compiler ca=
n create it out of thin air as it is just symbolic. Same goes for calling f=
unctions with a unit-type void. On the hardware level you aren=E2=80=99t pa=
ssing any bit-representable information to the function. The fact the funct=
ion executes means it got passed the void argument. If it needs to take its=
 address the compiler can again create it out of thin air.

Have a look here: http://melpon.org/wandbox/permlink/8zMjeSHKZaWxPBgs <http=
://melpon.org/wandbox/permlink/8zMjeSHKZaWxPBgs>

You can see that the implementation of foo() has no assembly to generate a =
return value and the assignment to the volatile variable just takes the add=
ress of a stack location with undefined content, which is fine because the =
actual bit pattern of X has no meaning.

If you uncomment the other stuff you can even see that the call to operator=
<< receives a single argument (the ostream), not two. The compiler decided =
to not pass an X to the function at all.

This shows that at least to this compiler an empty trivial user-defined str=
uct has the same semantics as void when it comes to generation of call/retu=
rn code. Therefore making void regular changes nothing in this context.

I don=E2=80=99t know if any ABIs support omitting empty structures so the c=
ompiler doesn=E2=80=99t have to waste stack space on arguments, but since u=
nit-type void is builtin it can be ignored in calls and returns the same wa=
y it already is.

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

--Apple-Mail=_55614D76-762E-4EA9-9EC5-706F35710536
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 06 Oct 2015, at 1=
6:00 , Matthew Woehlke &lt;<a href=3D"mailto:mwoehlke.floss@gmail.com" clas=
s=3D"">mwoehlke.floss@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-inte=
rchange-newline"><div class=3D"">On 2015-10-05 17:24, Miro Knejp wrote:<br =
class=3D""><blockquote type=3D"cite" class=3D"">Am 05.10.2015 um 22:53 schr=
ieb Matthew Woehlke:<br class=3D""><blockquote type=3D"cite" class=3D"">I d=
on't see in the changes how you reconcile claiming that void is a<br class=
=3D"">regular type with the fact that a void function *doesn't return a<br =
class=3D"">value*, or for that matter how 'void foo() { return; }' is still=
<br class=3D"">supposed to work.<br class=3D""></blockquote><br class=3D"">=
With this proposal void becomes a unit type. It can have only one<br class=
=3D"">possible value.<br class=3D""></blockquote><br class=3D"">Saying "it'=
s there" is nice, but doesn't answer the question. Can you<br class=3D"">pl=
ease point out where the proposal makes the necessary changes for<br class=
=3D"">this? (Or explain why no changes are needed?)<br class=3D""></div></b=
lockquote>Whether one says =E2=80=9Ca function returns no value=E2=80=9D or=
 =E2=80=9Ca function returns a value that represents nothing=E2=80=9D is a =
matter of perspective and only relevant at the language level. In a functio=
nal environment functions have to return *something* to the caller, otherwi=
se they terminate in a different manner (like throwing). The unit type repr=
esents that the function finished its side effects and terminated by return=
ing to the caller.</div><div><br class=3D""></div><div>void as a regular ty=
pe compared to an empty user-defined struct has the advantage that it is bu=
iltin and the compiler can sprinkle some fairy dust to make it disappear fr=
om the assembly as long as you don=E2=80=99t take its address or make it a =
member variable. If the user-defined empty struct is trivial same applies u=
nder the as-if rule.</div><div><br class=3D""></div><div>There is no point =
passing a regular void in registers because it has only *one* possible valu=
e. It is not a value you need to waste bits in a register on, because the o=
nly value it can have is exactly =E2=80=9Cvoid{}=E2=80=9D and nothing else.=
 There is no actual bit-representable information that is returned from a f=
unction that returns a unit-type void. The fact the function returns means =
it produced a void value. If you need it, the compiler can create it out of=
 thin air as it is just symbolic. Same goes for calling functions with a un=
it-type void. On the hardware level you aren=E2=80=99t passing any bit-repr=
esentable information to the function. The fact the function executes means=
 it got passed the void argument. If it needs to take its address the compi=
ler can again create it out of thin air.</div><div><br class=3D""></div><di=
v>Have a look here:&nbsp;<a href=3D"http://melpon.org/wandbox/permlink/8zMj=
eSHKZaWxPBgs" class=3D"">http://melpon.org/wandbox/permlink/8zMjeSHKZaWxPBg=
s</a></div><div><br class=3D""></div><div>You can see that the implementati=
on of foo() has no assembly to generate a return value and the assignment t=
o the volatile variable just takes the address of a stack location with und=
efined content, which is fine because the actual bit pattern of X has no me=
aning.</div><div><br class=3D""></div><div>If you uncomment the other stuff=
 you can even see that the call to operator&lt;&lt; receives a single argum=
ent (the ostream), not two. The compiler decided to not pass an X to the fu=
nction at all.</div><div><br class=3D""></div><div>This shows that at least=
 to this compiler an empty trivial user-defined struct has the same semanti=
cs as void when it comes to generation of call/return code. Therefore makin=
g void regular changes nothing in this context.</div><div><br class=3D""></=
div><div>I don=E2=80=99t know if any ABIs support omitting empty structures=
 so the compiler doesn=E2=80=99t have to waste stack space on arguments, bu=
t since unit-type void is builtin it can be ignored in calls and returns th=
e same way it already is.</div><div><br class=3D""></div></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 />

--Apple-Mail=_55614D76-762E-4EA9-9EC5-706F35710536--

.

--Apple-Mail=_86FBF7A1-31C8-45AC-B0DC-CE86BF48E656
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 06 Oct 2015, at 01:10 , 'Matt Calabrese' via ISO C++ Standard - Future=
 Proposals <std-proposals@isocpp.org> wrote:
>=20
> On Mon, Oct 5, 2015 at 3:07 PM, Miro Knejp <miro.knejp@gmail.com <mailto:=
miro.knejp@gmail.com>> wrote:
> Am 05.10.2015 um 23:39 schrieb 'Matt Calabrese' via ISO C++ Standard - Fu=
ture Proposals:
>>=20
>> I should have maybe mentioned this in the proposal. I suggested a soluti=
on sort of similar to this in the middle of the long thread "Allow values o=
f void," but I've since decided it's somewhat questionable (I further sugge=
sted generalizing it so that any "empty" argument, regardless of the locati=
on in the argument list, can be considered to be equivalent to doing void{}=
, making something like foo(5, 'a', , 3.0) valid, with the third argument b=
eing void{}). The difference between what you are suggesting and what I was=
 suggesting is that I still think that we'd need to keep the function types=
 separate between int foo(void) and int foo(). If we didn't, we could have =
really subtle differences between void and other types here that can still =
break generic code. With the function types being equal, for instance, if y=
ou had both of those declarations you'd now be producing two overloads for =
all types T except void, but for void it would re-declare the same function=
 and can cause other problems, such as if those declarations were both defi=
nitions. When void is a dependent type there, this becomes particularly sub=
tle and can require special-casing. As well, if you agree with my rationale=
 for why the function declarations would need to be separate types, then th=
is also now implies that existing code is potentially broken, since right n=
ow it is allowable to do: void foo(); void foo(void) {} and the definition =
is the definition of the declared function. If we changed this, it means th=
at any existing code that does this would now likely break. This can really=
 be bad if the code that does this is a part of a compiled dependency.
> Hmm maybe I didn't get this over well enough. In my approach "void foo();=
 void foo(void) { }" defines the *same* function. There is no breaking here=
.. My implication is that we treat any function that is declared/defined as =
"void foo()" as if it were declared/defined as "void foo(void)". The two re=
fer to the same entity and are interchangeable. That alone would break exis=
ting code at the call site, unless we also say that calling a "void foo(voi=
d)" function as "foo()" is equivalent to "foo(void{})".
>=20
> Right, I think I understand what you're saying, but even this has implica=
tions in generic code. Consider the following:
>=20
> //////////
> template<class T>
> struct foo
> {
>   foo() { /**/ } // default constructor
>   foo(T init) : bar(std::move(init)) {}
>=20
>   T bar;
> };
> //////////
Ah well this is unfortunate. So much for that idea then.

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

--Apple-Mail=_86FBF7A1-31C8-45AC-B0DC-CE86BF48E656
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dus-ascii"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode=
: space; -webkit-line-break: after-white-space;" class=3D""><br class=3D"">=
<div><blockquote type=3D"cite" class=3D""><div class=3D"">On 06 Oct 2015, a=
t 01:10 , 'Matt Calabrese' via ISO C++ Standard - Future Proposals &lt;<a h=
ref=3D"mailto:std-proposals@isocpp.org" class=3D"">std-proposals@isocpp.org=
</a>&gt; wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D"=
"><div dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div class=3D"gmai=
l_quote">On Mon, Oct 5, 2015 at 3:07 PM, Miro Knejp <span dir=3D"ltr" class=
=3D"">&lt;<a href=3D"mailto:miro.knejp@gmail.com" target=3D"_blank" class=
=3D"">miro.knejp@gmail.com</a>&gt;</span> wrote:<br class=3D""><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:=
1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000" class=3D""><span class=3D"">
    Am 05.10.2015 um 23:39 schrieb 'Matt Calabrese' via ISO C++ Standard
    - Future Proposals:<br class=3D"">
    <blockquote type=3D"cite" class=3D"">
      <div dir=3D"ltr" class=3D"">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote"><br class=3D"">
            <div class=3D"">I should have maybe mentioned this in the propo=
sal. I
              suggested a solution sort of similar to this in the middle
              of the long thread "Allow values of void," but I've since
              decided it's somewhat questionable (I further suggested
              generalizing it so that any "empty" argument, regardless
              of the location in the argument list, can be considered to
              be equivalent to doing void{}, making something like
              foo(5, 'a', , 3.0) valid, with the third argument being
              void{}). The difference between what you are suggesting
              and what I was suggesting is that I still think that we'd
              <i class=3D"">need</i> to keep the function types separate be=
tween
              int foo(void) and int foo(). If we didn't, we could have
              really subtle differences between void and other types
              here that can still break generic code. With the function
              types being equal, for instance, if you had both of those
              declarations you'd now be producing two overloads for all
              types T except void, but for void it would re-declare the
              same function and can cause other problems, such as if
              those declarations were both definitions.&nbsp;When void is a
              dependent type there, this becomes particularly subtle and
              can require special-casing. As well, if you agree with my
              rationale for why the function declarations would need to
              be separate types, then this also now implies that
              existing code is potentially broken, since right now it is
              allowable to do: void foo(); void foo(void) {} and the
              definition is the definition of the declared function. If
              we changed this, it means that any existing code that does
              this would now likely break. This can really be bad if the
              code that does this is a part of a compiled dependency.</div>
          </div>
        </div>
      </div>
    </blockquote></span>
    Hmm maybe I didn't get this over well enough. In my approach "void
    foo(); void foo(void) { }" defines the *same* function. There is no
    breaking here. My implication is that we treat any function that is
    declared/defined as "void foo()" as if it were declared/defined as
    "void foo(void)". The two refer to the same entity and are
    interchangeable. That alone would break existing code at the call
    site, unless we also say that calling a "void foo(void)" function as
    "foo()" is equivalent to "foo(void{})".<br class=3D""></div></blockquot=
e><div class=3D""><br class=3D""></div><div class=3D"">Right, I think I und=
erstand what you're saying, but even this has implications in generic code.=
 Consider the following:</div><div class=3D""><br class=3D""></div><div cla=
ss=3D"">//////////</div><div class=3D"">template&lt;class T&gt;</div><div c=
lass=3D"">struct foo</div><div class=3D"">{</div><div class=3D"">&nbsp; foo=
() { /**/ } // default constructor</div><div class=3D"">&nbsp; foo(T init) =
: bar(std::move(init)) {}</div><div class=3D""><br class=3D""></div><div cl=
ass=3D"">&nbsp; T bar;</div><div class=3D"">};</div><div class=3D"">///////=
///</div></div></div></div></div></blockquote>Ah well this is unfortunate. =
So much for that idea then.</div><div><br class=3D""></div></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 />

--Apple-Mail=_86FBF7A1-31C8-45AC-B0DC-CE86BF48E656--

.

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

On Mon, Oct 5, 2015 at 8:43 PM, Matt Calabrese <calabrese@google.com> wrote:

> Following the "Allow values of void" discussion, I've put together a
> proposal[1] for updating void to be a Regular type.
>

I've thought this through a couple of times before.

I think void should represent the absence of type, rather than be a type
that holds one value.  It is correctly, imho, incomplete.

I understand the extra work that has to be done occasionally in generic
programming where you have to write a separate specialization to deal with
void (and have done this personally more than once).

I do not think the time saved by this rare case, outweighs the time lost
from either migration to a "regular" void, or the end result of the strange
cases that come up:

   void p;
   void* q = &p;  // void* has special properties
   void A[10];
   std::vector<void> v;
   void f(void); // 0 or 1 parameter
   sizeof(void)
   SFINAE uses of void
   etc

It's a close call, but on the weight of it, the generic programming case
(which afaik is the only pro) I find insufficiently motivating.

--

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

--089e0111ceb62c101105217107d3
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, Oct 5, 2015 at 8:43 PM, Matt Calabrese <span dir=3D"ltr">&lt;<a href=3D=
"mailto:calabrese@google.com" target=3D"_blank">calabrese@google.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"><div>Fol=
lowing the &quot;Allow values of void&quot; discussion, I&#39;ve put togeth=
er a proposal[1] for updating void to be a Regular type.</div></div></block=
quote><div><br></div><div>I&#39;ve thought this through a couple of times b=
efore.</div><div><br></div><div>I think void should represent the absence o=
f type, rather than be a type that holds one value.=C2=A0 It is correctly, =
imho, incomplete.</div><div><br></div><div>I understand the extra work that=
 has to be done occasionally in generic programming where you have to write=
 a separate specialization to deal with void (and have done this personally=
 more than once).</div><div><br></div><div>I do not think the time saved by=
 this rare case, outweighs the time lost from either migration to a &quot;r=
egular&quot; void, or the end result of the strange cases that come up:</di=
v><div><br></div><div>=C2=A0 =C2=A0void p;</div><div>=C2=A0 =C2=A0void* q =
=3D &amp;p; =C2=A0// void* has special properties</div><div>=C2=A0 =C2=A0vo=
id A[10];</div><div>=C2=A0 =C2=A0std::vector&lt;void&gt; v;</div><div>=C2=
=A0 =C2=A0void f(void); // 0 or 1 parameter</div><div>=C2=A0 =C2=A0sizeof(v=
oid)</div><div>=C2=A0 =C2=A0SFINAE uses of void</div><div>=C2=A0 =C2=A0etc<=
/div><div><br></div><div>It&#39;s a close call, but on the weight of it, th=
e generic programming case (which afaik is the only pro) I find insufficien=
tly motivating.</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 />

--089e0111ceb62c101105217107d3--

.

------=_Part_714_2074713640.1444147581738
Content-Type: multipart/alternative;
 boundary="----=_Part_715_1929226672.1444147581739"

------=_Part_715_1929226672.1444147581739
Content-Type: text/plain; charset=UTF-8

I find this paper to be an interesting examination of the problem. It
attempts to make `void` as regular as one could reasonably expect such a
type to be.

However, the question is this: do we want `void` to be regular, or do we
want to avoid having to specialize templates for it in so many cases?

If the goal is to make `void` regular, then P0146 obviously fails. There
are too many occurrences of `void` being irregular for users to be able to
*generally* rely on type regularity.

I think that making `void` regular is simply the wrong goal. I really think
the goal should be to minimize the number of times you need to specialize
templates.

Take the logging function in P0147, for example:

// Invoke a callable, logging its arguments and return value.
template<class R, class... P, class Callable>
R invoke_and_log(callable_log<R(P...)>& log, Callable&& callable, P... args)
{
  log.log_arguments(args...);
  auto result = std::invoke(std::forward<Callable>(callable),
                            std::forward<P>(args)...);
  log.log_result(result);
  return result;
}

This stores a return value, logs it, and then returns that value. By its
very nature, it makes assumptions about the return value of `Callable`. The
return value *must* be copy/moveable; it can't return an immobile type. But
of course, that is the nature of the function, so users expect it.

However, this particular implementation of return value logging introduces
an unnecessary construct: a named object of the return type. You could
instead implement it like this:

// Invoke a callable, logging its arguments and return value.
template<class R, class... P, class Callable>
R invoke_and_log(callable_log<R(P...)>& log, Callable&& callable, P... args)
{
  log.log_arguments(args...);

  return log.log_result(
    std::invoke(std::forward<Callable>(callable),
      std::forward<P>(args)...));
}

By implementing it this way, you have removed the need for being able to
have a named `void` value. All you need in this case are two things:

1) The ability to return the result of a function call, even if that result
is `void`. I'm pretty sure we already have this.

2) The ability to pass the result of a function to another function, even
if that result is `void`. In the `void` case, the argument should
effectively disappear.

Oh, and `log.log_result` will need to have an overload that takes no
parameters.

By examining the problem domain like this, I think you can find ways to
avoid some of the more pernicious issues of `void` regularity. I'd guess
you can avoid having named values of `void` type. Which also means you can
avoid questions of getting references to `void`, passing them around as
arguments, copy/move, and so forth.

Oh sure, `void` will still be quite irregular. But I think, with a few
relaxed rules, template programmers will be able to avoid writing quite so
many specializations for `void`.

--

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

<div dir=3D"ltr">I find this paper to be an interesting examination of the =
problem. It attempts to make `void` as regular as one could reasonably expe=
ct such a type to be.<br><br>However, the question is this: do we want `voi=
d` to be regular, or do we want to avoid having to specialize templates for=
 it in so many cases?<br><br>If the goal is to make `void` regular, then P0=
146 obviously fails. There are too many occurrences of `void` being irregul=
ar for users to be able to <i>generally</i> rely on type regularity.<br><br=
>I think that making `void` regular is simply the wrong goal. I really thin=
k the goal should be to minimize the number of times you need to specialize=
 templates.<br><br>Take the logging function in P0147, for example:<br><br>=
<div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); b=
order-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; wo=
rd-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettypr=
int"><span style=3D"color: #800;" class=3D"styled-by-prettify">// Invoke a =
callable, logging its arguments and return value.</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">template</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> R</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">class<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">...</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> P</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"sty=
led-by-prettify">Callable</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>R invoke_and_log</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">callable_log</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">R</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">P</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">...)&gt;&amp;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> log</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #60=
6;" class=3D"styled-by-prettify">Callable</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">&amp;&amp;</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> callable</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> P</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">...</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> args</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: #660;" class=3D"styled-by-prettify">{</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 log</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">log_arguments</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">args</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">...);</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> result </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">invoke</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 st=
yle=3D"color: #000;" class=3D"styled-by-prettify">forward</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #606;" class=3D"styled-by-prettify">Callable</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&gt;(</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">callable</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">),</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 std</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">forward</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">P</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">&gt;(</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">args</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">)...);</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br>=C2=A0 log</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>log_result</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">result</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">return</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> result</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">}</span></div></code></div><br>This store=
s a return value, logs it, and then returns that value. By its very nature,=
 it makes assumptions about the return value of `Callable`. The return valu=
e <i>must</i> be copy/moveable; it can&#39;t return an immobile type. But o=
f course, that is the nature of the function, so users expect it.<br><br>Ho=
wever, this particular implementation of return value logging introduces an=
 unnecessary construct: a named object of the return type. You could instea=
d implement it like this:<br><br><div class=3D"prettyprint" style=3D"backgr=
ound-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-st=
yle: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prett=
yprint"><div class=3D"subprettyprint"><span style=3D"color: #800;" class=3D=
"styled-by-prettify">// Invoke a callable, logging its arguments and return=
 value.</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span><span style=3D"color: #008;" class=3D"styled-by-prettify">template<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">class</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> R</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"styled-by-prettify">class</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">...</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> P</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">class</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #606;" class=3D"styled-by-prettify">Callable</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br>R invoke_and_log</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">callable_log</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">R</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">P</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">...)&gt;&amp;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> log</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Calla=
ble</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;&a=
mp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> callab=
le</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> P</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">...</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> args</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: #660;" class=3D"=
styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br>=C2=A0 log</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">log_arguments</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
args</span><span style=3D"color: #660;" class=3D"styled-by-prettify">...);<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=C2=
=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">return=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> log</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">log_result</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 std</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">invoke</span><span style=3D"col=
or: #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"styl=
ed-by-prettify">forward</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">&lt;</span><span style=3D"color: #606;" class=3D"styled-by-pre=
ttify">Callable</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">&gt;(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
callable</span><span style=3D"color: #660;" class=3D"styled-by-prettify">),=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0=
 =C2=A0 =C2=A0 std</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
forward</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">P</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;(</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">args</span><span 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"color=
: #660;" class=3D"styled-by-prettify">}</span></div></code></div><br>By imp=
lementing it this way, you have removed the need for being able to have a n=
amed `void` value. All you need in this case are two things:<br><br>1) The =
ability to return the result of a function call, even if that result is `vo=
id`. I&#39;m pretty sure we already have this.<br><br>2) The ability to pas=
s the result of a function to another function, even if that result is `voi=
d`. In the `void` case, the argument should effectively disappear.<br><br>O=
h, and `log.log_result` will need to have an overload that takes no paramet=
ers.<br><br>By examining the problem domain like this, I think you can find=
 ways to avoid some of the more pernicious issues of `void` regularity. I&#=
39;d guess you can avoid having named values of `void` type. Which also mea=
ns you can avoid questions of getting references to `void`, passing them ar=
ound as arguments, copy/move, and so forth.<br><br>Oh sure, `void` will sti=
ll be quite irregular. But I think, with a few relaxed rules, template prog=
rammers will be able to avoid writing quite so many specializations for `vo=
id`.<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_715_1929226672.1444147581739--
------=_Part_714_2074713640.1444147581738--

.

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

On Tue, Oct 6, 2015 at 7:14 AM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2015-10-05 18:53, Matt Calabrese wrote:
> > Further, even if we had a language-level solution for returning N
> > different values, you'd still want to be able to pass these entities
> > around as a single object *without* unpacking them as separate
> > arguments, otherwise examples like my second logging example (the one
> > with the verbosity option) break down.
>
> True, and that's similarly why I think that something like:
>
>   void foo();
>   auto x = foo();
>
> ...should be supported in any case. But *not* by making void a regular
> type. There should be just as much difference between assigning to a
> single variable from a 0-value function vs. a 1-value function as from
> an N-value function vs. a 1-value function (for N > 1).
>

Why do you think these restrictions are somehow necessary or a good idea?
All you are talking about is a subset of functionality and I've shown with
examples why the additional functionality is useful in real world code (I'm
surprised this even required being that explicit, since the usefulness of
Regular types is well understood already). If you personally decided that
you didn't like this functionality due to religious reasons, just don't use
those functions.

This is getting way off topic and I'd really like to not keep going down
this:

Even with your hypothetical return value proposal, what are you suggesting
the type of decltype(bar()) would be in general, assuming nothing about
whether bar() returns 0, 1, or N return values? Are you suggesting that
decltype wouldn't work here? Can we no longer do that in generic code? If
we can do that, would it yield a tuple? If a tuple, why would you not want
this tuple to be Regular (assuming the components are Regular)?
Library-level tuples certainly are. This is true even if the tuple contains
no components. Would your facility be Regular except for when there happen
to be no components? If decltype works but doesn't yield a tuple, what does
it return there? A variadic list of types? Are people expected to wrap that
in some kind of type-list/tuple to forward it along (making the target
variadic isn't always an option, especially when you either don't have
control of the template or when your template already takes multiple types,
where each type could be a return type)? If I have code that takes a
function object and runs it on some other thread, returning a future, are
you suggesting that the promise is something other than
std::promise<decltype(bar())> or would that just work without making
promise variadic or something? What about more complicated templates where
you'd expect to instantiate it with multiple return types from different
functions? What overall functionality are you getting out of this over
library-level tuples, other than the possibility of more opportunities for
copy/move elision and perhaps simpler syntax? Functions in mathematics
certainly don't require such direct mappings to multiple results directly
in the notion of a function and effectively do what we already do -- we
return a single object that is a tuple when we need 0-N separate results.
I'd further argue that this is not a weakness in mathematics nor in C++,
since all we are doing is saying that an ordered list of results is itself
a first-class type, and can be dealt with in the same ways that your can
deal with other types. I agree that language-level multiple return values
and language level tuples would be cool (though I'm not entirely convinced
they are necessary given that we have library-level tuples), but
regardless, if we had language level support, in practice they would either
directly be some kind of tuple type or they would be easily packed into
tuples in order to be useful in generic code. In either case, it would be
beneficial for the packed, tuple-like object to be Regular, even when that
type just so happens to contain no components, just as is already the case
with std::tuple.

On Tue, Oct 6, 2015 at 7:14 AM, Matthew Woehlke <mwoehlke.floss@gmail.com>
 wrote:

> For what it's worth, I was strongly in favor of being able to treat
> MRV's as a single object. There was also, however, some strong opposition.
>

Strongly opposed by ... this group or at a meeting? Is there even a
proposal for this? Skimming through the recent mailings, at least, I see no
multiple return value proposal, unless I missed it.

On Tue, Oct 6, 2015 at 7:14 AM, Matthew Woehlke <mwoehlke.floss@gmail.com>
 wrote:

> > Even in this case, I'm not certain that the implication is that
> > "void" would or should be equivalent to the "tuple with no elements"
> > type.
>
> I would find it very strange for it to mean otherwise, when this is what
> it has meant historically.
>

Has it? There is no notion of some generalized 0-N result-like datatype in
C+++, with the closest being an tuple, which is notably Regular, and void
is certainly not an alias of tuple<> and this does not at all hurt generic
code. As I described earlier, if you had some kind of 0-N result syntax,
you also wouldn't expect for that syntax to end up to "void", would you? As
in maybe the syntax for multiple returns is something like {<int, float>},
and in generic code you could hypothetically form it from a variadic
expansion, etc. In this purely hypothetical example, {<>} is an empty
tuple. Why would "void" necessarily be an alias of this type? What do you
gain from that? Even if it were an alias of that, as described, why would
you expect this tuple with no elements to not be Regular.

Anyway, this is getting way off topic. If we want to talk further about
MRV, let's keep it to the other thread. I see little here that deals with
potential issues of the proposal other than philosophical issues with how
people choose to think of void.

On Tue, Oct 6, 2015 at 7:14 AM, Matthew Woehlke <mwoehlke.floss@gmail.com>
 wrote:

> Incidentally, I'm sure we would want some way to force a 1-value result
> to be "packed" the same as an N-value result. We can't always pack it
> for the sake of compatibility, but generic code would need a way to
> ensure consistency.


These problems exist only if we make them exist. We don't have this problem
right now and what you are suggesting doesn't actually solve additional
problems. N results can and is represented perfectly fine as a single
result with N components. Again, MRV is a sound idea, but really it's no
different in functionality from language-level tuples, and these problems
do not exist in generic code that deals with tuples (nor would they with
well designed MRV). Please though, let's stay more on the topic of
*this* proposal
rather than a hypothetical and separate language feature.

--

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

--001a11c29966b10c13052173c433
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 T=
ue, Oct 6, 2015 at 7:14 AM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex"><span class=3D"">On 2015-10-=
05 18:53, Matt Calabrese wrote:<br>
&gt; Further, even if we had a language-level solution for returning N<br>
&gt; different values, you&#39;d still want to be able to pass these entiti=
es<br>
</span>&gt; around as a single object *without* unpacking them as separate<=
br>
<span class=3D"">&gt; arguments, otherwise examples like my second logging =
example (the one<br>
&gt; with the verbosity option) break down.<br>
<br>
</span>True, and that&#39;s similarly why I think that something like:<br>
<br>
=C2=A0 void foo();<br>
=C2=A0 auto x =3D foo();<br>
<br>
....should be supported in any case. But *not* by making void a regular<br>
type. There should be just as much difference between assigning to a<br>
single variable from a 0-value function vs. a 1-value function as from<br>
an N-value function vs. a 1-value function (for N &gt; 1).<br></blockquote>=
<div><br></div><div>Why do you think these restrictions are somehow necessa=
ry or a good idea? All you are talking about is a subset of functionality a=
nd I&#39;ve shown with examples why the additional functionality is useful =
in real world code (I&#39;m surprised this even required being that explici=
t, since the usefulness of Regular types is well understood already). If yo=
u personally decided that you didn&#39;t like this functionality due to rel=
igious reasons, just don&#39;t use those functions.</div><div><br></div><di=
v>This is getting way off topic and I&#39;d really like to not keep going d=
own this:</div><div><br></div><div>Even with your hypothetical return value=
 proposal, what are you suggesting the type of decltype(bar()) would be in =
general, assuming nothing about whether bar() returns 0, 1, or N return val=
ues? Are you suggesting that decltype wouldn&#39;t work here? Can we no lon=
ger do that in generic code? If we can do that, would it yield a tuple? If =
a tuple, why would you not want this tuple to be Regular (assuming the comp=
onents are Regular)? Library-level tuples certainly are. This is true even =
if the tuple contains no components. Would your facility be Regular except =
for when there happen to be no components? If decltype works but doesn&#39;=
t yield a tuple, what does it return there? A variadic list of types? Are p=
eople expected to wrap that in some kind of type-list/tuple to forward it a=
long (making the target variadic isn&#39;t always an option, especially whe=
n you either don&#39;t have control of the template or when your template a=
lready takes multiple types, where each type could be a return type)? If I =
have code that takes a function object and runs it on some other thread, re=
turning a future, are you suggesting that the promise is something other th=
an std::promise&lt;decltype(bar())&gt; or would that just work without maki=
ng promise variadic or something? What about more complicated templates whe=
re you&#39;d expect to instantiate it with multiple return types from diffe=
rent functions? What overall functionality are you getting out of this over=
 library-level tuples, other than the possibility of more opportunities for=
 copy/move elision and perhaps simpler syntax? Functions in mathematics cer=
tainly don&#39;t require such direct mappings to multiple results directly =
in the notion of a function and effectively do what we already do -- we ret=
urn a single object that is a tuple when we need 0-N separate results. I&#3=
9;d further argue that this is not a weakness in mathematics nor in C++, si=
nce all we are doing is saying that an ordered list of results is itself a =
first-class type, and can be dealt with in the same ways that your can deal=
 with other types. I agree that language-level multiple return values and l=
anguage level tuples would be cool (though I&#39;m not entirely convinced t=
hey are necessary given that we have library-level tuples), but regardless,=
 if we had language level support, in practice they would either directly b=
e some kind of tuple type or they would be easily packed into tuples in ord=
er to be useful in generic code. In either case, it would be beneficial for=
 the packed, tuple-like object to be Regular, even when that type just so h=
appens to contain no components, just as is already the case with std::tupl=
e.</div><div>=C2=A0</div><div>On Tue, Oct 6, 2015 at 7:14 AM, Matthew Woehl=
ke=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:mwoehlke.floss@gmail.com" t=
arget=3D"_blank">mwoehlke.floss@gmail.com</a>&gt;</span>=C2=A0wrote:</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex">
For what it&#39;s worth, I was strongly in favor of being able to treat<br>
MRV&#39;s as a single object. There was also, however, some strong oppositi=
on.<br></blockquote><div><br></div><div>Strongly opposed by ... this group =
or at a meeting? Is there even a proposal for this? Skimming through the re=
cent mailings, at least, I see no multiple return value proposal, unless I =
missed it.</div><div>=C2=A0</div><div>On Tue, Oct 6, 2015 at 7:14 AM, Matth=
ew Woehlke=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:mwoehlke.floss@gmai=
l.com" target=3D"_blank">mwoehlke.floss@gmail.com</a>&gt;</span>=C2=A0wrote=
:</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:=
solid;padding-left:1ex"><span class=3D"">
&gt; Even in this case, I&#39;m not certain that the implication is that<br=
>
&gt; &quot;void&quot; would or should be equivalent to the &quot;tuple with=
 no elements&quot;<br>
&gt; type.<br>
<br>
</span>I would find it very strange for it to mean otherwise, when this is =
what<br>
it has meant historically.<br></blockquote><div><br></div><div>Has it? Ther=
e is no notion of some generalized 0-N result-like datatype in C+++, with t=
he closest being an tuple, which is notably Regular, and void is certainly =
not an alias of tuple&lt;&gt; and this does not at all hurt generic code. A=
s I described earlier, if you had some kind of 0-N result syntax, you also =
wouldn&#39;t expect for that syntax to end up to &quot;void&quot;, would yo=
u? As in maybe the syntax for multiple returns is something like {&lt;int, =
float&gt;}, and in generic code you could hypothetically form it from a var=
iadic expansion, etc. In this purely hypothetical example, {&lt;&gt;} is an=
 empty tuple. Why would &quot;void&quot; necessarily be an alias of this ty=
pe? What do you gain from that? Even if it were an alias of that, as descri=
bed, why would you expect this tuple with no elements to not be Regular.</d=
iv><div><br></div><div>Anyway, this is getting way off topic. If we want to=
 talk further about MRV, let&#39;s keep it to the other thread. I see littl=
e here that deals with potential issues of the proposal other than philosop=
hical issues with how people choose to think of void.</div><div><br></div><=
div>On Tue, Oct 6, 2015 at 7:14 AM, Matthew Woehlke=C2=A0<span dir=3D"ltr">=
&lt;<a href=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.=
floss@gmail.com</a>&gt;</span>=C2=A0wrote:</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-=
color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Incidentally, I&#39;m sure we would want some way to force a 1-value result=
<br>
to be &quot;packed&quot; the same as an N-value result. We can&#39;t always=
 pack it<br>
for the sake of compatibility, but generic code would need a way to<br>
ensure consistency.</blockquote><div><br></div><div>These problems exist on=
ly if we make them exist. We don&#39;t have this problem right now and what=
 you are suggesting doesn&#39;t actually solve additional problems. N resul=
ts can and is represented perfectly fine as a single result with N componen=
ts. Again, MRV is a sound idea, but really it&#39;s no different in functio=
nality from language-level tuples, and these problems do not exist in gener=
ic code that deals with tuples (nor would they with well designed MRV). Ple=
ase though, let&#39;s stay more on the topic of <i>this</i>=C2=A0proposal r=
ather than a hypothetical and separate language feature.</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 />

--001a11c29966b10c13052173c433--

.

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

On Tue, Oct 6, 2015 at 8:10 AM, Andrew Tomazos <andrewtomazos@gmail.com>
wrote:

> On Mon, Oct 5, 2015 at 8:43 PM, Matt Calabrese <calabrese@google.com>
> wrote:
>
>> Following the "Allow values of void" discussion, I've put together a
>> proposal[1] for updating void to be a Regular type.
>>
>
> I've thought this through a couple of times before.
>
> I think void should represent the absence of type, rather than be a type
> that holds one value.  It is correctly, imho, incomplete.
>

Why? What does this get you and what would you hypothetically lose by
*adding* functionality to the type. This wouldn't (realistically) break
existing uses of void, all it does is make generic code easier to write.

On Tue, Oct 6, 2015 at 8:10 AM, Andrew Tomazos <andrewtomazos@gmail.com>
 wrote:

> I understand the extra work that has to be done occasionally in generic
> programming where you have to write a separate specialization to deal with
> void (and have done this personally more than once).
>
> I do not think the time saved by this rare case, outweighs the time lost
> from either migration to a "regular" void, or the end result of the strange
> cases that come up:
>
>    void p;
>    void* q = &p;  // void* has special properties
>    void A[10];
>    std::vector<void> v;
>    void f(void); // 0 or 1 parameter
>    sizeof(void)
>    SFINAE uses of void
>    etc
>

There is nothing particularly strange about any of these. void f(void) and
SFINAE are explicitly addressed, too -- what specifically do you disagree
with about the analysis there? All of above types and sizeof are perfectly
sensible, and they are all either explicitly or implicitly addressed in the
proposal. void would just be a monostate type. If you take issue with the
resolution of something, then say specifically what the issue is.

--

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

--001a11c18226c8abda052173e4e1
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 T=
ue, Oct 6, 2015 at 8:10 AM, Andrew Tomazos <span dir=3D"ltr">&lt;<a href=3D=
"mailto:andrewtomazos@gmail.com" target=3D"_blank">andrewtomazos@gmail.com<=
/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);=
border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gm=
ail_extra"><div class=3D"gmail_quote"><span class=3D"">On Mon, Oct 5, 2015 =
at 8:43 PM, Matt Calabrese <span dir=3D"ltr">&lt;<a href=3D"mailto:calabres=
e@google.com" target=3D"_blank">calabrese@google.com</a>&gt;</span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli=
d;padding-left:1ex"><div dir=3D"ltr"><div>Following the &quot;Allow values =
of void&quot; discussion, I&#39;ve put together a proposal[1] for updating =
void to be a Regular type.</div></div></blockquote><div><br></div></span><d=
iv>I&#39;ve thought this through a couple of times before.</div><div><br></=
div><div>I think void should represent the absence of type, rather than be =
a type that holds one value.=C2=A0 It is correctly, imho, incomplete.</div>=
</div></div></div></blockquote><div><br></div><div>Why? What does this get =
you and what would you hypothetically lose by <i>adding</i>=C2=A0functional=
ity to the type. This wouldn&#39;t (realistically) break existing uses of v=
oid, all it does is make generic code easier to write.</div><div><br></div>=
<div>On Tue, Oct 6, 2015 at 8:10 AM, Andrew Tomazos=C2=A0<span dir=3D"ltr">=
&lt;<a href=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andrewtoma=
zos@gmail.com</a>&gt;</span>=C2=A0wrote:</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-co=
lor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"=
ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>I understan=
d the extra work that has to be done occasionally in generic programming wh=
ere you have to write a separate specialization to deal with void (and have=
 done this personally more than once).</div><div><br></div><div>I do not th=
ink the time saved by this rare case, outweighs the time lost from either m=
igration to a &quot;regular&quot; void, or the end result of the strange ca=
ses that come up:</div><div><br></div><div>=C2=A0 =C2=A0void p;</div><div>=
=C2=A0 =C2=A0void* q =3D &amp;p; =C2=A0// void* has special properties</div=
><div>=C2=A0 =C2=A0void A[10];</div><div>=C2=A0 =C2=A0std::vector&lt;void&g=
t; v;</div><div>=C2=A0 =C2=A0void f(void); // 0 or 1 parameter</div><div>=
=C2=A0 =C2=A0sizeof(void)</div><div>=C2=A0 =C2=A0SFINAE uses of void</div><=
div>=C2=A0 =C2=A0etc</div></div></div></div></blockquote><div><br></div><di=
v>There is nothing particularly strange about any of these. void f(void) an=
d SFINAE are explicitly addressed, too -- what specifically do you disagree=
 with about the analysis there? All of above types and sizeof are perfectly=
 sensible, and they are all either explicitly or implicitly addressed in th=
e proposal. void would just be a monostate type. If you take issue with the=
 resolution of something, then say specifically what the issue is.</div></d=
iv></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 />

--001a11c18226c8abda052173e4e1--

.

On 2015-10-06 14:26, Matt Calabrese wrote:
> If you personally decided that you didn't like this functionality due
> to religious reasons, just don't use those functions.

It doesn't work that way. My concern is that if your proposal is
accepted, we lose the ability to express certain concepts that we can
currently express (i.e. void as not-a-type), and where, if (hopefully
when) we later want to add "real MRV support", we've painted ourselves
into a corner where we've lost the ability to use 'void' for 0-tuples as
it seems we would want to so do. The problem isn't that it will break my
legacy code, it's that it moves the language in a questionable direction
from which it is difficult to backtrack.

> This is getting way off topic and I'd really like to not keep going down
> this:

I don't see it as off topic at all. I see it as two possible directions
that the language could move in which are mostly mutually exclusive.

I will, however, refrain from discussing the other questions you asked,
which are indeed drifting quite far off topic. (I will say, however,
briefly, that one of the major arguments for language-level tuples /
MRV's is to improve generic programming abilities in the face of N-tuple
returns as well as unpacking the same as function arguments. The most
important argument however is RVO.)

> On Tue, Oct 6, 2015 at 7:14 AM, Matthew Woehlke wrote:
>> For what it's worth, I was strongly in favor of being able to treat
>> MRV's as a single object. There was also, however, some strong opposition.
>
> Strongly opposed by ... this group or at a meeting? Is there even a
> proposal for this?

This group. I'm not aware that there has been a proposal. Personally,
I'm less interested in MRV's as first class citizens than general
unpacking. (Part of the aforementioned strong opposition was to even
having such a concept as general unpacking, insisting instead that it
must be done with first class MRV's and MRV helper functions to do
unpacking. I continue to maintain that the problems are orthogonal and
can both be addressed without being detrimental to either problem domain.)

The level of contention on the list seems to have killed anything
getting further.

> On Tue, Oct 6, 2015 at 7:14 AM, Matthew Woehlke wrote:
>> I would find it very strange for [a void function to mean something
>> other than returning a 0-tuple, which] is what it has meant
>> historically.
>
> Has it?

Yes. See in particular the lack-of-return equivalence that mentions the
lack of a value, the general way in which the result of a void function
disappears and/or cannot be used, and the machine instructions emitted
in a void function. A non-void function has a return slot that is filled
with the function result. A void function has no return slot and nothing
is filled on return. If this doesn't describe the difference between a
1-tuple return and a 0-tuple return, I don't know what does.

> As I described earlier, if you had some kind of 0-N result syntax,
> you also wouldn't expect for that syntax to end up to "void", would you?

That's *exactly* what I *would* expect. 1-tuple returns should be
interchangeable with "traditional non-void returns" (absent syntax to
force interpretation as a tuple). Likewise, 0-tuple returns should be
interchangeable with "traditional void returns".

Otherwise, we might as well forget all about compatibility with legacy
code and start over from scratch.

The reason this is relevant is because the direction of your proposal is
opposed to this.

--
Matthew

--

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

.

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

On Tue, Oct 6, 2015 at 9:06 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> I find this paper to be an interesting examination of the problem. It
> attempts to make `void` as regular as one could reasonably expect such a
> type to be.
>
> However, the question is this: do we want `void` to be regular, or do we
> want to avoid having to specialize templates for it in so many cases?
>
> If the goal is to make `void` regular, then P0146 obviously fails. There
> are too many occurrences of `void` being irregular for users to be able to
> *generally* rely on type regularity.
>

Why do you think void is not Regular in this proposal? To be clear,
"Regular" is with respect to generic programming (there is a paper linked
in the references that describes Regular types, but they are also described
in Stepanov's books, formally in the old C++0x proposal, and I'm sure the
current Concepts TS will have such a concept if it doesn't specify one
already). In brief, a Regular type just has proper copy/move semantics is
comparable, and move is noexcept. This proposal makes void Regular, and it
is simply a monostate type.

On Tue, Oct 6, 2015 at 9:06 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> I think that making `void` regular is simply the wrong goal. I really
> think the goal should be to minimize the number of times you need to
> specialize templates.
>

This is precisely how you accomplish that goal in a way that doesn't leave
void as some kind of special type that needs explicit consideration in
generic code. Treating void as special is exactly the problem. It doesn't
have to be anything special. It can just be a Regular type and you're not
losing anything by that. Being special in the sense of not supporting
fundamental operations is what forces users to write code in odd ways and
to special case.

On Tue, Oct 6, 2015 at 9:06 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> However, this particular implementation of return value logging introduces
> an unnecessary construct: a named object of the return type. You could
> instead implement it like this:
>
> // Invoke a callable, logging its arguments and return value.
> template<class R, class... P, class Callable>
> R invoke_and_log(callable_log<R(P...)>& log, Callable&& callable, P...
> args) {
>   log.log_arguments(args...);
>
>   return log.log_result(
>     std::invoke(std::forward<Callable>(callable),
>       std::forward<P>(args)...));
> }
>
>
No, you cannot implement it like that in the current language because you
can't pass a void expression as an argument. That would also require a
language change. Further, why should the user have to write it in this very
specific way just to account for void? It is logically equivalent for all
other types, why should it break for void (it shouldn't)? You are only
making things more difficult and you are quite literally gaining nothing
with this restriction over simply having void be a Regular type. A Regular
type provides a superset of this functionality and works like any object
type in C++, because that is exactly what it would be.

On Tue, Oct 6, 2015 at 9:06 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> 2) The ability to pass the result of a function to another function, even
> if that result is `void`. In the `void` case, the argument should
> effectively disappear.
>

I already address this explicitly in the proposal and why it doesn't work.
Please read the proposal.

On Tue, Oct 6, 2015 at 9:06 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> By examining the problem domain like this, I think you can find ways to
> avoid some of the more pernicious issues of `void` regularity. I'd guess
> you can avoid having named values of `void` type. Which also means you can
> avoid questions of getting references to `void`, passing them around as
> arguments, copy/move, and so forth.
>

You are still forcing writers of generic code to have arbitrary
considerations if they want to work with void. This also doesn't avoid
questions like getting references to void, or forming arrays, or anything
at all. These still frequently come up in generic code.

--

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

--001a1142e648c7b2c50521746048
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 T=
ue, Oct 6, 2015 at 9:06 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</sp=
an> 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);border-left=
-style:solid;padding-left:1ex"><div dir=3D"ltr">I find this paper to be an =
interesting examination of the problem. It attempts to make `void` as regul=
ar as one could reasonably expect such a type to be.<br><br>However, the qu=
estion is this: do we want `void` to be regular, or do we want to avoid hav=
ing to specialize templates for it in so many cases?<br><br>If the goal is =
to make `void` regular, then P0146 obviously fails. There are too many occu=
rrences of `void` being irregular for users to be able to <i>generally</i> =
rely on type regularity.<br></div></blockquote><div><br></div><div>Why do y=
ou think void is not Regular in this proposal? To be clear, &quot;Regular&q=
uot; is with respect to generic programming (there is a paper linked in the=
 references that describes Regular types, but they are also described in St=
epanov&#39;s books, formally in the old C++0x proposal, and I&#39;m sure th=
e current Concepts TS will have such a concept if it doesn&#39;t specify on=
e already). In brief, a Regular type just has proper copy/move semantics is=
 comparable, and move is noexcept. This proposal makes void Regular, and it=
 is simply a monostate type.</div><div>=C2=A0</div><div>On Tue, Oct 6, 2015=
 at 9:06 AM, Nicol Bolas=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:jmcke=
sson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span>=C2=A0w=
rote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-st=
yle:solid;padding-left:1ex"><div dir=3D"ltr">I think that making `void` reg=
ular is simply the wrong goal. I really think the goal should be to minimiz=
e the number of times you need to specialize templates.<br></div></blockquo=
te><div><br></div><div>This is precisely how you accomplish that goal in a =
way that doesn&#39;t leave void as some kind of special type that needs exp=
licit consideration in generic code. Treating void as special is exactly th=
e problem. It doesn&#39;t have to be anything special. It can just be a Reg=
ular type and you&#39;re not losing anything by that. Being special in the =
sense of not supporting fundamental operations is what forces users to writ=
e code in odd ways and to special case.</div><div>=C2=A0</div><div>On Tue, =
Oct 6, 2015 at 9:06 AM, Nicol Bolas=C2=A0<span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</s=
pan>=C2=A0wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bor=
der-left-style:solid;padding-left:1ex"><div dir=3D"ltr">However, this parti=
cular implementation of return value logging introduces an unnecessary cons=
truct: a named object of the return type. You could instead implement it li=
ke this:<br><br><div style=3D"border:1px solid rgb(187,187,187);word-wrap:b=
reak-word;background-color:rgb(250,250,250)"><code><div><span style=3D"colo=
r:rgb(136,0,0)">// Invoke a callable, logging its arguments and return valu=
e.</span><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:r=
gb(0,0,136)">template</span><span style=3D"color:rgb(102,102,0)">&lt;</span=
><span style=3D"color:rgb(0,0,136)">class</span><span style=3D"color:rgb(0,=
0,0)"> R</span><span style=3D"color:rgb(102,102,0)">,</span><span style=3D"=
color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">class</span><s=
pan style=3D"color:rgb(102,102,0)">...</span><span style=3D"color:rgb(0,0,0=
)"> P</span><span style=3D"color:rgb(102,102,0)">,</span><span style=3D"col=
or:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">class</span><span=
 style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,0,102)">Ca=
llable</span><span style=3D"color:rgb(102,102,0)">&gt;</span><span style=3D=
"color:rgb(0,0,0)"><br>R invoke_and_log</span><span style=3D"color:rgb(102,=
102,0)">(</span><span style=3D"color:rgb(0,0,0)">callable_log</span><span s=
tyle=3D"color:rgb(102,102,0)">&lt;</span><span style=3D"color:rgb(0,0,0)">R=
</span><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rg=
b(0,0,0)">P</span><span style=3D"color:rgb(102,102,0)">...)&gt;&amp;</span>=
<span style=3D"color:rgb(0,0,0)"> log</span><span style=3D"color:rgb(102,10=
2,0)">,</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color=
:rgb(102,0,102)">Callable</span><span style=3D"color:rgb(102,102,0)">&amp;&=
amp;</span><span style=3D"color:rgb(0,0,0)"> callable</span><span style=3D"=
color:rgb(102,102,0)">,</span><span style=3D"color:rgb(0,0,0)"> P</span><sp=
an style=3D"color:rgb(102,102,0)">...</span><span style=3D"color:rgb(0,0,0)=
"> args</span><span style=3D"color:rgb(102,102,0)">)</span><span style=3D"c=
olor:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">{</span><span=
 style=3D"color:rgb(0,0,0)"><br>=C2=A0 log</span><span style=3D"color:rgb(1=
02,102,0)">.</span><span style=3D"color:rgb(0,0,0)">log_arguments</span><sp=
an style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,0)">=
args</span><span style=3D"color:rgb(102,102,0)">...);</span><span style=3D"=
color:rgb(0,0,0)"><br><br>=C2=A0 </span><span style=3D"color:rgb(0,0,136)">=
return</span><span style=3D"color:rgb(0,0,0)"> log</span><span style=3D"col=
or:rgb(102,102,0)">.</span><span style=3D"color:rgb(0,0,0)">log_result</spa=
n><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0=
,0)"><br>=C2=A0 =C2=A0 std</span><span style=3D"color:rgb(102,102,0)">::</s=
pan><span style=3D"color:rgb(0,0,0)">invoke</span><span style=3D"color:rgb(=
102,102,0)">(</span><span style=3D"color:rgb(0,0,0)">std</span><span style=
=3D"color:rgb(102,102,0)">::</span><span style=3D"color:rgb(0,0,0)">forward=
</span><span style=3D"color:rgb(102,102,0)">&lt;</span><span style=3D"color=
:rgb(102,0,102)">Callable</span><span style=3D"color:rgb(102,102,0)">&gt;(<=
/span><span style=3D"color:rgb(0,0,0)">callable</span><span style=3D"color:=
rgb(102,102,0)">),</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0=
 =C2=A0 std</span><span style=3D"color:rgb(102,102,0)">::</span><span style=
=3D"color:rgb(0,0,0)">forward</span><span style=3D"color:rgb(102,102,0)">&l=
t;</span><span style=3D"color:rgb(0,0,0)">P</span><span style=3D"color:rgb(=
102,102,0)">&gt;(</span><span style=3D"color:rgb(0,0,0)">args</span><span s=
tyle=3D"color:rgb(102,102,0)">)...));</span><span style=3D"color:rgb(0,0,0)=
"><br></span><span style=3D"color:rgb(102,102,0)">}</span></div></code></di=
v><br></div></blockquote><div><br></div><div>No, you cannot implement it li=
ke that in the current language because you can&#39;t pass a void expressio=
n as an argument. That would also require a language change. Further, why s=
hould the user have to write it in this very specific way just to account f=
or void? It is logically equivalent for all other types, why should it brea=
k for void (it shouldn&#39;t)? You are only making things more difficult an=
d you are quite literally gaining nothing with this restriction over simply=
 having void be a Regular type. A Regular type provides a superset of this =
functionality and works like any object type in C++, because that is exactl=
y what it would be.</div><div>=C2=A0</div><div>On Tue, Oct 6, 2015 at 9:06 =
AM, Nicol Bolas=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:jmckesson@gmai=
l.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span>=C2=A0wrote:</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid=
;padding-left:1ex"><div dir=3D"ltr">2) The ability to pass the result of a =
function to another function, even if that result is `void`. In the `void` =
case, the argument should effectively disappear.<br></div></blockquote><div=
><br></div><div>I already address this explicitly in the proposal and why i=
t doesn&#39;t work. Please read the proposal.</div><div><br></div><div>On T=
ue, Oct 6, 2015 at 9:06 AM, Nicol Bolas=C2=A0<span dir=3D"ltr">&lt;<a href=
=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&g=
t;</span>=C2=A0wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204=
,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr">By examini=
ng the problem domain like this, I think you can find ways to avoid some of=
 the more pernicious issues of `void` regularity. I&#39;d guess you can avo=
id having named values of `void` type. Which also means you can avoid quest=
ions of getting references to `void`, passing them around as arguments, cop=
y/move, and so forth.<br></div></blockquote><div><br></div><div>You are sti=
ll forcing writers of generic code to have arbitrary considerations if they=
 want to work with void. This also doesn&#39;t avoid questions like getting=
 references to void, or forming arrays, or anything at all. These still fre=
quently come up in generic code.</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 />

--001a1142e648c7b2c50521746048--

.

Am 06.10.2015 um 20:53 schrieb Matthew Woehlke:
>> On Tue, Oct 6, 2015 at 7:14 AM, Matthew Woehlke wrote:
>>> I would find it very strange for [a void function to mean something
>>> other than returning a 0-tuple, which] is what it has meant
>>> historically.
>> Has it?
> Yes. See in particular the lack-of-return equivalence that mentions the
> lack of a value, the general way in which the result of a void function
> disappears and/or cannot be used, and the machine instructions emitted
> in a void function. A non-void function has a return slot that is filled
> with the function result. A void function has no return slot and nothing
> is filled on return. If this doesn't describe the difference between a
> 1-tuple return and a 0-tuple return, I don't know what does.
http://melpon.org/wandbox/permlink/llXEZOp9bescGXMy

Please point out the diff in machine instructions between make_X() and
make_void(), especially where make_X() fills the "return slot" with an X
instance.

"But X is trivial, the return register is simply not initialized, it's
still there in EAX".

http://melpon.org/wandbox/permlink/tQuh4TUUbzHX3V1A

Please point to the instructions where the result of make_X() is used as
argument to call consume_X() (compared to how the result of make_Y() is
used as argument to call consume_Y()).

And this is just with -O0. With -O1 "there is no X".

You see the compiler already is pretty smart about this, and those are
used-defined types. True, there is still stack space allocated for the
argument, which is not the case in a nullary function, but that is
simply because user defined types require storage. void is builtin, and
even if we make it regular the compiler still has more opportunities to
remove it than it has with user-defined types. This should also prove to
you that a function returning "old-school void" is ABI compatible to a
function returning "regular void".

Please do your research before making claims about generated machine
instructions.

--

---
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 2015-10-06 16:04, Miro Knejp wrote:
> Please do your research before making claims about generated machine
> instructions.

An "interesting" (non-monostate=C2=B9) return value is necessarily returned
somehow (excluding fell-off-the-end bugs). A void return value doesn't
get storage, in a register or otherwise.

Please don't accuse me of incompetence over a claim that is correct
aside from very exceptional cases.

(=C2=B9 I'm also curious how many times you actually see functions returnin=
g
monostates in the wild... For that matter, if a monostate already
behaves exactly like you want void to behave, why do we need to change
anything? Just teach people to use std::monostate instead of void, and
problem solved.)

--=20
Matthew

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

.

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

On Tue, Oct 6, 2015 at 11:53 AM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2015-10-06 14:26, Matt Calabrese wrote:
> > If you personally decided that you didn't like this functionality due
> > to religious reasons, just don't use those functions.
>
> It doesn't work that way. My concern is that if your proposal is
> accepted, we lose the ability to express certain concepts that we can
> currently express


Post actual code examples of what functionality you claim you are losing.

 On Tue, Oct 6, 2015 at 11:53 AM, Matthew Woehlke <mwoehlke.floss@gmail.com>
 wrote:

> (i.e. void as not-a-type), and where, if (hopefully
> when) we later want to add "real MRV support", we've painted ourselves
> into a corner where we've lost the ability to use 'void' for 0-tuples as
> it seems we would want to so do.


Again, as I've already explained, you 1) wouldn't lose the ability to treat
void as equivalent to a 0-tuple (though I additionally do refute your
assertion that there *necessarily* should be equivalence, even though it
would be okay to have such equivalence) and 2) Just like with existing
tuple types, such as std::tuple, a tuple with no components, such as
tuple<> *is Regular*. Why would your language-level tuple type be any
different in that particular respect. tuple<> being Regular is important
right now to generic code just as it would be if it were a language-level
facility. Are you claiming that std::tuple<> is incorrect here? Why? When
you are dealing with generic code that deals with N different values in the
form of a tuple (or MRV), you shouldn't expect your code to require
additional consideration simply to handle the 0 case in the event that you
encounter it.

 On Tue, Oct 6, 2015 at 11:53 AM, Matthew Woehlke <mwoehlke.floss@gmail.com>
 wrote:

> The problem isn't that it will break my
> legacy code, it's that it moves the language in a questionable direction
> from which it is difficult to backtrack.
>

Again, how? As I pointed out, you could still get equivalence of void with
your empty language-level tuple type with or without this proposal, and in
practice, your language-level tuple would likely be Regular, just like
std::tuple<> and just as I propose void to be. There is no incompatibility
here at all.

 On Tue, Oct 6, 2015 at 11:53 AM, Matthew Woehlke <mwoehlke.floss@gmail.com>
 wrote:

> I will, however, refrain from discussing the other questions you asked,
> which are indeed drifting quite far off topic. (I will say, however,
> briefly, that one of the major arguments for language-level tuples /
> MRV's is to improve generic programming abilities in the face of N-tuple
> returns as well as unpacking the same as function arguments. The most
> important argument however is RVO.)
>

Yes, I agree that that is the most important argument. I am not against
language-level tuples or direct support for MRV, but understand that those
ideas are not at all mutually exclusive with this proposal as you seem to
be thinking that they are.

 On Tue, Oct 6, 2015 at 11:53 AM, Matthew Woehlke <mwoehlke.floss@gmail.com>
 wrote:

> The level of contention on the list seems to have killed anything
> getting further.
>

I don't know about that. Write up a proposal and submit it.

 On Tue, Oct 6, 2015 at 11:53 AM, Matthew Woehlke <mwoehlke.floss@gmail.com>
 wrote:
>
> > On Tue, Oct 6, 2015 at 7:14 AM, Matthew Woehlke wrote:
> >> I would find it very strange for [a void function to mean something
> >> other than returning a 0-tuple, which] is what it has meant
> >> historically.
> >
> > Has it?
>
> Yes. See in particular the lack-of-return equivalence that mentions the
> lack of a value, the general way in which the result of a void function
> disappears and/or cannot be used, and the machine instructions emitted
> in a void function.


We are just adding functionality, not that dissimilar from adding something
like "emplace" to std::vector. Sure you can break hypothetical SFINAE
constructs in that sense, but that is minute and such hypotheticals were
never recommended ways of doing SFINAE. What currently *cannot* be done
doesn't really matter much in practice, just like when adding functionality
to any other data type. As well, "machine instructions emitted" don't even
necessary have to change, not that this latter point matters at all with
respect to the soundness of the idea.


 On Tue, Oct 6, 2015 at 11:53 AM, Matthew Woehlke <mwoehlke.floss@gmail.com>
 wrote:

> A non-void function has a return slot that is filled
> with the function result. A void function has no return slot and nothing
> is filled on return. If this doesn't describe the difference between a
> 1-tuple return and a 0-tuple return, I don't know what does.
>

Well then you don't. Again, a std::tuple<> (as in a tuple with no
components in existing C++ today) is still a Regular object type that you
can make an instance of, copy, compare, return from and pass to functions,
etc.. void as I describe it is completely compatible with such a notion and
similarly would be compatible with language-level tuples. Making a 0-tuple
not even instantiable, which again, is completely against existing practice
if you compare it to std::tuple<>, even if you choose to not acknowledge
the use cases, just makes sensible code more difficult to write. We
shouldn't be afraid of the 0 case. It's not different from any other N in
this situation and treating it like it is somehow special in this regard
only hinders development.

 On Tue, Oct 6, 2015 at 11:53 AM, Matthew Woehlke <mwoehlke.floss@gmail.com>
 wrote:
>
> That's *exactly* what I *would* expect. 1-tuple returns should be
> interchangeable with "traditional non-void returns" (absent syntax to
> force interpretation as a tuple). Likewise, 0-tuple returns should be
> interchangeable with "traditional void returns".
>
> Otherwise, we might as well forget all about compatibility with legacy
> code and start over from scratch.
>

It doesn't break compatibility with legacy code as you describe it. If you
think it does, then post an actual example.

 On Tue, Oct 6, 2015 at 11:53 AM, Matthew Woehlke <mwoehlke.floss@gmail.com>
 wrote:

> The reason this is relevant is because the direction of your proposal is
> opposed to this.


Again, they are not at all mutually exclusive.

--

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

--089e0115f052e8bfa7052175988b
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 T=
ue, Oct 6, 2015 at 11:53 AM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex"><span class=3D"">On 2015-10-=
06 14:26, Matt Calabrese wrote:<br>
&gt; If you personally decided that you didn&#39;t like this functionality =
due<br>
&gt; to religious reasons, just don&#39;t use those functions.<br>
<br>
</span>It doesn&#39;t work that way. My concern is that if your proposal is=
<br>
accepted, we lose the ability to express certain concepts that we can<br>
currently express</blockquote><div><br></div><div>Post actual code examples=
 of what functionality you claim you are losing.</div><div><br></div><div>=
=C2=A0On Tue, Oct 6, 2015 at 11:53 AM, Matthew Woehlke=C2=A0<span dir=3D"lt=
r">&lt;<a href=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehl=
ke.floss@gmail.com</a>&gt;</span>=C2=A0wrote:</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> (i.e. =
void as not-a-type), and where, if (hopefully<br>
when) we later want to add &quot;real MRV support&quot;, we&#39;ve painted =
ourselves<br>
into a corner where we&#39;ve lost the ability to use &#39;void&#39; for 0-=
tuples as<br>
it seems we would want to so do.</blockquote><div><br></div><div>Again, as =
I&#39;ve already explained, you 1) wouldn&#39;t lose the ability to treat v=
oid as equivalent to a 0-tuple (though I additionally do refute your assert=
ion that there <i>necessarily</i>=C2=A0should be equivalence, even though i=
t would be okay to have such equivalence) and 2) Just like with existing tu=
ple types, such as std::tuple, a tuple with no components, such as tuple&lt=
;&gt;=C2=A0<i>is Regular</i>. Why would your language-level tuple type be a=
ny different in that particular respect. tuple&lt;&gt; being Regular is imp=
ortant right now to generic code just as it would be if it were a language-=
level facility. Are you claiming that std::tuple&lt;&gt; is incorrect here?=
 Why? When you are dealing with generic code that deals with N different va=
lues in the form of a tuple (or MRV), you shouldn&#39;t expect your code to=
 require additional consideration simply to handle the 0 case in the event =
that you encounter it.</div><div><br></div><div>=C2=A0On Tue, Oct 6, 2015 a=
t 11:53 AM, Matthew Woehlke=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:mw=
oehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail.com</a>&gt;<=
/span>=C2=A0wrote:=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex"> The problem isn&#39;t that =
it will break my<br>
legacy code, it&#39;s that it moves the language in a questionable directio=
n<br>
from which it is difficult to backtrack.<br></blockquote><div><br></div><di=
v>Again, how? As I pointed out, you could still get equivalence of void wit=
h your empty language-level tuple type with or without this proposal, and i=
n practice, your language-level tuple would likely be Regular, just like st=
d::tuple&lt;&gt; and just as I propose void to be. There is no incompatibil=
ity here at all.</div><div><br></div><div>=C2=A0On Tue, Oct 6, 2015 at 11:5=
3 AM, Matthew Woehlke=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:mwoehlke=
..floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail.com</a>&gt;</span>=
=C2=A0wrote:=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b=
order-left-style:solid;padding-left:1ex">
I will, however, refrain from discussing the other questions you asked,<br>
which are indeed drifting quite far off topic. (I will say, however,<br>
briefly, that one of the major arguments for language-level tuples /<br>
MRV&#39;s is to improve generic programming abilities in the face of N-tupl=
e<br>
returns as well as unpacking the same as function arguments. The most<br>
important argument however is RVO.)<br></blockquote><div><br></div><div>Yes=
, I agree that that is the most important argument. I am not against langua=
ge-level tuples or direct support for MRV, but understand that those ideas =
are not at all mutually exclusive with this proposal as you seem to be thin=
king that they are.</div><div>=C2=A0</div><div>=C2=A0On Tue, Oct 6, 2015 at=
 11:53 AM, Matthew Woehlke=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:mwo=
ehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail.com</a>&gt;</=
span>=C2=A0wrote:=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,2=
04);border-left-style:solid;padding-left:1ex">
The level of contention on the list seems to have killed anything<br>
getting further.<br></blockquote><div><br></div><div>I don&#39;t know about=
 that. Write up a proposal and submit it.</div><div>=C2=A0</div>=C2=A0On Tu=
e, Oct 6, 2015 at 11:53 AM, Matthew Woehlke=C2=A0<span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gm=
ail.com</a>&gt;</span>=C2=A0wrote:=C2=A0<blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rg=
b(204,204,204);border-left-style:solid;padding-left:1ex">&gt; On Tue, Oct 6=
, 2015 at 7:14 AM, Matthew Woehlke wrote:<br>
&gt;&gt; I would find it very strange for [a void function to mean somethin=
g<br>
&gt;&gt; other than returning a 0-tuple, which] is what it has meant<br>
&gt;&gt; historically.<br>
&gt;<br>
&gt; Has it?<br>
<br>
Yes. See in particular the lack-of-return equivalence that mentions the<br>
lack of a value, the general way in which the result of a void function<br>
disappears and/or cannot be used, and the machine instructions emitted<br>
in a void function.</blockquote><div><br></div><div>We are just adding func=
tionality, not that dissimilar from adding something like &quot;emplace&quo=
t; to std::vector. Sure you can break hypothetical SFINAE constructs in tha=
t sense, but that is minute and such hypotheticals were never recommended w=
ays of doing SFINAE. What currently <i>cannot</i>=C2=A0be done doesn&#39;t =
really matter much in practice, just like when adding functionality to any =
other data type. As well, &quot;machine instructions emitted&quot; don&#39;=
t even necessary have to change, not that this latter point matters at all =
with respect to the soundness of the idea.</div><div><br></div><div><br></d=
iv><div>=C2=A0On Tue, Oct 6, 2015 at 11:53 AM, Matthew Woehlke=C2=A0<span d=
ir=3D"ltr">&lt;<a href=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank=
">mwoehlke.floss@gmail.com</a>&gt;</span>=C2=A0wrote:=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width=
:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-lef=
t:1ex"> A non-void function has a return slot that is filled<br>
with the function result. A void function has no return slot and nothing<br=
>
is filled on return. If this doesn&#39;t describe the difference between a<=
br>
1-tuple return and a 0-tuple return, I don&#39;t know what does.<br></block=
quote><div><br></div><div>Well then you don&#39;t. Again, a std::tuple&lt;&=
gt; (as in a tuple with no components in existing C++ today) is still a Reg=
ular object type that you can make an instance of, copy, compare, return fr=
om and pass to functions, etc.. void as I describe it is completely compati=
ble with such a notion and similarly would be compatible with language-leve=
l tuples. Making a 0-tuple not even instantiable, which again, is completel=
y against existing practice if you compare it to std::tuple&lt;&gt;, even i=
f you choose to not acknowledge the use cases, just makes sensible code mor=
e difficult to write. We shouldn&#39;t be afraid of the 0 case. It&#39;s no=
t different from any other N in this situation and treating it like it is s=
omehow special in this regard only hinders development.</div><div>=C2=A0</d=
iv>=C2=A0On Tue, Oct 6, 2015 at 11:53 AM, Matthew Woehlke=C2=A0<span dir=3D=
"ltr">&lt;<a href=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwo=
ehlke.floss@gmail.com</a>&gt;</span>=C2=A0wrote:=C2=A0<blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border=
-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">That=
&#39;s *exactly* what I *would* expect. 1-tuple returns should be<br>
interchangeable with &quot;traditional non-void returns&quot; (absent synta=
x to<br>
force interpretation as a tuple). Likewise, 0-tuple returns should be<br>
interchangeable with &quot;traditional void returns&quot;.<br>
<br>
Otherwise, we might as well forget all about compatibility with legacy<br>
code and start over from scratch.<br></blockquote><div><br></div><div>It do=
esn&#39;t break compatibility with legacy code as you describe it. If you t=
hink it does, then post an actual example.</div><div><br></div><div>=C2=A0O=
n Tue, Oct 6, 2015 at 11:53 AM, Matthew Woehlke=C2=A0<span dir=3D"ltr">&lt;=
<a href=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.flos=
s@gmail.com</a>&gt;</span>=C2=A0wrote:=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
The reason this is relevant is because the direction of your proposal is<br=
>
opposed to this.</blockquote><div>=C2=A0</div><div>Again, they are not at a=
ll mutually exclusive.=C2=A0</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 />

--089e0115f052e8bfa7052175988b--

.

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

On Tue, Oct 6, 2015 at 1:31 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:
>
> if a monostate already
> behaves exactly like you want void to behave, why do we need to change
> anything? Just teach people to use std::monostate instead of void, and
> problem solved.


This is already explained in the proposal.

--

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

--089e015366082ba702052175bc98
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 T=
ue, Oct 6, 2015 at 1:31 PM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">if a monostate alr=
eady<br>
behaves exactly like you want void to behave, why do we need to change<br>
anything? Just teach people to use std::monostate instead of void, and<br>
problem solved.</blockquote><div><br></div><div>This is already explained i=
n the proposal.</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 />

--089e015366082ba702052175bc98--

.

Am 06.10.2015 um 22:31 schrieb Matthew Woehlke:
> On 2015-10-06 16:04, Miro Knejp wrote:
>> Please do your research before making claims about generated machine
>> instructions.
> An "interesting" (non-monostate=C2=B9) return value is necessarily return=
ed
> somehow (excluding fell-off-the-end bugs). A void return value doesn't
> get storage, in a register or otherwise.
Do you know what the unit type is? This proposal and the attached=20
discussion is all about making void a unit type, therefore a *monostate*=20
as you persist on calling it, or a *regular empty trivial type*. I just=20
proved to you that at least one compiler does not waste cycles nor=20
registers on returning such types from functions and the generated=20
machine instructions do not differ from returning void in its current=20
form. It proves that making void into such a builtin regular/unit type=20
does not impact code generation and therefore is zero-overhead and ABI=20
compatible.
>
> Please don't accuse me of incompetence over a claim that is correct
> aside from very exceptional cases.
It was incorrect as proven by actual machine instructions generated by=20
an actual compiler using a non-void returning function as evidence to=20
the contrary. This "very exceptional case" is what this proposal is all=20
about.
>
> (=C2=B9 I'm also curious how many times you actually see functions return=
ing
> monostates in the wild...
That is irrelevant as the entire crux of the proposal is to make void=20
such a "monostate". Point is, an *empty trivial type* returned from a=20
function or consumed by the caller generates the same code as a void=20
returning function with this compiler.

Regardless, all of that doesn't matter in the end. Since void is a=20
builtin type the compiler can chose to eliminate it from function calls=20
and not give it any register or stack space in generated code even if it=20
is a regular type with sizeof > 0 under the as-if rule. No wasted=20
cycles, no wasted registers, no ABI incompatibility.

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

.

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

On Tue, Oct 6, 2015 at 6:20 AM, Casey Carter <cartec69@gmail.com> wrote:

>
> On Monday, October 5, 2015 at 4:52:31 PM UTC-5, Matt Calabrese wrote:
>>
>> On Mon, Oct 5, 2015 at 2:38 PM, Casey Carter <cart...@gmail.com> wrote:
>>
>>> On Monday, October 5, 2015 at 1:43:06 PM UTC-5, Matt Calabrese wrote:
>>>>
>>>>
>>>> [1]
>>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html
>>>>
>>>
>>> You're going to have to do something about the last sentence in
>>> stmt.return/2: "Flowing off the end of a function is equivalent to a return
>>> with no value; this results in undefined behavior in a value-returning
>>> function." The consequence of the proposed change is that all existing
>>> functions that return void will have undefined behavior.
>>>
>>
>> I didn't change anything that would [directly] affect the special-casing
>> of functions returning void in this respect. Is there something specific in
>> my listed changes that would make this no longer true that you can point
>> to, or is otherwise implied?
>>
>
> You've left the statement "A return statement with no operand shall be
> used only in a function whose return type is cv void, a constructor (12.1),
> or a destructor (12.4)." in stmt.return, but it's not clear what the effect
> of such a return should be. The final sentence clarifies the behavior:
> "Flowing off the end of a function is equivalent to a return with no value;
> this results in undefined behavior in a value-returning function." Since a
> function returning void is now a value-returning function, void f(bool b)
> { if (b) return; } has undefined behavior for exactly the same reasons as
> std::nullptr_t g(bool b) { if (b) return; }.
>

Ah, yeah, you're right. That's a mistake.

--

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

--001a1137bdd021286d05217709fc
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 T=
ue, Oct 6, 2015 at 6:20 AM, Casey Carter <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:cartec69@gmail.com" target=3D"_blank">cartec69@gmail.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><br>On Monday, October 5, 2015 =
at 4:52:31 PM UTC-5, Matt Calabrese wrote:<span class=3D""><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On=
 Mon, Oct 5, 2015 at 2:38 PM, Casey Carter <span dir=3D"ltr">&lt;<a rel=3D"=
nofollow">cart...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><span>On Monday, October 5, 2015 at 1:43:06 PM UT=
C-5, Matt Calabrese 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"><div><br></div>[1] <a href=3D"http://www.open-std.org/jtc1/sc22/wg=
21/docs/papers/2015/p0146r0.html" rel=3D"nofollow" target=3D"_blank">http:/=
/www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html</a></div></b=
lockquote><div><br></div></span><div>You&#39;re going to have to do somethi=
ng about the last sentence in stmt.return/2: &quot;Flowing off the end of a=
 function is equivalent to a return with no value; this results in undefine=
d behavior in a value-returning function.&quot; The consequence of the prop=
osed change is that all existing functions that return void will have undef=
ined behavior.</div></div></blockquote><div><br></div><div>I didn&#39;t cha=
nge anything that would [directly] affect the special-casing of functions r=
eturning void in this respect. Is there something specific in my listed cha=
nges that would make this no longer true that you can point to, or is other=
wise implied?=C2=A0</div></div></div></div></blockquote><div><br></div></sp=
an><div>You&#39;ve left the statement &quot;A return statement with no oper=
and shall be used only in a function whose return type is cv void, a constr=
uctor (12.1), or a destructor (12.4).&quot; in stmt.return, but it&#39;s no=
t clear what the effect of such a return should be. The final sentence clar=
ifies the behavior: &quot;Flowing off the end of a function is equivalent t=
o a return with no value; this results in undefined behavior in a value-ret=
urning function.&quot; Since a function returning void is now a value-retur=
ning function, <font face=3D"courier new, monospace">void f(bool b) { if (b=
) return; }=C2=A0</font>has undefined behavior for exactly the same reasons=
 as std::nullptr_t g(bool b) { if (b) return; }.</div></blockquote><div><br=
></div><div>Ah, yeah, you&#39;re right. That&#39;s a mistake.</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 />

--001a1137bdd021286d05217709fc--

.

On 10/06/2015 05:20 PM, 'Matt Calabrese' via ISO C++ Standard - Future
Proposals wrote:
> On Tue, Oct 6, 2015 at 6:20 AM, Casey Carter <cartec69@gmail.com
> <mailto:cartec69@gmail.com>> wrote:
>
>
>     On Monday, October 5, 2015 at 4:52:31 PM UTC-5, Matt Calabrese wrote:
>
>         On Mon, Oct 5, 2015 at 2:38 PM, Casey Carter <cart...@gmail.com>
>         wrote:
>
>             On Monday, October 5, 2015 at 1:43:06 PM UTC-5, Matt
>             Calabrese wrote:
>
>
>                 [1]
>                 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html
>
>
>             You're going to have to do something about the last sentence
>             in stmt.return/2: "Flowing off the end of a function is
>             equivalent to a return with no value; this results in
>             undefined behavior in a value-returning function." The
>             consequence of the proposed change is that all existing
>             functions that return void will have undefined behavior.
>
>
>         I didn't change anything that would [directly] affect the
>         special-casing of functions returning void in this respect. Is
>         there something specific in my listed changes that would make
>         this no longer true that you can point to, or is otherwise implied?
>
>
>     You've left the statement "A return statement with no operand shall
>     be used only in a function whose return type is cv void, a
>     constructor (12.1), or a destructor (12.4)." in stmt.return, but
>     it's not clear what the effect of such a return should be. The final
>     sentence clarifies the behavior: "Flowing off the end of a function
>     is equivalent to a return with no value; this results in undefined
>     behavior in a value-returning function." Since a function returning
>     void is now a value-returning function, void f(bool b) { if (b)
>     return; } has undefined behavior for exactly the same reasons as
>     std::nullptr_t g(bool b) { if (b) return; }.
>
>
> Ah, yeah, you're right. That's a mistake.


Why not have a different type than void to represent "no value".
Why not the bottom type:

https://en.wikipedia.org/wiki/Bottom_type

which is the categorical dual of the top or unit type.

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

.

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

On Tue, Oct 6, 2015 at 5:23 PM, Larry Evans <cppljevans@suddenlink.net>
wrote:

> On 10/06/2015 05:20 PM, 'Matt Calabrese' via ISO C++ Standard - Future
> Proposals wrote:
> > On Tue, Oct 6, 2015 at 6:20 AM, Casey Carter <cartec69@gmail.com
> > <mailto:cartec69@gmail.com>> wrote:
> >
> >
> >     On Monday, October 5, 2015 at 4:52:31 PM UTC-5, Matt Calabrese wrote:
> >
> >         On Mon, Oct 5, 2015 at 2:38 PM, Casey Carter <cart...@gmail.com>
> >         wrote:
> >
> >             On Monday, October 5, 2015 at 1:43:06 PM UTC-5, Matt
> >             Calabrese wrote:
> >
> >
> >                 [1]
> >
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html
> >
> >
> >             You're going to have to do something about the last sentence
> >             in stmt.return/2: "Flowing off the end of a function is
> >             equivalent to a return with no value; this results in
> >             undefined behavior in a value-returning function." The
> >             consequence of the proposed change is that all existing
> >             functions that return void will have undefined behavior.
> >
> >
> >         I didn't change anything that would [directly] affect the
> >         special-casing of functions returning void in this respect. Is
> >         there something specific in my listed changes that would make
> >         this no longer true that you can point to, or is otherwise
> implied?
> >
> >
> >     You've left the statement "A return statement with no operand shall
> >     be used only in a function whose return type is cv void, a
> >     constructor (12.1), or a destructor (12.4)." in stmt.return, but
> >     it's not clear what the effect of such a return should be. The final
> >     sentence clarifies the behavior: "Flowing off the end of a function
> >     is equivalent to a return with no value; this results in undefined
> >     behavior in a value-returning function." Since a function returning
> >     void is now a value-returning function, void f(bool b) { if (b)
> >     return; } has undefined behavior for exactly the same reasons as
> >     std::nullptr_t g(bool b) { if (b) return; }.
> >
> >
> > Ah, yeah, you're right. That's a mistake.
>
>
> Why not have a different type than void to represent "no value".
> Why not the bottom type:
>
> https://en.wikipedia.org/wiki/Bottom_type


That doesn't help in this case; a function with the bottom type as its
return type can never return.

which is the categorical dual of the top or unit type.


The top type is not a unit type (unless your type system is very
uninteresting); every value is a value of the top type, whereas the unit
type has only one value.

--

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

--001a11431b66309e940521791a33
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 T=
ue, Oct 6, 2015 at 5:23 PM, Larry Evans <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:cppljevans@suddenlink.net" target=3D"_blank">cppljevans@suddenlink.net=
</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)=
;border-left-style:solid;padding-left:1ex">On 10/06/2015 05:20 PM, &#39;Mat=
t Calabrese&#39; via ISO C++ Standard - Future<br>
<span class=3D"">Proposals wrote:<br>
&gt; On Tue, Oct 6, 2015 at 6:20 AM, Casey Carter &lt;<a href=3D"mailto:car=
tec69@gmail.com">cartec69@gmail.com</a><br>
</span><div><div class=3D"h5">&gt; &lt;mailto:<a href=3D"mailto:cartec69@gm=
ail.com">cartec69@gmail.com</a>&gt;&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0On Monday, October 5, 2015 at 4:52:31 PM UTC-5, Mat=
t Calabrese wrote:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Mon, Oct 5, 2015 at 2:38 PM, Casey=
 Carter &lt;<a href=3D"mailto:cart...@gmail.com">cart...@gmail.com</a>&gt;<=
br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wrote:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Monday, October 5, 2=
015 at 1:43:06 PM UTC-5, Matt<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Calabrese wrote:<br>
&gt;<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[1]<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=
=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html" r=
el=3D"noreferrer" target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/=
docs/papers/2015/p0146r0.html</a><br>
&gt;<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0You&#39;re going to hav=
e to do something about the last sentence<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in stmt.return/2: &quot=
;Flowing off the end of a function is<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0equivalent to a return =
with no value; this results in<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0undefined behavior in a=
 value-returning function.&quot; The<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0consequence of the prop=
osed change is that all existing<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0functions that return v=
oid will have undefined behavior.<br>
&gt;<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I didn&#39;t change anything that wou=
ld [directly] affect the<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0special-casing of functions returning=
 void in this respect. Is<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0there something specific in my listed=
 changes that would make<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this no longer true that you can poin=
t to, or is otherwise implied?<br>
&gt;<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0You&#39;ve left the statement &quot;A return statem=
ent with no operand shall<br>
&gt;=C2=A0 =C2=A0 =C2=A0be used only in a function whose return type is cv =
void, a<br>
&gt;=C2=A0 =C2=A0 =C2=A0constructor (12.1), or a destructor (12.4).&quot; i=
n stmt.return, but<br>
&gt;=C2=A0 =C2=A0 =C2=A0it&#39;s not clear what the effect of such a return=
 should be. The final<br>
&gt;=C2=A0 =C2=A0 =C2=A0sentence clarifies the behavior: &quot;Flowing off =
the end of a function<br>
&gt;=C2=A0 =C2=A0 =C2=A0is equivalent to a return with no value; this resul=
ts in undefined<br>
&gt;=C2=A0 =C2=A0 =C2=A0behavior in a value-returning function.&quot; Since=
 a function returning<br>
&gt;=C2=A0 =C2=A0 =C2=A0void is now a value-returning function, void f(bool=
 b) { if (b)<br>
&gt;=C2=A0 =C2=A0 =C2=A0return; } has undefined behavior for exactly the sa=
me reasons as<br>
&gt;=C2=A0 =C2=A0 =C2=A0std::nullptr_t g(bool b) { if (b) return; }.<br>
&gt;<br>
&gt;<br>
&gt; Ah, yeah, you&#39;re right. That&#39;s a mistake.<br>
<br>
<br>
</div></div>Why not have a different type than void to represent &quot;no v=
alue&quot;.<br>
Why not the bottom type:<br>
<br>
<a href=3D"https://en.wikipedia.org/wiki/Bottom_type" rel=3D"noreferrer" ta=
rget=3D"_blank">https://en.wikipedia.org/wiki/Bottom_type</a></blockquote><=
div><br></div><div>That doesn&#39;t help in this case; a function with the =
bottom type as its return type can never return.</div><div><br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding=
-left:1ex">
which is the categorical dual of the top or unit type.</blockquote><div><br=
></div><div>The top type is not a unit type (unless your type system is ver=
y uninteresting); every value is a value of the top type, whereas the unit =
type has only one value.</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 />

--001a11431b66309e940521791a33--

.

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

On 5 October 2015 at 13:43, Matt Calabrese <calabrese@google.com> wrote:

>
> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html
>

Given that *void* is all over the place in the C standard, which is the
base document for C++, it is surprising not to find a detailed section on C
Compatibility in your proposal.  Do you plan on adding one soon?
--
 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/.

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

<div dir=3D"ltr">On 5 October 2015 at 13:43, Matt Calabrese <span dir=3D"lt=
r">&lt;<a href=3D"mailto:calabrese@google.com" target=3D"_blank">calabrese@=
google.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"><div><br><=
/div>[1] <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015=
/p0146r0.html" target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/doc=
s/papers/2015/p0146r0.html</a></div></blockquote><div><br></div><div>Given =
that <u>void</u> is all over the place in the C standard, which is the base=
 document for C++, it is surprising not to find a detailed section on C Com=
patibility in your proposal.=C2=A0 Do you plan on adding one soon?</div></d=
iv>-- <br><div class=3D"gmail_signature">=C2=A0Nevin &quot;:-)&quot; Liber=
=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blan=
k">nevin@eviloverlord.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 />

--001a113d9f7af7ee2d052184dd5e--

.

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

On Wed, Oct 7, 2015 at 7:49 AM, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 5 October 2015 at 13:43, Matt Calabrese <calabrese@google.com> wrote:
>
>>
>> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html
>>
>
> Given that *void* is all over the place in the C standard, which is the
> base document for C++, it is surprising not to find a detailed section on C
> Compatibility in your proposal.  Do you plan on adding one soon?
>

Given that C does not allow function overloads by name, and has no
templates, am I wrong in thinking that the effects are essentially
non-existent?



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

--

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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Oct 7, 2015 at 7:49 AM, Nevin Liber <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.c=
om</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
>On 5 October 2015 at 13:43, Matt Calabrese <span dir=3D"ltr">&lt;<a href=
=3D"mailto:calabrese@google.com" target=3D"_blank">calabrese@google.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:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div>[1] <a href=
=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html" t=
arget=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0=
146r0.html</a></div></blockquote><div><br></div><div>Given that <u>void</u>=
 is all over the place in the C standard, which is the base document for C+=
+, it is surprising not to find a detailed section on C Compatibility in yo=
ur proposal.=C2=A0 Do you plan on adding one soon?</div></div></div></div><=
/blockquote><div><br></div><div>Given that C does not allow function overlo=
ads by name, and has no templates, am I wrong in thinking that the effects =
are essentially non-existent?=C2=A0</div><div><br></div><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><s=
pan class=3D"HOEnZb"><font color=3D"#888888">-- <br><div>=C2=A0Nevin &quot;=
:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" =
target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 <a href=3D"tel:%2884=
7%29%20691-1404" value=3D"+18476911404" target=3D"_blank">(847) 691-1404</a=
></div>
</font></span></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

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

--001a113f3cd4383353052186393e--

.

------=_Part_49_439962690.1444235973267
Content-Type: multipart/alternative;
 boundary="----=_Part_50_1393947264.1444235973268"

------=_Part_50_1393947264.1444235973268
Content-Type: text/plain; charset=UTF-8

On Tuesday, October 6, 2015 at 3:10:09 PM UTC-4, Matt Calabrese wrote:
>
> On Tue, Oct 6, 2015 at 9:06 AM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> I find this paper to be an interesting examination of the problem. It
>> attempts to make `void` as regular as one could reasonably expect such a
>> type to be.
>>
>> However, the question is this: do we want `void` to be regular, or do we
>> want to avoid having to specialize templates for it in so many cases?
>>
>> If the goal is to make `void` regular, then P0146 obviously fails. There
>> are too many occurrences of `void` being irregular for users to be able to
>> *generally* rely on type regularity.
>>
>
> Why do you think void is not Regular in this proposal? To be clear,
> "Regular" is with respect to generic programming (there is a paper linked
> in the references that describes Regular types, but they are also described
> in Stepanov's books, formally in the old C++0x proposal, and I'm sure the
> current Concepts TS will have such a concept if it doesn't specify one
> already). In brief, a Regular type just has proper copy/move semantics is
> comparable, and move is noexcept. This proposal makes void Regular, and it
> is simply a monostate type.
>

I seem to have read your proposal backwards then. I was looking for the
treatment of specific instances, so my searches all lead to the
"alternative" section, which I mistook for the actual proposal.

Sorry about that.


>
> On Tue, Oct 6, 2015 at 9:06 AM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> I think that making `void` regular is simply the wrong goal. I really
>> think the goal should be to minimize the number of times you need to
>> specialize templates.
>>
>
> This is precisely how you accomplish that goal in a way that doesn't leave
> void as some kind of special type that needs explicit consideration in
> generic code. Treating void as special is exactly the problem. It doesn't
> have to be anything special. It can just be a Regular type and you're not
> losing anything by that. Being special in the sense of not supporting
> fundamental operations is what forces users to write code in odd ways and
> to special case.
>

Wait: if the goal is to help improve template code writing, why does it
matter if `void` is a special type or not?

My issue here is that you seem to be conflating two points, using one to
hide your desire for the other. Your proposal is very clear on the
motivations. It's not that `void` ought to be a type, for some functional
programming reason or whatever.

The motivation is because, by making `void` regular, you make template
programming easier in various situations. You don't have to make complex
specializations and such just for a minor case of a function with no return
value.

However, if the goal is making template code easier to write, then whether
`void` is "some kind of special type that needs explicit consideration in
generic code" is irrelevant. What matters is how hard it is to provide that
"explicit consideration".

For example, P0128 (consexpr_if) <http://wg21.link/P0128> solves your
logging problem thusly:

// Invoke a callable, logging its arguments and return value.
template<class R, class... P, class Callable>
R invoke_and_log(callable_log<R(P...)>& log, Callable&& callable, P... args)
{
  log.log_arguments(args...);
  constexpr_if(is_same_v<void, std::result_of_t<Callable, Args...>>)
  {
    auto result = std::invoke(std::forward<Callable>(callable),
      std::forward<P>(args)...);
    log.log_result(result);
    return result;
  }
  else
    return;
}

This code looks perfectly reasonable. You could even write a metafunction
to make the conditional a bit shorter, if that bothers you.

This is a solution to the problem that motivates your proposal. You
probably won't prefer this solution. But you cannot deny that it
substantially reduces the burden on users when doing this sort of stuff. It
doesn't require adding function specializations and whatnot. It just works,
and its easy to read and reason about.

So, do you want to make `void` regular, or do you want to help improve
template code? Because the former is not required for the latter. You claim
that `void` being special is "the problem", but it's not. "The problem" is
the difficulty in writing *any* kind of conditional template code.

Solve that problem, and 80% of the reason for regularizing `void` goes away.

There is another problem with regularizing `void` that your proposal does
not deal with. Namely, that you've removed a fundamental distinction
between "functions that return a value" and "functions that don't return a
value".

As an example of where this distinction is important, consider a
specialized transformation visitor for a variant. That is, it converts one
variant into another variant. And let's say we're clever and we decree that
the typelist for the generated variant will be deduced from the return
types of the visitor (I don't know if that's possible, but it sounds
plausible).

Well, answer me this: what would it mean for the user to provide a `void`
function in such a visitor? Did the user make a mistake? Or does the user
actually mean to store the `void` value?

It would make far more sense for such a function to reject `void`
functions. Why? Because thanks to auto return type deduction, it's very
easy to compute a value and forget to return it, thus accidentally creating
a `void` function. And sure, a compiler might offer a warning, but a
compiler error is much more effective. If the user truly wanted an "empty"
state, they'd use an empty class.

With your case, my visitation function needs to expend effort to *break*
those using `void`. And without constexpr_if or concepts, that effort is
non-trivial.

In short, not every user *wants* to treat `void` as regular. Why should
regularity be the default case?

So on the one hand, your solution to the problem seems like overkill; we
can solve the problem adequately without affecting `void`. And on the other
hand, there are many cases where you don't want to treat `void` like any
other type, and if you make `void` regular, you have to expend code to do
that.

On Tue, Oct 6, 2015 at 9:06 AM, Nicol Bolas <jmck...@gmail.com <javascript:>
> > wrote:
>
>> By examining the problem domain like this, I think you can find ways to
>> avoid some of the more pernicious issues of `void` regularity. I'd guess
>> you can avoid having named values of `void` type. Which also means you can
>> avoid questions of getting references to `void`, passing them around as
>> arguments, copy/move, and so forth.
>>
>
> You are still forcing writers of generic code to have arbitrary
> considerations if they want to work with void. This also doesn't avoid
> questions like getting references to void, or forming arrays, or anything
> at all. These still frequently come up in generic code.
>

You would strengthen your motivation section if you could provide
real-world example code of cases where these operations are necessary. It
would also make it easy for a user to judge if the code is logically
consistent.

It seems to me that most instances of such occurrences are when dealing
with return values of user-provided functions. And thus, most such
operations would naturally not make sense when dealing with user-provided
functions that have no return value. So code that builds an array of return
values from functions that don't have a return value seems... odd. That
sounds like the user provided the wrong function, which should be a
compiler 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_50_1393947264.1444235973268
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, October 6, 2015 at 3:10:09 PM UTC-4, Matt Calabrese wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D=
"gmail_quote">On Tue, Oct 6, 2015 at 9:06 AM, Nicol Bolas <span dir=3D"ltr"=
>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"469=
EoG8zDAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39=
;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">=
jmck...@gmail.com</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);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr=
">I find this paper to be an interesting examination of the problem. It att=
empts to make `void` as regular as one could reasonably expect such a type =
to be.<br><br>However, the question is this: do we want `void` to be regula=
r, or do we want to avoid having to specialize templates for it in so many =
cases?<br><br>If the goal is to make `void` regular, then P0146 obviously f=
ails. There are too many occurrences of `void` being irregular for users to=
 be able to <i>generally</i> rely on type regularity.<br></div></blockquote=
><div><br></div><div>Why do you think void is not Regular in this proposal?=
 To be clear, &quot;Regular&quot; is with respect to generic programming (t=
here is a paper linked in the references that describes Regular types, but =
they are also described in Stepanov&#39;s books, formally in the old C++0x =
proposal, and I&#39;m sure the current Concepts TS will have such a concept=
 if it doesn&#39;t specify one already). In brief, a Regular type just has =
proper copy/move semantics is comparable, and move is noexcept. This propos=
al makes void Regular, and it is simply a monostate type.</div></div></div>=
</div></blockquote><div><br>I seem to have read your proposal backwards the=
n. I was looking for the treatment of specific instances, so my searches al=
l lead to the &quot;alternative&quot; section, which I mistook for the actu=
al proposal.<br><br>Sorry about that.<br>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><di=
v>=C2=A0</div><div>On Tue, Oct 6, 2015 at 9:06 AM, Nicol Bolas=C2=A0<span d=
ir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mai=
lto=3D"469EoG8zDAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javas=
cript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;retu=
rn true;">jmck...@gmail.com</a>&gt;</span>=C2=A0<wbr>wrote:</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width=
:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-lef=
t:1ex"><div dir=3D"ltr">I think that making `void` regular is simply the wr=
ong goal. I really think the goal should be to minimize the number of times=
 you need to specialize templates.<br></div></blockquote><div><br></div><di=
v>This is precisely how you accomplish that goal in a way that doesn&#39;t =
leave void as some kind of special type that needs explicit consideration i=
n generic code. Treating void as special is exactly the problem. It doesn&#=
39;t have to be=20
anything special. It can just be a Regular type and you&#39;re not losing=
=20
anything by that. Being special in the sense of not supporting=20
fundamental operations is what forces users to write code in odd ways=20
and to special case.</div></div></div></div></blockquote><div><br>Wait: if =
the goal is to help improve template code writing, why does it matter if `v=
oid` is a special type or not?<br><br>My issue here is that you seem to be =
conflating two points, using one to hide your desire for the other. Your pr=
oposal is very clear on the motivations. It&#39;s not that `void` ought to =
be a type, for some functional programming reason or whatever.<br><br>The m=
otivation is because, by making `void` regular, you make template programmi=
ng easier in various situations. You don&#39;t have to make complex special=
izations and such just for a minor case of a function with no return value.=
<br><br>However, if the goal is making template code easier to write, then =
whether `void` is &quot;some kind of special type that needs explicit consi=
deration in generic code&quot; is irrelevant. What matters is how hard it i=
s to provide that &quot;explicit consideration&quot;.<br><br>For example, <=
a href=3D"http://wg21.link/P0128">P0128 (consexpr_if)</a> solves your loggi=
ng problem thusly:<br><br><div class=3D"prettyprint" style=3D"background-co=
lor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: so=
lid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"=
><div class=3D"subprettyprint"><span style=3D"color: #800;" class=3D"styled=
-by-prettify">// Invoke a callable, logging its arguments and return value.=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">template</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> R</span><span style=3D"colo=
r: #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=
"styled-by-prettify">class</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">...</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> P</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"styled-by-prettify">class</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #606;" class=3D"styled-by-prettify">Callable</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br>R invoke_and_log</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">callable_log</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">R</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">P</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">...)&gt;&amp;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> log</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #606;" class=3D"styled-by-prettify">Callable</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;&amp;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> callable</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> P</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">...</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> args</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: #660;" class=3D"styled-by=
-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>=C2=A0 log</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">log=
_arguments</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">args</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">...);</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 constexpr=
_if</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">is_same_v</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">void</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">result_of_t</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">&lt;</span><span style=3D"color: #606;" class=3D"s=
tyled-by-prettify">Callable</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">A=
rgs</span><span style=3D"color: #660;" class=3D"styled-by-prettify">...&gt;=
&gt;)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">aut=
o</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> result <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">invoke</span><span style=3D"colo=
r: #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"styl=
ed-by-prettify">forward</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">&lt;</span><span style=3D"color: #606;" class=3D"styled-by-pre=
ttify">Callable</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">&gt;(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
callable</span><span style=3D"color: #660;" class=3D"styled-by-prettify">),=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0=
 =C2=A0 =C2=A0 std</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
forward</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">P</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;(</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">args</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">)...);</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 log</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">log_result</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">result</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> result</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">else</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">return</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</spa=
n></div></code></div><br></div><div>This code looks perfectly reasonable. Y=
ou could even write a metafunction to make the conditional a bit shorter, i=
f that bothers you.<br><br>This is a solution to the problem that motivates=
 your proposal. You probably won&#39;t prefer this solution. But you cannot=
 deny that it substantially reduces the burden on users when doing this sor=
t of stuff. It doesn&#39;t require adding function specializations and what=
not. It just works, and its easy to read and reason about.<br><br>So, do yo=
u want to make `void` regular, or do you want to help improve template code=
? Because the former is not required for the latter. You claim that `void` =
being special is &quot;the problem&quot;, but it&#39;s not. &quot;The probl=
em&quot; is the difficulty in writing <i>any</i> kind of conditional templa=
te code.<br><br>Solve that problem, and 80% of the reason for regularizing =
`void` goes away.<br><br>There is another problem with regularizing `void` =
that your proposal does not deal with. Namely, that you&#39;ve removed a fu=
ndamental distinction between &quot;functions that return a value&quot; and=
 &quot;functions that don&#39;t return a value&quot;.<br><br>As an example =
of where this distinction is important, consider a specialized transformati=
on visitor for a variant. That is, it converts one variant into another var=
iant. And let&#39;s say we&#39;re clever and we decree that the typelist fo=
r the generated variant will be deduced from the return types of the visito=
r (I don&#39;t know if that&#39;s possible, but it sounds plausible).<br><b=
r>Well, answer me this: what would it mean for the user to provide a `void`=
 function in such a visitor? Did the user make a mistake? Or does the user =
actually mean to store the `void` value?<br><br>It would make far more sens=
e for such a function to reject `void` functions. Why? Because thanks to au=
to return type deduction, it&#39;s very easy to compute a value and forget =
to return it, thus accidentally creating a `void` function. And sure, a com=
piler might offer a warning, but a compiler error is much more effective. I=
f the user truly wanted an &quot;empty&quot; state, they&#39;d use an empty=
 class.<br><br>With your case, my visitation function needs to expend effor=
t to <i>break</i> those using `void`. And without constexpr_if or concepts,=
 that effort is non-trivial.<br><br>In short, not every user <i>wants</i> t=
o treat `void` as regular. Why should regularity be the default case?<br><b=
r>So on the one hand, your solution to the problem seems like overkill; we =
can solve the problem adequately without affecting `void`. And on the other=
 hand, there are many cases where you don&#39;t want to treat `void` like a=
ny other type, and if you make `void` regular, you have to expend code to d=
o that.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote"><div></div><div></div><div>On Tue,=
 Oct 6, 2015 at 9:06 AM, Nicol Bolas=C2=A0<span dir=3D"ltr">&lt;<a href=3D"=
javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"469EoG8zDAAJ" rel=
=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;=
" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">jmck...@gmail.=
com</a>&gt;</span>=C2=A0<wbr>wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-col=
or:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"l=
tr">By examining the problem domain like this, I think you can find ways to=
 avoid some of the more pernicious issues of `void` regularity. I&#39;d gue=
ss you can avoid having named values of `void` type. Which also means you c=
an avoid questions of getting references to `void`, passing them around as =
arguments, copy/move, and so forth.<br></div></blockquote><div><br></div><d=
iv>You are still forcing writers of generic code to have arbitrary consider=
ations if they want to work with void. This also doesn&#39;t avoid question=
s like getting references to void, or forming arrays, or anything at all. T=
hese still frequently come up in generic code.</div></div></div></div></blo=
ckquote><div><br>You would strengthen your motivation section if you could =
provide real-world example code of cases where these operations are necessa=
ry. It would also make it easy for a user to judge if the code is logically=
 consistent.<br><br>It seems to me that most instances of such occurrences =
are when dealing with return values of user-provided functions. And thus, m=
ost such operations would naturally not make sense when dealing with user-p=
rovided functions that have no return value. So code that builds an array o=
f return values from functions that don&#39;t have a return value seems... =
odd. That sounds like the user provided the wrong function, which should be=
 a compiler error.<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_50_1393947264.1444235973268--
------=_Part_49_439962690.1444235973267--

.

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

>
>
>
> My issue here is that you seem to be conflating two points, using one to
> hide your desire for the other. Your proposal is very clear on the
> motivations. It's not that `void` ought to be a type, for some functional
> programming reason or whatever.
>
> The motivation is because, by making `void` regular, you make template
> programming easier in various situations. You don't have to make complex
> specializations and such just for a minor case of a function with no return
> value.
>
> However, if the goal is making template code easier to write, then whether
> `void` is "some kind of special type that needs explicit consideration in
> generic code" is irrelevant. What matters is how hard it is to provide that
> "explicit consideration".
>
>
The argument you're presenting in your various posts on this topic seems to
take, as a base assumption, that these "special handling for void" cases
happen very rarely, and are not that big a deal.  I write significantly
less library-level and fully generic code than many of the people on this
list, and yet I've run into this problem many times. It doesn't seem
infrequent, and it is always tedious.  Matt's proposal would already help
simplify the code I've had to write.  Particularly when I have compounded,
or nested structures and functions.

You seem to be very passionately arguing against this suggestion based on
the statement that people are using 'void' to mean the absence of a type,
as opposed to a monostate type, and yet you don't provide any real,
complete examples of code that do in fact require the distinction you're
defending.  In fact, Miro Knejp has demonstrated precisely that for 'normal
users', no problems will occur, and has shown that the theoretical
foundation for this proposal is strong.

Can you please provide real code examples that are not hypothetical
contrivances that would be broken by this proposal? Otherwise, it seems
like your objections are based on some individual interpretation or
discomfort.

Chris

--

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

--089e0117646d37b9e4052186ac66
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"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div><br><br>My issue here is that you seem to b=
e conflating two points, using one to hide your desire for the other. Your =
proposal is very clear on the motivations. It&#39;s not that `void` ought t=
o be a type, for some functional programming reason or whatever.<br><br>The=
 motivation is because, by making `void` regular, you make template program=
ming easier in various situations. You don&#39;t have to make complex speci=
alizations and such just for a minor case of a function with no return valu=
e.<br><br>However, if the goal is making template code easier to write, the=
n whether `void` is &quot;some kind of special type that needs explicit con=
sideration in generic code&quot; is irrelevant. What matters is how hard it=
 is to provide that &quot;explicit consideration&quot;.<br><br></div></bloc=
kquote><div><br></div><div>The argument you&#39;re presenting in your vario=
us posts on this topic seems to take, as a base assumption, that these &quo=
t;special handling for void&quot; cases happen very rarely, and are not tha=
t big a deal.=C2=A0 I write significantly less library-level and fully gene=
ric code than many of the people on this list, and yet I&#39;ve run into th=
is problem many times. It doesn&#39;t seem infrequent, and it is always ted=
ious.=C2=A0 Matt&#39;s proposal would already help simplify the code I&#39;=
ve had to write.=C2=A0 Particularly when I have compounded, or nested struc=
tures and functions.</div><div><br></div><div>You seem to be very passionat=
ely arguing against this suggestion based on the statement that people are =
using &#39;void&#39; to mean the absence of a type, as opposed to a monosta=
te type, and yet you don&#39;t provide any real, complete examples of code =
that do in fact require the distinction you&#39;re defending.=C2=A0 In fact=
, Miro Knejp has demonstrated precisely that for &#39;normal users&#39;, no=
 problems will occur, and has shown that the theoretical foundation for thi=
s proposal is strong.</div><div><br></div><div>Can you please provide real =
code examples that are not hypothetical contrivances that would be broken b=
y this proposal? Otherwise, it seems like your objections are based on some=
 individual interpretation or discomfort.</div><div><br></div><div>Chris</d=
iv><div><br></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 />

--089e0117646d37b9e4052186ac66--

.

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

On 7 October 2015 at 11:27, Christopher Horvath <blackencino@gmail.com>
wrote:

>
> Given that C does not allow function overloads by name, and has no
> templates, am I wrong in thinking that the effects are essentially
> non-existent?
>

I have no idea.  Someone who wants this change to the language has to go
through the C standard and figure that out.

For instance:

C11 6.2.5p19: The void type comprises an empty set of values; it is an
incomplete object type that cannot be completed.

Surely that would no longer be true.  Are there any repercussions from that
in the rest of the C standard?  Sure.  Now sizeof(void) compiles.

What if sizeof(void) > 1 (since the proposal has opted to leave the
sizeof(void) unspecified)?  Could that violate

C11 6.2.5p28: A pointer to void shall have the same representation and
alignment requirements as a pointer to a character type.

Etc. etc.

Given that this is a breaking change from C, the proposal author has to go
through the C standard and document the repercussions so the committee can
decide how significant those changes are.  Plus, all that would need to be
documented in Annex C of the C++ Standard were such a proposal to pass.
--
 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/.

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

<div dir=3D"ltr">On 7 October 2015 at 11:27, Christopher Horvath <span dir=
=3D"ltr">&lt;<a href=3D"mailto:blackencino@gmail.com" target=3D"_blank">bla=
ckencino@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:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bo=
rder-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"=
gmail_extra">Given that C does not allow function overloads by name, and ha=
s no templates, am I wrong in thinking that the effects are essentially non=
-existent?=C2=A0<br></div></div></blockquote><div><br></div><div>I have no =
idea.=C2=A0 Someone who wants this change to the language has to go through=
 the C standard and figure that out.</div><div><br></div><div>For instance:=
</div><div><br></div><div>C11 6.2.5p19:=C2=A0<span style=3D"font-family:Tim=
es;font-size:12px">The </span><span style=3D"font-size:12px;line-height:nor=
mal;font-family:Courier">void </span><span style=3D"font-family:Times;font-=
size:12px">type comprises an empty set of values; it is an incomplete objec=
t type that cannot be completed.</span></div><div><br></div><div><div>Surel=
y that would no longer be true.=C2=A0 Are there any repercussions from that=
 in the rest of the C standard?=C2=A0 Sure.=C2=A0 Now sizeof(void) compiles=
..</div></div><div><br></div><div>What if sizeof(void) &gt; 1 (since the pro=
posal has opted to leave the sizeof(void) unspecified)?=C2=A0 Could that vi=
olate</div><div><br></div><div>C11 6.2.5p28:=C2=A0<span style=3D"font-famil=
y:Times;font-size:12px">A pointer to </span><span style=3D"font-size:12px;l=
ine-height:normal;font-family:Courier">void </span><span style=3D"font-fami=
ly:Times;font-size:12px">shall have the same representation and alignment r=
equirements as a pointer to a character type.</span></div><div><br></div><d=
iv>Etc. etc.</div><div><br></div><div>Given that this is a breaking change =
from C, the proposal author has to go through the C standard and document t=
he repercussions so the committee can decide how significant those changes =
are.=C2=A0 Plus, all that would need to be documented in Annex C of the C++=
 Standard were such a proposal to pass.</div></div>-- <br><div class=3D"gma=
il_signature">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D=
"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.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 />

--001a1143f1c0f81ef4052186b3a2--

.

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

On Wed, Oct 7, 2015 at 7:49 AM, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 5 October 2015 at 13:43, Matt Calabrese <calabrese@google.com> wrote:
>
>>
>> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html
>>
>
> Given that *void* is all over the place in the C standard, which is the
> base document for C++, it is surprising not to find a detailed section on C
> Compatibility in your proposal.  Do you plan on adding one soon?
>

Define soon ;) I didn't plan on sending around a draft of a revision prior
to Kona, if that's what you mean (though I suppose I can, if you want), but
assuming the idea isn't completely thrown out at Kona and something like
this ends up being required, I'll add a further section in a revision to
this, in addition to the separate proposal for standard library changes
(std::promise, etc.).

--

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

--001a11c182265aec870521876ee9
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 W=
ed, Oct 7, 2015 at 7:49 AM, Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&g=
t;</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">On 5 Oc=
tober 2015 at 13:43, Matt Calabrese <span dir=3D"ltr">&lt;<a href=3D"mailto=
:calabrese@google.com" target=3D"_blank">calabrese@google.com</a>&gt;</span=
> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr"><div><br></div>[1] <a href=3D"http:/=
/www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html" target=3D"_=
blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0146r0.html=
</a></div></blockquote><div><br></div><div>Given that <u>void</u> is all ov=
er the place in the C standard, which is the base document for C++, it is s=
urprising not to find a detailed section on C Compatibility in your proposa=
l.=C2=A0 Do you plan on adding one soon?</div></div></div></div></blockquot=
e><div><br></div><div>Define soon ;) I didn&#39;t plan on sending around a =
draft of a revision prior to Kona, if that&#39;s what you mean (though I su=
ppose I can, if you want), but assuming the idea isn&#39;t completely throw=
n out at Kona and something like this ends up being required, I&#39;ll add =
a further section in a revision to this, in addition to the separate propos=
al for standard library changes (std::promise, etc.).</div></div><br></div>=
</div>

<p></p>

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

--001a11c182265aec870521876ee9--

.

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

On Wed, Oct 7, 2015 at 9:39 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Tuesday, October 6, 2015 at 3:10:09 PM UTC-4, Matt Calabrese wrote:
>>
>> On Tue, Oct 6, 2015 at 9:06 AM, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> I find this paper to be an interesting examination of the problem. It
>>> attempts to make `void` as regular as one could reasonably expect such a
>>> type to be.
>>>
>>> However, the question is this: do we want `void` to be regular, or do we
>>> want to avoid having to specialize templates for it in so many cases?
>>>
>>> If the goal is to make `void` regular, then P0146 obviously fails. There
>>> are too many occurrences of `void` being irregular for users to be able to
>>> *generally* rely on type regularity.
>>>
>>
>> Why do you think void is not Regular in this proposal? To be clear,
>> "Regular" is with respect to generic programming (there is a paper linked
>> in the references that describes Regular types, but they are also described
>> in Stepanov's books, formally in the old C++0x proposal, and I'm sure the
>> current Concepts TS will have such a concept if it doesn't specify one
>> already). In brief, a Regular type just has proper copy/move semantics is
>> comparable, and move is noexcept. This proposal makes void Regular, and it
>> is simply a monostate type.
>>
>
> I seem to have read your proposal backwards then. I was looking for the
> treatment of specific instances, so my searches all lead to the
> "alternative" section, which I mistook for the actual proposal.
>

I could probably separate that out better. It's also been pointed out that
I should probably inline an exact definition of Regular (as even that has
gone through subtle revisions over time, especially since the language got
move semantics).

On Wed, Oct 7, 2015 at 9:39 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Tue, Oct 6, 2015 at 9:06 AM, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> I think that making `void` regular is simply the wrong goal. I really
>>> think the goal should be to minimize the number of times you need to
>>> specialize templates.
>>>
>>
>> This is precisely how you accomplish that goal in a way that doesn't
>> leave void as some kind of special type that needs explicit consideration
>> in generic code. Treating void as special is exactly the problem. It
>> doesn't have to be anything special. It can just be a Regular type and
>> you're not losing anything by that. Being special in the sense of not
>> supporting fundamental operations is what forces users to write code in odd
>> ways and to special case.
>>
>
> Wait: if the goal is to help improve template code writing, why does it
> matter if `void` is a special type or not?
>

It can be special in that it can do *more, *just like how a random access
iterator is still a forward iterator and usable with functions that expect
forward iterators, even though it can do *more* than a forward iterator.
This is why things like the ability to write "return;" in a function that
returns void, or that objects are explicitly convertible to void don't
hinder writing generic code. Not being able to do things like copy them or
make arrays or tuples of them, on the other hand, does actually hurt our
ability to write generic code. As an example, imagine a generic algorithm
that, as a part of its execution, executes N function objects that were
provided by the user and packages up the return values, returning them as a
tuple. There's not really anything logically weird about this. The user
should be able to access the Nth return value via the Nth location in the
tuple. They should be able to iterate over elements over the tuple, etc. If
one of the functions happened to return void, then this is fine. In the
generic algorithm it doesn't matter, even though many of the operations
involved just happen to effectively be no-ops. On the user-side, they don't
have to do anything particularly special to account for the fact that one
of their functions returned void. All of this is fine. Instantiating,
copying, and comparing instances of void in non-generic code isn't
particularly interesting, but there's nothing incorrect about it, and as
soon as void becomes a dependent type, you can encounter generic code that
requires those operations, since in the generic case they don't know (and
also shouldn't care) that things like copies are a no-op for your
particular type.

On Wed, Oct 7, 2015 at 9:39 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> The motivation is because, by making `void` regular, you make template
> programming easier in various situations. You don't have to make complex
> specializations and such just for a minor case of a function with no return
> value.
>
> However, if the goal is making template code easier to write, then whether
> `void` is "some kind of special type that needs explicit consideration in
> generic code" is irrelevant. What matters is how hard it is to provide that
> "explicit consideration".
>

It's that void shouldn't require explicit consideration *at all*. If you
logically just represent it as a unit type, it's an object type like
anything other object type. Indeed, some broader definitions of a void type
even explicitly refer to it as a unit type, even though C++ currently
doesn't specify it as such. Even if we had other ways that simply made it
easier to handle void, think about what you'd specify as the concept
requirements of your generic function that potentially involves void as a
dependent type "T" -- specifically, what would the concept requirements of
"T" be for your algorithm? "T must model the Regular concept... or it can
be a void type" (the notion of "or" constraints are already pretty dubious
in generic code to begin with). Similarly, this would be true of all other
generic functions that need to deal with a Regular type but also want to
account for void. So not only are you complicating the implementation of
your function, but you're also complicating its specification. Why? Having
void be a unit type removes all of this. It also simplifies the standard
and how people need to think about types in C++.

On Wed, Oct 7, 2015 at 9:39 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

>
> For example, P0128 (consexpr_if) <http://wg21.link/P0128> solves your
> logging problem thusly:
>
> // Invoke a callable, logging its arguments and return value.
> template<class R, class... P, class Callable>
> R invoke_and_log(callable_log<R(P...)>& log, Callable&& callable, P...
> args) {
>   log.log_arguments(args...);
>   constexpr_if(is_same_v<void, std::result_of_t<Callable, Args...>>)
>   {
>     auto result = std::invoke(std::forward<Callable>(callable),
>       std::forward<P>(args)...);
>     log.log_result(result);
>     return result;
>   }
>   else
>     return;
> }
>
> This code looks perfectly reasonable. You could even write a metafunction
> to make the conditional a bit shorter, if that bothers you.
>
> This is a solution to the problem that motivates your proposal. You
> probably won't prefer this solution. But you cannot deny that it
> substantially reduces the burden on users when doing this sort of stuff. It
> doesn't require adding function specializations and whatnot. It just works,
> and its easy to read and reason about.
>

Your example doesn't execute the function in the void case, nor does it log
the result. Even if you made the proper fix here, that still requires
explicit consideration for void, and it also makes the concept requirements
of the function complicated, so I wouldn't consider it a solution to the
problem. We already have existing solutions in the language today, without
modification, that makes things analogous to what you show possible to
write. You can even inline such solutions in the definition of the function
template (if not clear, you can [partially] simulate static-if/constexpr_if
by way of generic lambdas and forcing types involved to be dependent).

On Wed, Oct 7, 2015 at 9:39 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> There is another problem with regularizing `void` that your proposal does
> not deal with. Namely, that you've removed a fundamental distinction
> between "functions that return a value" and "functions that don't return a
> value".
>

I've addressed this numerous times and why the concern is completely
illusory. Since it keeps coming up, I'll add a section on it if there ends
up being another revision.

On Wed, Oct 7, 2015 at 9:39 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> As an example of where this distinction is important, consider a
> specialized transformation visitor for a variant. That is, it converts one
> variant into another variant. And let's say we're clever and we decree that
> the typelist for the generated variant will be deduced from the return
> types of the visitor (I don't know if that's possible, but it sounds
> plausible).
>
> Well, answer me this: what would it mean for the user to provide a `void`
> function in such a visitor? Did the user make a mistake? Or does the user
> actually mean to store the `void` value?
>

??? Why do you think that's a problem. The overall result type (assuming
some form of deduction) would be void or possibly would require the user to
be explicit (though I'd personally suggest the former, but it doesn't
really matter), which isn't especially different whether vodi is Regular or
not. What do you think is weird here? If they provide a function that
returns void it's not a mistake nowadays when doing visitation.

On Wed, Oct 7, 2015 at 9:39 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> It would make far more sense for such a function to reject `void`
> functions. Why? Because thanks to auto return type deduction, it's very
> easy to compute a value and forget to return it, thus accidentally creating
> a `void` function. And sure, a compiler might offer a warning, but a
> compiler error is much more effective. If the user truly wanted an "empty"
> state, they'd use an empty class.
>

Not that what you are saying is particularly different whether or not void
undergoes the proposed changes, are you really advocating that variant's
visitation function shouldn't allow void return types, and further that
*this* is also why void shouldn't be Regular!? As someone who has worked
with variants and visitation in pretty much every project for very many
years, visitors that return void are not at all uncommon, though it doesn't
take experience to understand that. There is nothing logically incorrect
about them. People "forgetting to write return" does not change whether
void is Regular or if it were to stay just as it is today. If you want
people to be explicit instead of relying on deduction in that void case,
assuming you support deduction at all with the apply_visitor-like function
template, you could always require the user to be explicit about the return
type in those cases. This is true whether the proposal is accepted or not.

On Wed, Oct 7, 2015 at 9:39 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> In short, not every user *wants* to treat `void` as regular. Why should
> regularity be the default case?
>

Because it is only additional functionality that you do not pay for. If you
don't want that additional functionality then simply do not use it. People
who write real world generic code care about this and it's even a
simplification to the type system and the standard.

 On Wed, Oct 7, 2015 at 9:39 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> So on the one hand, your solution to the problem seems like overkill; we
> can solve the problem adequately without affecting `void`.
>

I don't consider a simplification to the standard to be "overkill" and the
other suggested solutions only add more special casing.

On Wed, Oct 7, 2015 at 9:39 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> You would strengthen your motivation section if you could provide
> real-world example code of cases where these operations are necessary. It
> would also make it easy for a user to judge if the code is logically
> consistent.
>

Yeah, noted :/ I should have included a bunch of example uses.


On Wed, Oct 7, 2015 at 9:39 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> It seems to me that most instances of such occurrences are when dealing
> with return values of user-provided functions. And thus, most such
> operations would naturally not make sense when dealing with user-provided
> functions that have no return value. So code that builds an array of return
> values from functions that don't have a return value seems... odd. That
> sounds like the user provided the wrong function, which should be a
> compiler error.
>

It's not particularly odd. Any generic function that executes some
user-provided functions may want to forward back those results to the user
in some way. If the user provided functions that happened to return void,
then the user probably wouldn't touch those results (unless they are also
in generic code). If the result wasn't void, the user might examine the
results. The generic code isn't impacted, regardless. It's not very
dissimilar from std::for_each returning the function object that was passed
in. People pass in simple function objects to std::for_each that have no
state very frequently (those function objects are monostate/unit types).
The generic function still returns the function object back to the caller
in the even that their function object did have some state that the user
may with to examine. If there is no information that needs to be conveyed,
then so what? There's no logical error there.

--

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

--001a11c29966552dfd05218897b4
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 W=
ed, Oct 7, 2015 at 9:39 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</sp=
an> 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);border-left=
-style:solid;padding-left:1ex">On Tuesday, October 6, 2015 at 3:10:09 PM UT=
C-4, Matt Calabrese wrote:<span class=3D""><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color=
:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr=
"><div><div class=3D"gmail_quote">On Tue, Oct 6, 2015 at 9:06 AM, Nicol Bol=
as <span dir=3D"ltr">&lt;<a rel=3D"nofollow">jmck...@gmail.com</a>&gt;</spa=
n> 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);border-left-=
style:solid;padding-left:1ex"><div dir=3D"ltr">I find this paper to be an i=
nteresting examination of the problem. It attempts to make `void` as regula=
r as one could reasonably expect such a type to be.<br><br>However, the que=
stion is this: do we want `void` to be regular, or do we want to avoid havi=
ng to specialize templates for it in so many cases?<br><br>If the goal is t=
o make `void` regular, then P0146 obviously fails. There are too many occur=
rences of `void` being irregular for users to be able to <i>generally</i> r=
ely on type regularity.<br></div></blockquote><div><br></div><div>Why do yo=
u think void is not Regular in this proposal? To be clear, &quot;Regular&qu=
ot; is with respect to generic programming (there is a paper linked in the =
references that describes Regular types, but they are also described in Ste=
panov&#39;s books, formally in the old C++0x proposal, and I&#39;m sure the=
 current Concepts TS will have such a concept if it doesn&#39;t specify one=
 already). In brief, a Regular type just has proper copy/move semantics is =
comparable, and move is noexcept. This proposal makes void Regular, and it =
is simply a monostate type.</div></div></div></div></blockquote></span><div=
><br>I seem to have read your proposal backwards then. I was looking for th=
e treatment of specific instances, so my searches all lead to the &quot;alt=
ernative&quot; section, which I mistook for the actual proposal.<br></div><=
/blockquote><div><br></div><div>I could probably separate that out better. =
It&#39;s also been pointed out that I should probably inline an exact defin=
ition of Regular (as even that has gone through subtle revisions over time,=
 especially since the language got move semantics).=C2=A0</div><div>=C2=A0<=
/div><div>On Wed, Oct 7, 2015 at 9:39 AM, Nicol Bolas=C2=A0<span dir=3D"ltr=
">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gm=
ail.com</a>&gt;</span>=C2=A0wrote:</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rg=
b(204,204,204);border-left-style:solid;padding-left:1ex"><span class=3D""><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>On Tu=
e, Oct 6, 2015 at 9:06 AM, Nicol Bolas=C2=A0<span dir=3D"ltr">&lt;<a rel=3D=
"nofollow">jmck...@gmail.com</a>&gt;</span>=C2=A0wrote:</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px=
;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1e=
x"><div dir=3D"ltr">I think that making `void` regular is simply the wrong =
goal. I really think the goal should be to minimize the number of times you=
 need to specialize templates.<br></div></blockquote><div><br></div><div>Th=
is is precisely how you accomplish that goal in a way that doesn&#39;t leav=
e void as some kind of special type that needs explicit consideration in ge=
neric code. Treating void as special is exactly the problem. It doesn&#39;t=
 have to be=20
anything special. It can just be a Regular type and you&#39;re not losing=
=20
anything by that. Being special in the sense of not supporting=20
fundamental operations is what forces users to write code in odd ways=20
and to special case.</div></div></div></div></blockquote></span><div><br>Wa=
it: if the goal is to help improve template code writing, why does it matte=
r if `void` is a special type or not?<br></div></blockquote><div><br></div>=
<div>It can be special in that it can do <i>more,=C2=A0</i>just like how a =
random access iterator is still a forward iterator and usable with function=
s that expect forward iterators, even though it can do <i>more</i>=C2=A0tha=
n a forward iterator. This is why things like the ability to write &quot;re=
turn;&quot; in a function that returns void, or that objects are explicitly=
 convertible to void don&#39;t hinder writing generic code. Not being able =
to do things like copy them or make arrays or tuples of them, on the other =
hand, does actually hurt our ability to write generic code. As an example, =
imagine a generic algorithm that, as a part of its execution, executes N fu=
nction objects that were provided by the user and packages up the return va=
lues, returning them as a tuple. There&#39;s not really anything logically =
weird about this. The user should be able to access the Nth return value vi=
a the Nth location in the tuple. They should be able to iterate over elemen=
ts over the tuple, etc. If one of the functions happened to return void, th=
en this is fine. In the generic algorithm it doesn&#39;t matter, even thoug=
h many of the operations involved just happen to effectively be no-ops. On =
the user-side, they don&#39;t have to do anything particularly special to a=
ccount for the fact that one of their functions returned void. All of this =
is fine. Instantiating, copying, and comparing instances of void in non-gen=
eric code isn&#39;t particularly interesting, but there&#39;s nothing incor=
rect about it, and as soon as void becomes a dependent type, you can encoun=
ter generic code that requires those operations, since in the generic case =
they don&#39;t know (and also shouldn&#39;t care) that things like copies a=
re a no-op for your particular type.</div><div><br></div><div>On Wed, Oct 7=
, 2015 at 9:39 AM, Nicol Bolas=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto=
:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span>=
=C2=A0wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-=
left-style:solid;padding-left:1ex"><div>The motivation is because, by makin=
g `void` regular, you make template programming easier in various situation=
s. You don&#39;t have to make complex specializations and such just for a m=
inor case of a function with no return value.<br><br>However, if the goal i=
s making template code easier to write, then whether `void` is &quot;some k=
ind of special type that needs explicit consideration in generic code&quot;=
 is irrelevant. What matters is how hard it is to provide that &quot;explic=
it consideration&quot;.<br></div></blockquote><div><br></div><div>It&#39;s =
that void shouldn&#39;t require explicit consideration <i>at all</i>. If yo=
u logically just represent it as a unit type, it&#39;s an object type like =
anything other object type. Indeed, some broader definitions of a void type=
 even explicitly refer to it as a unit type, even though C++ currently does=
n&#39;t specify it as such. Even if we had other ways that simply made it e=
asier to handle void, think about what you&#39;d specify as the concept req=
uirements of your generic function that potentially involves void as a depe=
ndent type &quot;T&quot; -- specifically, what would the concept requiremen=
ts of &quot;T&quot; be for your algorithm? &quot;T must model the Regular c=
oncept... or it can be a void type&quot; (the notion of &quot;or&quot; cons=
traints are already pretty dubious in generic code to begin with). Similarl=
y, this would be true of all other generic functions that need to deal with=
 a Regular type but also want to account for void. So not only are you comp=
licating the implementation of your function, but you&#39;re also complicat=
ing its specification. Why? Having void be a unit type removes all of this.=
 It also simplifies the standard and how people need to think about types i=
n C++.</div><div><br></div><div>On Wed, Oct 7, 2015 at 9:39 AM, Nicol Bolas=
=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=
=3D"_blank">jmckesson@gmail.com</a>&gt;</span>=C2=A0wrote:</div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:=
1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left=
:1ex"><div><br>For example, <a href=3D"http://wg21.link/P0128" target=3D"_b=
lank">P0128 (consexpr_if)</a> solves your logging problem thusly:<br><br><d=
iv style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;backgrou=
nd-color:rgb(250,250,250)"><code><div><span class=3D""><span style=3D"color=
:rgb(136,0,0)">// Invoke a callable, logging its arguments and return value=
..</span><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rg=
b(0,0,136)">template</span><span style=3D"color:rgb(102,102,0)">&lt;</span>=
<span style=3D"color:rgb(0,0,136)">class</span><span style=3D"color:rgb(0,0=
,0)"> R</span><span style=3D"color:rgb(102,102,0)">,</span><span style=3D"c=
olor:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">class</span><sp=
an style=3D"color:rgb(102,102,0)">...</span><span style=3D"color:rgb(0,0,0)=
"> P</span><span style=3D"color:rgb(102,102,0)">,</span><span style=3D"colo=
r:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">class</span><span =
style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,0,102)">Cal=
lable</span><span style=3D"color:rgb(102,102,0)">&gt;</span><span style=3D"=
color:rgb(0,0,0)"><br>R invoke_and_log</span><span style=3D"color:rgb(102,1=
02,0)">(</span><span style=3D"color:rgb(0,0,0)">callable_log</span><span st=
yle=3D"color:rgb(102,102,0)">&lt;</span><span style=3D"color:rgb(0,0,0)">R<=
/span><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb=
(0,0,0)">P</span><span style=3D"color:rgb(102,102,0)">...)&gt;&amp;</span><=
span style=3D"color:rgb(0,0,0)"> log</span><span style=3D"color:rgb(102,102=
,0)">,</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:=
rgb(102,0,102)">Callable</span><span style=3D"color:rgb(102,102,0)">&amp;&a=
mp;</span><span style=3D"color:rgb(0,0,0)"> callable</span><span style=3D"c=
olor:rgb(102,102,0)">,</span><span style=3D"color:rgb(0,0,0)"> P</span><spa=
n style=3D"color:rgb(102,102,0)">...</span><span style=3D"color:rgb(0,0,0)"=
> args</span><span style=3D"color:rgb(102,102,0)">)</span><span style=3D"co=
lor:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">{</span><span =
style=3D"color:rgb(0,0,0)"><br>=C2=A0 log</span><span style=3D"color:rgb(10=
2,102,0)">.</span><span style=3D"color:rgb(0,0,0)">log_arguments</span><spa=
n style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,0)">a=
rgs</span><span style=3D"color:rgb(102,102,0)">...);</span></span><span sty=
le=3D"color:rgb(0,0,0)"><br>=C2=A0 constexpr_if</span><span style=3D"color:=
rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,0)">is_same_v</span><s=
pan style=3D"color:rgb(102,102,0)">&lt;</span><span style=3D"color:rgb(0,0,=
136)">void</span><span style=3D"color:rgb(102,102,0)">,</span><span style=
=3D"color:rgb(0,0,0)"> std</span><span style=3D"color:rgb(102,102,0)">::</s=
pan><span style=3D"color:rgb(0,0,0)">result_of_t</span><span style=3D"color=
:rgb(102,102,0)">&lt;</span><span style=3D"color:rgb(102,0,102)">Callable</=
span><span style=3D"color:rgb(102,102,0)">,</span><span style=3D"color:rgb(=
0,0,0)"> </span><span style=3D"color:rgb(102,0,102)">Args</span><span style=
=3D"color:rgb(102,102,0)">...&gt;&gt;)</span><span style=3D"color:rgb(0,0,0=
)"><br>=C2=A0 </span><span style=3D"color:rgb(102,102,0)">{</span><span sty=
le=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(0=
,0,136)">auto</span><span style=3D"color:rgb(0,0,0)"> result </span><span s=
tyle=3D"color:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> s=
td</span><span style=3D"color:rgb(102,102,0)">::</span><span style=3D"color=
:rgb(0,0,0)">invoke</span><span style=3D"color:rgb(102,102,0)">(</span><spa=
n style=3D"color:rgb(0,0,0)">std</span><span style=3D"color:rgb(102,102,0)"=
>::</span><span style=3D"color:rgb(0,0,0)">forward</span><span style=3D"col=
or:rgb(102,102,0)">&lt;</span><span style=3D"color:rgb(102,0,102)">Callable=
</span><span style=3D"color:rgb(102,102,0)">&gt;(</span><span style=3D"colo=
r:rgb(0,0,0)">callable</span><span style=3D"color:rgb(102,102,0)">),</span>=
<span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =C2=A0 std</span><span s=
tyle=3D"color:rgb(102,102,0)">::</span><span style=3D"color:rgb(0,0,0)">for=
ward</span><span style=3D"color:rgb(102,102,0)">&lt;</span><span style=3D"c=
olor:rgb(0,0,0)">P</span><span style=3D"color:rgb(102,102,0)">&gt;(</span><=
span style=3D"color:rgb(0,0,0)">args</span><span style=3D"color:rgb(102,102=
,0)">)...);</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 log</s=
pan><span style=3D"color:rgb(102,102,0)">.</span><span style=3D"color:rgb(0=
,0,0)">log_result</span><span style=3D"color:rgb(102,102,0)">(</span><span =
style=3D"color:rgb(0,0,0)">result</span><span style=3D"color:rgb(102,102,0)=
">);</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span =
style=3D"color:rgb(0,0,136)">return</span><span style=3D"color:rgb(0,0,0)">=
 result</span><span style=3D"color:rgb(102,102,0)">;</span><span style=3D"c=
olor:rgb(0,0,0)"><br>=C2=A0 </span><span style=3D"color:rgb(102,102,0)">}</=
span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 </span><span style=3D"colo=
r:rgb(0,0,136)">else</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=
=A0 </span><span style=3D"color:rgb(0,0,136)">return</span><span style=3D"c=
olor:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br></span><s=
pan style=3D"color:rgb(102,102,0)">}</span></div></code></div><br></div><di=
v>This code looks perfectly reasonable. You could even write a metafunction=
 to make the conditional a bit shorter, if that bothers you.<br><br>This is=
 a solution to the problem that motivates your proposal. You probably won&#=
39;t prefer this solution. But you cannot deny that it substantially reduce=
s the burden on users when doing this sort of stuff. It doesn&#39;t require=
 adding function specializations and whatnot. It just works, and its easy t=
o read and reason about.<br></div></blockquote><div><br></div><div>Your exa=
mple doesn&#39;t execute the function in the void case, nor does it log the=
 result. Even if you made the proper fix here, that still requires explicit=
 consideration for void, and it also makes the concept requirements of the =
function complicated, so I wouldn&#39;t consider it a solution to the probl=
em. We already have existing solutions in the language today, without modif=
ication, that makes things analogous to what you show possible to write. Yo=
u can even inline such solutions in the definition of the function template=
 (if not clear, you can [partially] simulate static-if/constexpr_if by way =
of generic lambdas and forcing types involved to be dependent).</div><div><=
br></div><div>On Wed, Oct 7, 2015 at 9:39 AM, Nicol Bolas=C2=A0<span dir=3D=
"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesso=
n@gmail.com</a>&gt;</span>=C2=A0wrote:=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>The=
re is another problem with regularizing `void` that your proposal does not =
deal with. Namely, that you&#39;ve removed a fundamental distinction betwee=
n &quot;functions that return a value&quot; and &quot;functions that don&#3=
9;t return a value&quot;.<br></div></blockquote><div><br></div><div>I&#39;v=
e addressed this numerous times and why the concern is completely illusory.=
 Since it keeps coming up, I&#39;ll add a section on it if there ends up be=
ing another revision.</div><div><br></div><div>On Wed, Oct 7, 2015 at 9:39 =
AM, Nicol Bolas=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:jmckesson@gmai=
l.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span>=C2=A0wrote:=C2=
=A0=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div>As an example of where this distinctio=
n is important, consider a specialized transformation visitor for a variant=
.. That is, it converts one variant into another variant. And let&#39;s say =
we&#39;re clever and we decree that the typelist for the generated variant =
will be deduced from the return types of the visitor (I don&#39;t know if t=
hat&#39;s possible, but it sounds plausible).<br><br>Well, answer me this: =
what would it mean for the user to provide a `void` function in such a visi=
tor? Did the user make a mistake? Or does the user actually mean to store t=
he `void` value?<br></div></blockquote><div><br></div><div>??? Why do you t=
hink that&#39;s a problem. The overall result type (assuming some form of d=
eduction) would be void or possibly would require the user to be explicit (=
though I&#39;d personally suggest the former, but it doesn&#39;t really mat=
ter), which isn&#39;t especially different whether vodi is Regular or not. =
What do you think is weird here? If they provide a function that returns vo=
id it&#39;s not a mistake nowadays when doing visitation.</div><div>=C2=A0<=
/div><div>On Wed, Oct 7, 2015 at 9:39 AM, Nicol Bolas=C2=A0<span dir=3D"ltr=
">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gm=
ail.com</a>&gt;</span>=C2=A0wrote:=C2=A0=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>I=
t would make far more sense for such a function to reject `void` functions.=
 Why? Because thanks to auto return type deduction, it&#39;s very easy to c=
ompute a value and forget to return it, thus accidentally creating a `void`=
 function. And sure, a compiler might offer a warning, but a compiler error=
 is much more effective. If the user truly wanted an &quot;empty&quot; stat=
e, they&#39;d use an empty class.<br></div></blockquote><div><br></div><div=
>Not that what you are saying is particularly different whether or not void=
 undergoes the proposed changes, are you really advocating that variant&#39=
;s visitation function shouldn&#39;t allow void return types, and further t=
hat <i>this</i>=C2=A0is also why void shouldn&#39;t be Regular!? As someone=
 who has worked with variants and visitation in pretty much every project f=
or very many years, visitors that return void are not at all uncommon, thou=
gh it doesn&#39;t take experience to understand that. There is nothing logi=
cally incorrect about them. People &quot;forgetting to write return&quot; d=
oes not change whether void is Regular or if it were to stay just as it is =
today. If you want people to be explicit instead of relying on deduction in=
 that void case, assuming you support deduction at all with the apply_visit=
or-like function template, you could always require the user to be explicit=
 about the return type in those cases. This is true whether the proposal is=
 accepted or not.</div><div><br></div><div>On Wed, Oct 7, 2015 at 9:39 AM, =
Nicol Bolas=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.co=
m" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span>=C2=A0wrote:=C2=A0=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex"><div>In short, not every user <i>wants</i> to =
treat `void` as regular. Why should regularity be the default case?<br></di=
v></blockquote><div><br></div><div>Because it is only additional functional=
ity that you do not pay for. If you don&#39;t want that additional function=
ality then simply do not use it. People who write real world generic code c=
are about this and it&#39;s even a simplification to the type system and th=
e standard.</div><div><br></div><div>=C2=A0On Wed, Oct 7, 2015 at 9:39 AM, =
Nicol Bolas=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.co=
m" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span>=C2=A0wrote: =C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:so=
lid;padding-left:1ex"><div>So on the one hand, your solution to the problem=
 seems like overkill; we can solve the problem adequately without affecting=
 `void`.<br></div></blockquote><div><br></div><div>I don&#39;t consider a s=
implification to the standard to be &quot;overkill&quot; and the other sugg=
ested solutions only add more special casing.</div><div><br></div><div>On W=
ed, Oct 7, 2015 at 9:39 AM, Nicol Bolas=C2=A0<span dir=3D"ltr">&lt;<a href=
=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&g=
t;</span>=C2=A0wrote:=C2=A0=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb=
(204,204,204);border-left-style:solid;padding-left:1ex"><div>You would stre=
ngthen your motivation section if you could provide real-world example code=
 of cases where these operations are necessary. It would also make it easy =
for a user to judge if the code is logically consistent.<br></div></blockqu=
ote><div><br></div><div>Yeah, noted :/ I should have included a bunch of ex=
ample uses.</div><div>=C2=A0</div><div><br></div><div>On Wed, Oct 7, 2015 a=
t 9:39 AM, Nicol Bolas=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:jmckess=
on@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span>=C2=A0wro=
te:=C2=A0=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);=
border-left-style:solid;padding-left:1ex"><div>It seems to me that most ins=
tances of such occurrences are when dealing with return values of user-prov=
ided functions. And thus, most such operations would naturally not make sen=
se when dealing with user-provided functions that have no return value. So =
code that builds an array of return values from functions that don&#39;t ha=
ve a return value seems... odd. That sounds like the user provided the wron=
g function, which should be a compiler error.<br></div></blockquote><div><b=
r></div><div>It&#39;s not particularly odd. Any generic function that execu=
tes some user-provided functions may want to forward back those results to =
the user in some way. If the user provided functions that happened to retur=
n void, then the user probably wouldn&#39;t touch those results (unless the=
y are also in generic code). If the result wasn&#39;t void, the user might =
examine the results. The generic code isn&#39;t impacted, regardless. It&#3=
9;s not very dissimilar from std::for_each returning the function object th=
at was passed in. People pass in simple function objects to std::for_each t=
hat have no state very frequently (those function objects are monostate/uni=
t types). The generic function still returns the function object back to th=
e caller in the even that their function object did have some state that th=
e user may with to examine. If there is no information that needs to be con=
veyed, then so what? There&#39;s no logical error there.</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 />

--001a11c29966552dfd05218897b4--

.

------=_Part_1271_2090014459.1444343682387
Content-Type: multipart/alternative;
 boundary="----=_Part_1272_1146980637.1444343682387"

------=_Part_1272_1146980637.1444343682387
Content-Type: text/plain; charset=UTF-8

I think I can help strengthen the motivational case for this feature
(despite the fact that I loathe the very concept of it).

I think the logging function is a terrible example, and it should not be
the primary focus of the motivation section. Though it is a simple example,
it is precisely the simplicity that's the problem. It's too easily
dismissed, for three reasons:

1) The required code to support functions with no return value is, quite
frankly, not that hard to write.

2) There are proposed language features that make it even easier to both
write and read.

3) It raises the question of why a user would want to log `void` returns at
all. The function call and it's parameters, yes. But does a user *really*
want to see a bunch of "void"s in the log file? (FYI: in one of my earlier
posts, I did forget the `invoke` call by mistake. But the lack of logging
in the `void` case was very much deliberate.)

Instead, you should aim for something that clearly and strongly indicates
the *extent* of the problem. Something that's almost irrefutable (and I
should know, since I've been *trying* to refute it ever since I realized
it). Your proposal talks about them a bit, but it focuses on *users* of
them rather than those cases specifically. I really think you should build
your central thesis on these templates:

std::promise and std::future

These are pretty much unbreakable. The `future` type, by its very nature,
must have storage for its value. But, if it doesn't have a value... what
does it store? Which means that you need to change more than just a
function or two.

You have to write the class all over again. Which is of course what the
standard requires.

Oh sure,  you can derive from a common base that contains the work not
related to the value (and you'll be doing that anyway, since you have to
support `R&`). But you have to write four sets of constructors (1 common
base, 3 for the various specializations). You have to write three separate
implementations of your getter function. And so forth.

Something similar goes for `promise`.

While the solution of a common base may mitigate some problems, it makes
maintaining the code more complex. If the interface needs to grow, then you
may need to implement this in 3 cases. You have to test your code against 3
possibilities. And so forth.

At the end of the day, it's a mess. And it's a mess that no language
feature can easily work around. Concepts won't help. `constexpr_if` won't
help. You just have to bite down.

Also, while one could argue that `promise<void>` doesn't make sense,
allowing that specialization also clearly demonstrates the benefits of
`void` regularity. It allows you to have a consistent interface to an
important concept: whether a process has completed. One could try to argue
that we could have had `task` and `promise<NotVoid>` as separate types, but
the only difference between them is that one has a value and the other does
not. In every other way, they'd be identical.

`promise` became a more useful type *because* effort was expended to make
`void` seem regular (that is, as regular as it could be without a language
change).

Examples like those are your best bet here. It almost convinced me that
it's a good idea.

--

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

<div dir=3D"ltr">I think I can help strengthen the motivational case for th=
is feature (despite the fact that I loathe the very concept of it).<br><br>=
I think the logging function is a terrible example, and it should not be th=
e primary focus of the motivation section. Though it is a simple example, i=
t is precisely the simplicity that&#39;s the problem. It&#39;s too easily d=
ismissed, for three reasons:<br><br>1) The required code to support functio=
ns with no return value is, quite frankly, not that hard to write.<br><br>2=
) There are proposed language features that make it even easier to both wri=
te and read.<br><br>3) It raises the question of why a user would want to l=
og `void` returns at all. The function call and it&#39;s parameters, yes. B=
ut does a user <i>really</i> want to see a bunch of &quot;void&quot;s in th=
e log file? (FYI: in one of my earlier posts, I did forget the `invoke` cal=
l by mistake. But the lack of logging in the `void` case was very much deli=
berate.)<br><br>Instead, you should aim for something that clearly and stro=
ngly indicates the <i>extent</i> of the problem. Something that&#39;s almos=
t irrefutable (and I should know, since I&#39;ve been <i>trying</i> to refu=
te it ever since I realized it). Your proposal talks about them a bit, but =
it focuses on <i>users</i> of them rather than those cases specifically. I =
really think you should build your central thesis on these templates:<br><b=
r>std::promise and std::future<br><br>These are pretty much unbreakable. Th=
e `future` type, by its very nature, must have storage for its value. But, =
if it doesn&#39;t have a value... what does it store? Which means that you =
need to change more than just a function or two.<br><br>You have to write t=
he class all over again. Which is of course what the standard requires.<br>=
<br>Oh sure,=C2=A0 you can derive from a common base that contains the work=
 not related to the value (and you&#39;ll be doing that anyway, since you h=
ave to support `R&amp;`). But you have to write four sets of constructors (=
1 common base, 3 for the various specializations). You have to write three =
separate implementations of your getter function. And so forth.<br><br>Some=
thing similar goes for `promise`.<br><br>While the solution of a common bas=
e may mitigate some problems, it makes maintaining the code more complex. I=
f the interface needs to grow, then you may need to implement this in 3 cas=
es. You have to test your code against 3 possibilities. And so forth.<br><b=
r>At the end of the day, it&#39;s a mess. And it&#39;s a mess that no langu=
age feature can easily work around. Concepts won&#39;t help. `constexpr_if`=
 won&#39;t help. You just have to bite down.<br><br>Also, while one could a=
rgue that `promise&lt;void&gt;` doesn&#39;t make sense, allowing that speci=
alization also clearly demonstrates the benefits of `void` regularity. It a=
llows you to have a consistent interface to an important concept: whether a=
 process has completed. One could try to argue that we could have had `task=
` and `promise&lt;NotVoid&gt;` as separate types, but the only difference b=
etween them is that one has a value and the other does not. In every other =
way, they&#39;d be identical.<br><br>`promise` became a more useful type <i=
>because</i> effort was expended to make `void` seem regular (that is, as r=
egular as it could be without a language change).<br><br>Examples like thos=
e are your best bet here. It almost convinced me that it&#39;s a good idea.=
<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_1272_1146980637.1444343682387--
------=_Part_1271_2090014459.1444343682387--

.

--94eb2c0961c45fb6e905219f94da
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 8, 2015 at 3:34 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> I think I can help strengthen the motivational case for this feature
> (despite the fact that I loathe the very concept of it).
>
> I think the logging function is a terrible example, and it should not be
> the primary focus of the motivation section. Though it is a simple example,
> it is precisely the simplicity that's the problem. It's too easily
> dismissed, for three reasons:
>
> 1) The required code to support functions with no return value is, quite
> frankly, not that hard to write.
>
> 2) There are proposed language features that make it even easier to both
> write and read.
>
> 3) It raises the question of why a user would want to log `void` returns
> at all. The function call and it's parameters, yes. But does a user
> *really* want to see a bunch of "void"s in the log file? (FYI: in one of
> my earlier posts, I did forget the `invoke` call by mistake. But the lack
> of logging in the `void` case was very much deliberate.)
>
>


> Instead, you should aim for something that clearly and strongly indicates
> the *extent* of the problem. Something that's almost irrefutable (and I
> should know, since I've been *trying* to refute it ever since I realized
> it). Your proposal talks about them a bit, but it focuses on *users* of
> them rather than those cases specifically. I really think you should build
> your central thesis on these templates:
>
> std::promise and std::future
>
> These are pretty much unbreakable. The `future` type, by its very nature,
> must have storage for its value. But, if it doesn't have a value... what
> does it store? Which means that you need to change more than just a
> function or two.
>
> You have to write the class all over again. Which is of course what the
> standard requires.
>
> Oh sure,  you can derive from a common base that contains the work not
> related to the value (and you'll be doing that anyway, since you have to
> support `R&`). But you have to write four sets of constructors (1 common
> base, 3 for the various specializations). You have to write three separate
> implementations of your getter function. And so forth.
>
> Something similar goes for `promise`.
>
> While the solution of a common base may mitigate some problems, it makes
> maintaining the code more complex. If the interface needs to grow, then you
> may need to implement this in 3 cases. You have to test your code against 3
> possibilities. And so forth.
>
> At the end of the day, it's a mess. And it's a mess that no language
> feature can easily work around. Concepts won't help. `constexpr_if` won't
> help. You just have to bite down.
>
> Also, while one could argue that `promise<void>` doesn't make sense,
> allowing that specialization also clearly demonstrates the benefits of
> `void` regularity. It allows you to have a consistent interface to an
> important concept: whether a process has completed. One could try to argue
> that we could have had `task` and `promise<NotVoid>` as separate types, but
> the only difference between them is that one has a value and the other does
> not. In every other way, they'd be identical.
>
> `promise` became a more useful type *because* effort was expended to make
> `void` seem regular (that is, as regular as it could be without a language
> change).
>
> Examples like those are your best bet here. It almost convinced me that
> it's a good idea.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--94eb2c0961c45fb6e905219f94da
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 T=
hu, Oct 8, 2015 at 3:34 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</sp=
an> 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">I think I can=
 help strengthen the motivational case for this feature (despite the fact t=
hat I loathe the very concept of it).<br><br>I think the logging function i=
s a terrible example, and it should not be the primary focus of the motivat=
ion section. Though it is a simple example, it is precisely the simplicity =
that&#39;s the problem. It&#39;s too easily dismissed, for three reasons:<b=
r><br>1) The required code to support functions with no return value is, qu=
ite frankly, not that hard to write.<br><br>2) There are proposed language =
features that make it even easier to both write and read.<br><br>3) It rais=
es the question of why a user would want to log `void` returns at all. The =
function call and it&#39;s parameters, yes. But does a user <i>really</i> w=
ant to see a bunch of &quot;void&quot;s in the log file? (FYI: in one of my=
 earlier posts, I did forget the `invoke` call by mistake. But the lack of =
logging in the `void` case was very much deliberate.)<br><br></div></blockq=
uote><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr">Instead, you should aim for something that clearly and strongly i=
ndicates the <i>extent</i> of the problem. Something that&#39;s almost irre=
futable (and I should know, since I&#39;ve been <i>trying</i> to refute it =
ever since I realized it). Your proposal talks about them a bit, but it foc=
uses on <i>users</i> of them rather than those cases specifically. I really=
 think you should build your central thesis on these templates:<br><br>std:=
:promise and std::future<br><br>These are pretty much unbreakable. The `fut=
ure` type, by its very nature, must have storage for its value. But, if it =
doesn&#39;t have a value... what does it store? Which means that you need t=
o change more than just a function or two.<br><br>You have to write the cla=
ss all over again. Which is of course what the standard requires.<br><br>Oh=
 sure,=C2=A0 you can derive from a common base that contains the work not r=
elated to the value (and you&#39;ll be doing that anyway, since you have to=
 support `R&amp;`). But you have to write four sets of constructors (1 comm=
on base, 3 for the various specializations). You have to write three separa=
te implementations of your getter function. And so forth.<br><br>Something =
similar goes for `promise`.<br><br>While the solution of a common base may =
mitigate some problems, it makes maintaining the code more complex. If the =
interface needs to grow, then you may need to implement this in 3 cases. Yo=
u have to test your code against 3 possibilities. And so forth.<br><br>At t=
he end of the day, it&#39;s a mess. And it&#39;s a mess that no language fe=
ature can easily work around. Concepts won&#39;t help. `constexpr_if` won&#=
39;t help. You just have to bite down.<br><br>Also, while one could argue t=
hat `promise&lt;void&gt;` doesn&#39;t make sense, allowing that specializat=
ion also clearly demonstrates the benefits of `void` regularity. It allows =
you to have a consistent interface to an important concept: whether a proce=
ss has completed. One could try to argue that we could have had `task` and =
`promise&lt;NotVoid&gt;` as separate types, but the only difference between=
 them is that one has a value and the other does not. In every other way, t=
hey&#39;d be identical.<br><br>`promise` became a more useful type <i>becau=
se</i> effort was expended to make `void` seem regular (that is, as regular=
 as it could be without a language change).<br><br>Examples like those are =
your best bet here. It almost convinced me that it&#39;s a good idea.<br></=
div><div class=3D"HOEnZb"><div class=3D"h5">

<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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

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

--94eb2c0961c45fb6e905219f94da--

.

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

Woops, ignore the previous reply. I somehow accidentally sent immediately.

On Thu, Oct 8, 2015 at 3:34 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> I think I can help strengthen the motivational case for this feature
> (despite the fact that I loathe the very concept of it).
>
> I think the logging function is a terrible example, and it should not be
> the primary focus of the motivation section. Though it is a simple example,
> it is precisely the simplicity that's the problem. It's too easily
> dismissed, for three reasons:
>
> 1) The required code to support functions with no return value is, quite
> frankly, not that hard to write.
>
> 2) There are proposed language features that make it even easier to both
> write and read.
>
> 3) It raises the question of why a user would want to log `void` returns
> at all. The function call and it's parameters, yes. But does a user
> *really* want to see a bunch of "void"s in the log file? (FYI: in one of
> my earlier posts, I did forget the `invoke` call by mistake. But the lack
> of logging in the `void` case was very much deliberate.)
>

If you have a suggestion for a different example, then I'm open to it
assuming this manages to make it to another revision, though if it makes it
that far, I imagine that the motivation will have been recognized as
sufficient, so it might end up being moot.

FWIW I do explicitly explain why logging the result is important directly
in the proposal, and I think of the subtlty as a part of its strength (in
the real world code that this is based on, I too initially started with a
solution that didn't "log" the void result, just as you did). The
serialization of "void" can even be a no-op, so it has no implications of
occupying storage in a log. The reason you generally still want the
function to be called is that "log_result" not only serializes the value,
but the fact that it is called at all signifies that there *was* a result
(as in, an exception didn't propagate and there wasn't some other form of
termination when invoking the function that we are logging).

I also really wanted at least one example that is separate from the
standard library just to make it clear that this is something that everyday
users face and not just standard library implementors. Maybe there's a
better example than logging, but it is one of the real world scenarios I've
encountered, and I'd like at least something separate from what might be
considered an implementation curiosity of the standard library.

On Thu, Oct 8, 2015 at 3:34 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> std::promise and std::future
>
> These are pretty much unbreakable. The `future` type, by its very nature,
> must have storage for its value. But, if it doesn't have a value... what
> does it store? Which means that you need to change more than just a
> function or two.
>
> You have to write the class all over again. Which is of course what the
> standard requires.
>
> Oh sure,  you can derive from a common base that contains the work not
> related to the value (and you'll be doing that anyway, since you have to
> support `R&`). But you have to write four sets of constructors (1 common
> base, 3 for the various specializations). You have to write three separate
> implementations of your getter function. And so forth.
>
> Something similar goes for `promise`.
>
> While the solution of a common base may mitigate some problems, it makes
> maintaining the code more complex. If the interface needs to grow, then you
> may need to implement this in 3 cases. You have to test your code against 3
> possibilities. And so forth.
>
> At the end of the day, it's a mess. And it's a mess that no language
> feature can easily work around. Concepts won't help. `constexpr_if` won't
> help. You just have to bite down.
>

Right, and this proposal would solve that problem. I suppose I could have
focused more time explicitly on this and other examples, but it was
somewhat last minute (down to the hour) and I decided to focus more effort
on the issues with alternative suggested solutions (I anticipated that some
of those alternatives would come up in discussion, as they did in this
group, so it made sense to have an analysis of some of them upfront). I
assumed that those in the committee would immediately relate to the
std::promise/std::future issue, but I suppose that might not be a correct
assumption. I have a partially written paper specifically about
std::promise/std::future and other standard library changes that would
accompany this change, and I was hoping to submit it at the same time as
this proposal, but it would have taken too much time to complete and would
be something of a wasted effort if the overall idea were shot down at the
language level, anyway.

On Thu, Oct 8, 2015 at 3:34 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> Examples like those are your best bet here. It almost convinced me that
> it's a good idea.
>

Well that's a good sign, at least :)

--

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

--001a1137bdd0ed5f4405219ff266
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">Woop=
s, ignore the previous reply. I somehow accidentally sent immediately.</div=
><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">On Thu, Oc=
t 8, 2015 at 3:34 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto:j=
mckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span> wr=
ote:<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);border-left-style=
:solid;padding-left:1ex"><div dir=3D"ltr">I think I can help strengthen the=
 motivational case for this feature (despite the fact that I loathe the ver=
y concept of it).<br><br>I think the logging function is a terrible example=
, and it should not be the primary focus of the motivation section. Though =
it is a simple example, it is precisely the simplicity that&#39;s the probl=
em. It&#39;s too easily dismissed, for three reasons:<br><br>1) The require=
d code to support functions with no return value is, quite frankly, not tha=
t hard to write.<br><br>2) There are proposed language features that make i=
t even easier to both write and read.<br><br>3) It raises the question of w=
hy a user would want to log `void` returns at all. The function call and it=
&#39;s parameters, yes. But does a user <i>really</i> want to see a bunch o=
f &quot;void&quot;s in the log file? (FYI: in one of my earlier posts, I di=
d forget the `invoke` call by mistake. But the lack of logging in the `void=
` case was very much deliberate.)<br></div></blockquote><div><br></div><div=
>If you have a suggestion for a different example, then I&#39;m open to it =
assuming this manages to make it to another revision, though if it makes it=
 that far, I imagine that the motivation will have been recognized as suffi=
cient, so it might end up being moot.</div><div><br></div><div>FWIW I do ex=
plicitly explain why logging the result is important directly in the propos=
al, and I think of the subtlty as a part of its strength (in the real world=
 code that this is based on, I too initially started with a solution that d=
idn&#39;t &quot;log&quot; the void result, just as you did). The serializat=
ion of &quot;void&quot; can even be a no-op, so it has no implications of o=
ccupying storage in a log. The reason you generally still want the function=
 to be called is that &quot;log_result&quot; not only serializes the value,=
 but the fact that it is called at all signifies that there <i>was</i>=C2=
=A0a result (as in, an exception didn&#39;t propagate and there wasn&#39;t =
some other form of termination when invoking the function that we are loggi=
ng).</div><div><br></div><div>I also really wanted at least one example tha=
t is separate from the standard library just to make it clear that this is =
something that everyday users face and not just standard library implemento=
rs. Maybe there&#39;s a better example than logging, but it is one of the r=
eal world scenarios I&#39;ve encountered, and I&#39;d like at least somethi=
ng separate from what might be considered an implementation curiosity of th=
e standard library.</div><div><br></div><div>On Thu, Oct 8, 2015 at 3:34 PM=
, Nicol Bolas=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.=
com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span>=C2=A0wrote:</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">std::promise and std::future<br><br>These=
 are pretty much unbreakable. The `future` type, by its very nature, must h=
ave storage for its value. But, if it doesn&#39;t have a value... what does=
 it store? Which means that you need to change more than just a function or=
 two.<br><br>You have to write the class all over again. Which is of course=
 what the standard requires.<br><br>Oh sure,=C2=A0 you can derive from a co=
mmon base that contains the work not related to the value (and you&#39;ll b=
e doing that anyway, since you have to support `R&amp;`). But you have to w=
rite four sets of constructors (1 common base, 3 for the various specializa=
tions). You have to write three separate implementations of your getter fun=
ction. And so forth.<br><br>Something similar goes for `promise`.<br><br>Wh=
ile the solution of a common base may mitigate some problems, it makes main=
taining the code more complex. If the interface needs to grow, then you may=
 need to implement this in 3 cases. You have to test your code against 3 po=
ssibilities. And so forth.<br><br>At the end of the day, it&#39;s a mess. A=
nd it&#39;s a mess that no language feature can easily work around. Concept=
s won&#39;t help. `constexpr_if` won&#39;t help. You just have to bite down=
..<br></div></blockquote><div><br></div><div>Right, and this proposal would =
solve that problem. I suppose I could have focused more time explicitly on =
this and other examples, but it was somewhat last minute (down to the hour)=
 and I decided to focus more effort on the issues with alternative suggeste=
d solutions (I anticipated that some of those alternatives would come up in=
 discussion, as they did in this group, so it made sense to have an analysi=
s of some of them upfront). I assumed that those in the committee would imm=
ediately relate to the std::promise/std::future issue, but I suppose that m=
ight not be a correct assumption. I have a partially written paper specific=
ally about std::promise/std::future and other standard library changes that=
 would accompany this change, and I was hoping to submit it at the same tim=
e as this proposal, but it would have taken too much time to complete and w=
ould be something of a wasted effort if the overall idea were shot down at =
the language level, anyway.</div><div><br></div><div>On Thu, Oct 8, 2015 at=
 3:34 PM, Nicol Bolas=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:jmckesso=
n@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span>=C2=A0wrot=
e:=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><div dir=3D"ltr">Examples like those are you=
r best bet here. It almost convinced me that it&#39;s a good idea.</div></b=
lockquote><div><br></div><div>Well that&#39;s a good sign, at least :)=C2=
=A0<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 />

--001a1137bdd0ed5f4405219ff266--

.

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

On Mon, Oct 5, 2015 at 11:43 AM, Matt Calabrese <calabrese@google.com>
wrote:

> Following the "Allow values of void" discussion, I've put together a
> proposal[1] for updating void to be a Regular type.
>

Here are some drafts for library changes, assuming the Regular Void
proposal is considered viable and worthwhile:

Remove Future-Related Explicit Specializations for Void:
https://googledrive.com/host/0B66ERk4C7uoQSXRienRLZDNnaUE
Standard Input and Output Support for Void:
https://googledrive.com/host/0B66ERk4C7uoQT01OLXVVSVF4UFE
std::hash Specialization for Void:
https://googledrive.com/host/0B66ERk4C7uoQOVlGa0N3U2U0bkk

--

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

--001a11c2578ac0b129052200931e
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, Oct 5, 2015 at 11:43 AM, Matt Calabrese <span dir=3D"ltr">&lt;<a href=
=3D"mailto:calabrese@google.com" target=3D"_blank">calabrese@google.com</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);bor=
der-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>Following the =
&quot;Allow values of void&quot; discussion, I&#39;ve put together a propos=
al[1] for updating void to be a Regular type.</div></div></blockquote><div>=
<br></div><div>Here are some drafts for library changes, assuming the Regul=
ar Void proposal is considered viable and worthwhile:</div><div><br></div><=
div>Remove Future-Related Explicit Specializations for Void: <a href=3D"htt=
ps://googledrive.com/host/0B66ERk4C7uoQSXRienRLZDNnaUE">https://googledrive=
..com/host/0B66ERk4C7uoQSXRienRLZDNnaUE</a></div></div></div>Standard Input =
and Output Support for Void: <a href=3D"https://googledrive.com/host/0B66ER=
k4C7uoQT01OLXVVSVF4UFE">https://googledrive.com/host/0B66ERk4C7uoQT01OLXVVS=
VF4UFE</a><div>std::hash Specialization for Void: <a href=3D"https://google=
drive.com/host/0B66ERk4C7uoQOVlGa0N3U2U0bkk">https://googledrive.com/host/0=
B66ERk4C7uoQOVlGa0N3U2U0bkk</a><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 />

--001a11c2578ac0b129052200931e--

.