Topic: Revised std::recover proposal (D0042)
Author: David Krauss <potswa@gmail.com>
Date: Wed, 23 Sep 2015 13:50:01 +0800
Raw View
--Apple-Mail=_70A9232F-9FFB-4263-B95B-C8951BB98A0D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
I=E2=80=99ve made a lot of changes to the proposal, std::re=E2=80=8Ccover: =
undoing type erasure.
1. The noexcept overload is given its own name try_recover, and it returns =
an unspecified nullable reference type, not a raw pointer, so as to propaga=
te value category.
2. Raw pointers to polymorphic type are valid inputs (again). EWG might not=
e that =E2=80=9Cthis function disregards base class access qualification an=
d tolerates base class ambiguity.=E2=80=9D This little-known aspect of dyna=
mic_cast<void*> gets a lot more exposure when encapsulated by recover.
3. There=E2=80=99s a fallback for classes that can=E2=80=99t retrieve a voi=
d* without first being given the type. (This was actually added a while ago=
..)
=E2=80=A6 and many small changes. What was supposed to be a quickie now wei=
ghs in at 13 pages.
I=E2=80=99m being a bit of a cowboy with the code examples; I=E2=80=99ve no=
t compiled any of it since the earlier prototyping. Unfortunately I=E2=80=
=99m starting to get a little rushed. All review and feedback continues to =
be much appreciated!
PDF: bit.ly/reccast <http://bit.ly/reccast>
--=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=_70A9232F-9FFB-4263-B95B-C8951BB98A0D
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""><div class=3D"">I=
=E2=80=99ve made a lot of changes to the proposal, <i class=3D""><font face=
=3D"Courier" class=3D"">std::re=E2=80=8Ccover</font>: undoing type erasure<=
/i>.</div><div class=3D""><br class=3D""></div><div class=3D"">1. The <font=
face=3D"Courier" class=3D"">noexcept</font> overload is given its own name=
<font face=3D"Courier" class=3D"">try_recover</font>, and it returns an un=
specified nullable reference type, not a raw pointer, so as to propagate va=
lue category.</div><div class=3D""><br class=3D""></div><div class=3D"">2. =
Raw pointers to polymorphic type are valid inputs (again). EWG might note t=
hat =E2=80=9Cthis function disregards base class access qualification and t=
olerates base class ambiguity.=E2=80=9D This little-known aspect of <font f=
ace=3D"Courier" class=3D"">dynamic_cast<void*></font> gets a lot more=
exposure when encapsulated by <font face=3D"Courier" class=3D"">recover</f=
ont>.</div><div class=3D""><br class=3D""></div><div class=3D"">3. There=E2=
=80=99s a fallback for classes that can=E2=80=99t retrieve a <font face=3D"=
Courier" class=3D"">void*</font> without first being given the type. (This =
was actually added a while ago.)</div><div class=3D""><br class=3D""></div>=
<div class=3D"">=E2=80=A6 and many small changes. What was supposed to be a=
quickie now weighs in at 13 pages.</div><div class=3D""><br class=3D""></d=
iv><div class=3D"">I=E2=80=99m being a bit of a cowboy with the code exampl=
es; I=E2=80=99ve not compiled any of it since the earlier prototyping. Unfo=
rtunately I=E2=80=99m starting to get a little rushed. All review and feedb=
ack continues to be much appreciated!</div><div class=3D""><br class=3D""><=
/div><div class=3D"">PDF: <a href=3D"http://bit.ly/reccast" class=3D"">bit.=
ly/reccast</a></div><div class=3D""><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" 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=_70A9232F-9FFB-4263-B95B-C8951BB98A0D--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 23 Sep 2015 09:06:05 +0200
Raw View
Le 23/09/15 07:50, David Krauss a =C3=A9crit :
> I=E2=80=99ve made a lot of changes to the proposal, std::re=E2=80=8Ccover=
: undoing type erasure.
>
> 1. The noexcept overload is given its own name try_recover, and it return=
s an unspecified nullable reference type, not a raw pointer, so as to propa=
gate value category.
Hi David, thanks for adding try_recover and reducing function provided=20
to the minimum bool(r) and *r. This is clearly easier to implement than=20
optional<T&>. For symmetry (defining operator*() should imply he=20
definition of operator->) I would add also operator->().
> 2. Raw pointers to polymorphic type are valid inputs (again). EWG might n=
ote that =E2=80=9Cthis function disregards base class access qualification =
and tolerates base class ambiguity.=E2=80=9D This little-known aspect of dy=
namic_cast<void*> gets a lot more exposure when encapsulated by recover.
>
> 3. There=E2=80=99s a fallback for classes that can=E2=80=99t retrieve a v=
oid* without first being given the type. (This was actually added a while a=
go.)
and also adding this case, even if as you know I would prefer that the=20
customization non-member function address_of<T>(s) and verify_type<T>(s).
>
> =E2=80=A6 and many small changes. What was supposed to be a quickie now w=
eighs in at 13 pages.
>
> I=E2=80=99m being a bit of a cowboy with the code examples; I=E2=80=99ve =
not compiled any of it since the earlier prototyping. Unfortunately I=E2=80=
=99m starting to get a little rushed. All review and feedback continues to =
be much appreciated!
>
> PDF: bit.ly/reccast <http://bit.ly/reccast>
>
>
I will surely remove from my proposal on homogeneous interface for=20
variant, any, optional the access part and make reference to your proposal.
I'm all for the Further work section. The constexpr issue seems to be a=20
real one and should be fixed before adoption, isn't it? Wouldn't =20
address_of<T> fix it?
I will try to re-read the whole paper this evening.
Thanks again,
Vicente
--=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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 23 Sep 2015 15:19:44 +0800
Raw View
--Apple-Mail=_75ABA2AE-2522-4654-A318-57FC9B38F075
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9309=E2=80=9323, at 3:06 PM, Vicente J. Botet Escriba <vice=
nte.botet@wanadoo.fr> wrote:
>=20
> Hi David, thanks for adding try_recover and reducing function provided to=
the minimum bool(r) and *r. This is clearly easier to implement than optio=
nal<T&>. For symmetry (defining operator*() should imply he definition of o=
perator->) I would add also operator->().
Agreed, but I think it=E2=80=99s outside the scope of the proposal. Ideally=
, whatever type is chosen by the library implementer should be useful in ge=
neral. I never even said it was MoveConstructible.
> I'm all for the Further work section. The constexpr issue seems to be a r=
eal one and should be fixed before adoption, isn't it? Wouldn't address_of=
<T> fix it?
It would be nice, but I=E2=80=99m not holding my breath. I don=E2=80=99t se=
e how address_of helps.
> I will try to re-read the whole paper this evening.
Continued thanks!
--=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=_75ABA2AE-2522-4654-A318-57FC9B38F075
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 2015=E2=80=9309=
=E2=80=9323, at 3:06 PM, Vicente J. Botet Escriba <<a href=3D"mailto:vic=
ente.botet@wanadoo.fr" class=3D"">vicente.botet@wanadoo.fr</a>> wrote:</=
div><br class=3D"Apple-interchange-newline"><div class=3D"">Hi David, thank=
s for adding try_recover and reducing function provided to the minimum bool=
(r) and *r. This is clearly easier to implement than optional<T&>=
.. For symmetry (defining operator*() should imply he definition of operator=
->) I would add also operator->().<br class=3D""></div></blockquote><=
div><br class=3D""></div><div>Agreed, but I think it=E2=80=99s outside the =
scope of the proposal. Ideally, whatever type is chosen by the library impl=
ementer should be useful in general. I never even said it was MoveConstruct=
ible.</div><br class=3D""><blockquote type=3D"cite" class=3D""><div class=
=3D"">I'm all for the Further work section. The constexpr issue seems to be=
a real one and should be fixed before adoption, isn't it? Wouldn't a=
ddress_of<T> fix it?<br class=3D""></div></blockquote><div><br class=
=3D""></div><div>It would be nice, but I=E2=80=99m not holding my breath. I=
don=E2=80=99t see how <font face=3D"Courier" class=3D"">address_of</font> =
helps.</div><br class=3D""><blockquote type=3D"cite" class=3D""><div class=
=3D"">I will try to re-read the whole paper this evening.<br class=3D""></d=
iv></blockquote></div><br class=3D""><div class=3D"">Continued thanks!</div=
><div class=3D""><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" 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=_75ABA2AE-2522-4654-A318-57FC9B38F075--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 23 Sep 2015 22:30:54 +0200
Raw View
This is a multi-part message in MIME format.
--------------080007020908010606070209
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 23/09/15 09:19, David Krauss a =C3=A9crit :
>> On 2015=E2=80=9309=E2=80=9323, at 3:06 PM, Vicente J. Botet Escriba <vic=
ente.botet@wanadoo.fr> wrote:
>>
>> Hi David, thanks for adding try_recover and reducing function provided t=
o the minimum bool(r) and *r. This is clearly easier to implement than opti=
onal<T&>. For symmetry (defining operator*() should imply he definition of =
operator->) I would add also operator->().
> Agreed, but I think it=E2=80=99s outside the scope of the proposal. Ideal=
ly, whatever type is chosen by the library implementer should be useful in =
general. I never even said it was MoveConstructible.
I'm not saying to change the type as it is unspecified, I'm just saying=20
that this unspecified type should define operator->() because it defines=20
operator*().
>
>> I'm all for the Further work section. The constexpr issue seems to be a =
real one and should be fixed before adoption, isn't it? Wouldn't address_o=
f<T> fix it?
> It would be nice, but I=E2=80=99m not holding my breath. I don=E2=80=99t =
see how address_of helps.
I don't master constexpr, but you say in the paper "recover cannot be=20
constexpr as it relies on casting from void* to object type". So if the=20
customization function address_of<T> returns T*, you should avoid the=20
cast from void*. As I said I don't know where the constexpr problem is.
Are you saying that the recover for real type erased types as std::any=20
and std::function can not be constexpr?
However you have declared them as constexpr.
I have some questions about possible customizations or ErasureClass.
How std::experimental::optional<T> will be customized? What could be the=20
result of verify_type<nullopt_t>(o)?
What could be the result of the recover<nullopt_t>(o)?
For optional, we want nullopt_t as an alternative type for the sum type=20
nullopt_t + T.
What could be the result of the bool(try_recover<nullopt_t>(o))?
if (try_recover<nullopt_t>(o)) ...
Hrr, this is weird. We are checking if o is disengaged. I'm wondering if=20
we don't need to split the alternatives into two separated sets, the=20
success alternatives and the failure alternatives. And that the types=20
that can be used with the ErasureClass must be only success alternatives.
And for expected<T, error_code>? What could be the result of=20
verify_type<error_code>(e)?
What could be the result of the bool(try_recover<error_code>(o))?
variant<Ts...> has always a value or is invalid, so there is no=20
not-a-type associated to it. However std::any and std::function<> could=20
have one not-a-type, see P0032 where I propose std::none_t as the type=20
that means that there is nothing on std::any. I have not think about=20
function.
How the customization could change the exception to throw?
Another class to consider for customization could be exception_ptr. It=20
would be interesting to identify if std::future can be adapted to the=20
concept and how. What could be the result of=20
verify_type<exception_ptr>(fut)?
Vicente
--=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/.
--------------080007020908010606070209
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">
<div class=3D"moz-cite-prefix">Le 23/09/15 09:19, David Krauss a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:CF402E04-F3D6-4D18-931C-60DC7F66445A@gmail.com"
type=3D"cite">
<pre wrap=3D"">
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">On 2015=E2=80=9309=E2=80=9323, at 3:06 PM, Vicente J=
.. Botet Escriba <a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:vicente.b=
otet@wanadoo.fr"><vicente.botet@wanadoo.fr></a> wrote:
Hi David, thanks for adding try_recover and reducing function provided to t=
he minimum bool(r) and *r. This is clearly easier to implement than optiona=
l<T&>. For symmetry (defining operator*() should imply he definit=
ion of operator->) I would add also operator->().
</pre>
</blockquote>
<pre wrap=3D"">
Agreed, but I think it=E2=80=99s outside the scope of the proposal. Ideally=
, whatever type is chosen by the library implementer should be useful in ge=
neral. I never even said it was MoveConstructible.</pre>
</blockquote>
I'm not saying to change the type as it is unspecified, I'm just
saying that this unspecified type should define operator->()
because it defines operator*().<br>
<blockquote
cite=3D"mid:CF402E04-F3D6-4D18-931C-60DC7F66445A@gmail.com"
type=3D"cite">
<pre wrap=3D"">
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">I'm all for the Further work section. The constexpr =
issue seems to be a real one and should be fixed before adoption, isn't it?=
Wouldn't address_of<T> fix it?
</pre>
</blockquote>
<pre wrap=3D"">
It would be nice, but I=E2=80=99m not holding my breath. I don=E2=80=99t se=
e how address_of helps.
</pre>
</blockquote>
I don't master constexpr, but you say in the paper "recover cannot
be constexpr as it relies on casting from void* to object type". So
if the customization function address_of<T> returns T*, you
should avoid the cast from void*. As I said I don't know where the
constexpr problem is. <br>
<br>
Are you saying that the recover for real type erased types as
std::any and std::function can not be constexpr?<br>
However you have declared them as constexpr.<br>
<br>
<blockquote
cite=3D"mid:CF402E04-F3D6-4D18-931C-60DC7F66445A@gmail.com"
type=3D"cite">
<pre wrap=3D"">
</pre>
</blockquote>
<font size=3D"+1"><br>
I have some questions about possible customizations or
ErasureClass.<br>
<br>
How std::experimental::optional<T> will be customized? What
could be the result of verify_type<nullopt_t>(o)?<br>
What could be the result of the recover<nullopt_t>(o)?<br>
For optional, we want nullopt_t as an alternative type for the sum
type nullopt_t + T.<br>
What could be the result of the
bool(try_recover<nullopt_t>(o))?<br>
<br>
=C2=A0=C2=A0=C2=A0 if (try_recover<nullopt_t>(o)) ...<br>
=C2=A0<br>
Hrr, this is weird. We are checking if o is disengaged. I'm
wondering if we don't need to split the alternatives into two
separated sets, the success alternatives and the failure
alternatives. And that the types that can be used with the
ErasureClass must be only success alternatives.<br>
<br>
And for expected<T, error_code>? What could be the result of
verify_type<error_code>(e)?<br>
What could be the result of the
bool(try_recover<error_code>(o))?<br>
<br>
variant<Ts...> has always a value or is invalid, so there is
no not-a-type associated to it. However std::any and
std::function<> could have one not-a-type, see P0032 where I
propose std::none_t as the type that means that there is nothing
on std::any. I have not think about function.<br>
<br>
How the customization could change the exception to throw?<br>
<br>
Another class to consider for customization could be
exception_ptr. It would be interesting to identify if std::future
can be adapted to the concept and how. What could be the result of
verify_type<exception_ptr>(fut)?<br>
<br>
Vicente</font><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" 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 />
--------------080007020908010606070209--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 23 Sep 2015 16:31:01 -0400
Raw View
--001a11c223aa2a1bc305206ffe18
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Sep 23, 2015 at 1:50 AM, David Krauss <potswa@gmail.com> wrote:
> I=E2=80=99ve made a lot of changes to the proposal, *std::re=E2=80=8Ccove=
r: undoing type
> erasure*.
>
> 1. The noexcept overload is given its own name try_recover, and it
> returns an unspecified nullable reference type, not a raw pointer, so as =
to
> propagate value category.
>
> 2. Raw pointers to polymorphic type are valid inputs (again). EWG might
> note that =E2=80=9Cthis function disregards base class access qualificati=
on and
> tolerates base class ambiguity.=E2=80=9D This little-known aspect of
> dynamic_cast<void*> gets a lot more exposure when encapsulated by recover=
..
>
> 3. There=E2=80=99s a fallback for classes that can=E2=80=99t retrieve a v=
oid* without
> first being given the type. (This was actually added a while ago.)
>
> =E2=80=A6 and many small changes. What was supposed to be a quickie now w=
eighs in
> at 13 pages.
>
> I=E2=80=99m being a bit of a cowboy with the code examples; I=E2=80=99ve =
not compiled any
> of it since the earlier prototyping. Unfortunately I=E2=80=99m starting t=
o get a
> little rushed. All review and feedback continues to be much appreciated!
>
> PDF: bit.ly/reccast
>
>
Tiny nit: for your optional implementation you say "Assignment is
implemented as disengagement and reengagement, hence references are
supported." The 'hence' sounds like that's the only way to support
references. (I don't think it is, nor do I think it is the right way.)
Obviously not very pertinent to the point of the paper, but it just tripped
me up.
Tony
--=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
> 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/.
>
--=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/.
--001a11c223aa2a1bc305206ffe18
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, Sep 23, 2015 at 1:50 AM, David Krauss <span dir=3D"ltr"><<a =
href=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>>=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div st=
yle=3D"word-wrap:break-word"><div>I=E2=80=99ve made a lot of changes to the=
proposal, <i><font face=3D"Courier">std::re=E2=80=8Ccover</font>: undoing =
type erasure</i>.</div><div><br></div><div>1. The <font face=3D"Courier">no=
except</font> overload is given its own name <font face=3D"Courier">try_rec=
over</font>, and it returns an unspecified nullable reference type, not a r=
aw pointer, so as to propagate value category.</div><div><br></div><div>2. =
Raw pointers to polymorphic type are valid inputs (again). EWG might note t=
hat =E2=80=9Cthis function disregards base class access qualification and t=
olerates base class ambiguity.=E2=80=9D This little-known aspect of <font f=
ace=3D"Courier">dynamic_cast<void*></font> gets a lot more exposure w=
hen encapsulated by <font face=3D"Courier">recover</font>.</div><div><br></=
div><div>3. There=E2=80=99s a fallback for classes that can=E2=80=99t retri=
eve a <font face=3D"Courier">void*</font> without first being given the typ=
e. (This was actually added a while ago.)</div><div><br></div><div>=E2=80=
=A6 and many small changes. What was supposed to be a quickie now weighs in=
at 13 pages.</div><div><br></div><div>I=E2=80=99m being a bit of a cowboy =
with the code examples; I=E2=80=99ve not compiled any of it since the earli=
er prototyping. Unfortunately I=E2=80=99m starting to get a little rushed. =
All review and feedback continues to be much appreciated!</div><div><br></d=
iv><div>PDF: <a href=3D"http://bit.ly/reccast" target=3D"_blank">bit.ly/rec=
cast</a></div><span class=3D""><font color=3D"#888888"><div><br></div></fon=
t></span></div></blockquote><div><br></div><div>Tiny nit: for your optional=
implementation you say "Assignment is implemented as disengagement an=
d reengagement, hence references are supported."=C2=A0 The 'hence&=
#39; sounds like that's the only way to support references.=C2=A0 (I do=
n't think it is, nor do I think it is the right way.)<br></div><div>Obv=
iously not very pertinent to the point of the paper, but it just tripped me=
up.<br><br></div><div>Tony<br><br> </div><blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex"><div style=3D"word-wrap:break-word"><span class=3D""><font=
color=3D"#888888"><div></div></font></span></div><span class=3D""><font co=
lor=3D"#888888">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
</font></span></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" 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 />
--001a11c223aa2a1bc305206ffe18--
.