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

Here's a bit of a brain-dump; sorry I don't have time to organize it more:

logical_const is effectively a smart pointer, but it's missing some
important pieces of standard smart-pointer functionality. For example, it
doesn't work with std::pointer_traits, and it doesn't provide an explicit
operator bool, or operator[].

It would be helpful to SFINAE out the const T& and const logical_const<T>&
constructors when their argument types are not copy-constructible, so that
std::is_copy_constructible gives the right answers for logical_const. In
fairness, though, a lot of std:: types fail to do this.

I'm not entirely sure about constructions like "&*t" and the methods that
use them; there could be exotic smart pointers whose operator* returns a
proxy object, so you might need to explicitly convert to Value_T& before
taking the address, and you might need to use std::addressof() instead of
"&". Relatedly, you should think carefully about how logical_const will
work with unique_ptr in the case where unique_ptr::pointer is another smart
pointer: for example, should get() and operator->() return plain pointers,
or should they return whatever the corresponding members of T return, or
should they actually return T? I'm actually inclined toward that last
option, but whatever your answer is, it's worth explicitly discussing in
the paper. It would also be nice to provide a reset() member. However, this
raises the same issue: does it take a plain pointer, or whatever T::reset()
takes, or does it take T?

An implicit conversion operator is not how I'd expect to get access to the
wrapped pointer. This is not only surprising, it's inconvenient (accessing
the wrapped pointer will typically require me to name its type, which may
be quite verbose), and potentially hazardous (implicit conversions often
get invoked in surprising ways). This is one reason I think get() should
probably return T, but even if you disagree, you should discuss the design
tradeoffs here.

Should logical_const<T> have a constructor and assignment operator taking
logical_const<U>, where U is implicitly convertible to T? This is often
important for smart pointers, so that they can provide the same implicit
conversions as raw pointers (e.g. const-qualification, pointer-to-derived
to pointer-to-base). Similarly, should it have a constructor and assignment
operator taking nullptr_t? nullptr_t will normally be implicitly
convertible to T, so the existing constructors mostly do the job, but they
don't allow nullptr_t to be implicitly convertible to logical_const<T>.
Generalizing the above, what should logical_const<T> be constructible and
assignable from? There's an at least superficially plausible case to be
made that it should behave as much as possible like the T, so it should be
constructible and assignable from anything T is (and maybe from
logical_const-wrapped versions of any of those?). In fact, taking this view
to the extreme, should logical_const<T> _inherit_ from T, when T is a class
type?



On Thu, Apr 24, 2014 at 11:05 AM, Jonathan Coe <jonathanbcoe@gmail.com>wrote:

> link as requested by Geoffrey Romer:
>
>
> https://googledrive.com/host/0B5BUDfRWFDPvNGNsWmRJZFp1YU0/logical_const.html
>
>
>
> On Thursday, April 24, 2014 6:47:43 PM UTC+1, Jonathan Coe wrote:
>
>> Following discussion on the BSI and c++std-lib mailing lists I propose an
>> addition to the C++ Standard Library to make logical const-ness easy to
>> implement and easy to spot in code review:
>>
>> https://drive.google.com/file/d/0B5BUDfRWFDPva1pOM0tyR1FRWFk/
>> edit?usp=sharing
>>
>> All thoughts are welcome.
>>
>> Kind regards,
>>
>> Jonathan Coe
>>
>  --
>
> ---
> 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/.

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

<div dir=3D"ltr"><div>Here&#39;s a bit of a brain-dump; sorry I don&#39;t h=
ave time to organize it more:</div><div><br></div><div>logical_const is eff=
ectively a smart pointer, but it&#39;s missing some important pieces of sta=
ndard smart-pointer functionality. For example, it doesn&#39;t work with st=
d::pointer_traits, and it doesn&#39;t provide an explicit operator bool, or=
 operator[].</div>

<div><br></div><div>It would be helpful to SFINAE out the const T&amp; and =
const logical_const&lt;T&gt;&amp; constructors when their argument types ar=
e not copy-constructible, so that std::is_copy_constructible gives the righ=
t answers for logical_const. In fairness, though, a lot of std:: types fail=
 to do this.</div>

<div><br></div><div>I&#39;m not entirely sure about constructions like &quo=
t;&amp;*t&quot; and the methods that use them; there could be exotic smart =
pointers whose operator* returns a proxy object, so you might need to expli=
citly convert to Value_T&amp; before taking the address, and you might need=
 to use std::addressof() instead of &quot;&amp;&quot;. Relatedly, you shoul=
d think carefully about how logical_const will work with unique_ptr in the =
case where unique_ptr::pointer is another smart pointer: for example, shoul=
d get() and operator-&gt;() return plain pointers, or should they return wh=
atever the corresponding members of T return, or should they actually retur=
n T? I&#39;m actually inclined toward that last option, but whatever your a=
nswer is, it&#39;s worth explicitly discussing in the paper. It would also =
be nice to provide a reset() member. However, this raises the same issue: d=
oes it take a plain pointer, or whatever T::reset() takes, or does it take =
T?</div>
<div><br></div><div>An implicit conversion operator is not how I&#39;d expe=
ct to get access to the wrapped pointer. This is not only surprising, it&#3=
9;s inconvenient (accessing the wrapped pointer will typically require me t=
o name its type, which may be quite verbose), and potentially hazardous (im=
plicit conversions often get invoked in surprising ways). This is one reaso=
n I think get() should probably return T, but even if you disagree, you sho=
uld discuss the design tradeoffs here.<br>
<div><br></div><div>Should logical_const&lt;T&gt; have a constructor and as=
signment operator taking logical_const&lt;U&gt;, where U is implicitly conv=
ertible to T? This is often important for smart pointers, so that they can =
provide the same implicit conversions as raw pointers (e.g. const-qualifica=
tion, pointer-to-derived to pointer-to-base). Similarly, should it have a c=
onstructor and assignment operator taking nullptr_t? nullptr_t will normall=
y be implicitly convertible to T, so the existing constructors mostly do th=
e job, but they don&#39;t allow nullptr_t to be implicitly convertible to l=
ogical_const&lt;T&gt;. Generalizing the above, what should logical_const&lt=
;T&gt; be constructible and assignable from? There&#39;s an at least superf=
icially plausible case to be made that it should behave as much as possible=
 like the T, so it should be constructible and assignable from anything T i=
s (and maybe from logical_const-wrapped versions of any of those?). In fact=
, taking this view to the extreme, should logical_const&lt;T&gt; _inherit_ =
from T, when T is a class type?</div>
<div><div><br></div></div></div></div><div class=3D"gmail_extra"><br><br><d=
iv class=3D"gmail_quote">On Thu, Apr 24, 2014 at 11:05 AM, Jonathan Coe <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:jonathanbcoe@gmail.com" target=3D"_bla=
nk">jonathanbcoe@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">link as requested by Geoffr=
ey Romer:<div><br></div><div><a href=3D"https://googledrive.com/host/0B5BUD=
fRWFDPvNGNsWmRJZFp1YU0/logical_const.html" target=3D"_blank">https://google=
drive.com/host/0B5BUDfRWFDPvNGNsWmRJZFp1YU0/logical_const.html</a></div>
<div><br></div><div><div class=3D""><br><br>On Thursday, April 24, 2014 6:4=
7:43 PM UTC+1, Jonathan Coe wrote:</div><div><div class=3D"h5"><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>Following discussion on the BSI and c++std-lib mailin=
g lists I propose an addition to the C++ Standard Library to make logical c=
onst-ness easy to implement and easy to spot in code review:</div><div><br>
</div><div><a href=3D"https://drive.google.com/file/d/0B5BUDfRWFDPva1pOM0ty=
R1FRWFk/edit?usp=3Dsharing" target=3D"_blank">https://drive.google.com/file=
/<u></u>d/<u></u>0B5BUDfRWFDPva1pOM0tyR1FRWFk/<u></u>edit?usp=3Dsharing</a>=
<br>
</div><div><br></div><div>All thoughts are welcome.</div><div><br></div><di=
v>Kind regards,</div><div><br></div><div>Jonathan Coe</div></div></blockquo=
te></div></div></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>

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

--001a11c2ef805208f004f7cfda4e--

.

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

On Thu, Apr 24, 2014 at 1:39 PM, Geoffrey Romer <gromer@google.com> wrote:

> Here's a bit of a brain-dump; sorry I don't have time to organize it more:
>
> logical_const is effectively a smart pointer, but it's missing some
> important pieces of standard smart-pointer functionality. For example, it
> doesn't work with std::pointer_traits, and it doesn't provide an explicit
> operator bool, or operator[].
>

Thought of one more: a std::hash specialization.


>
> It would be helpful to SFINAE out the const T& and const logical_const<T>&
> constructors when their argument types are not copy-constructible, so that
> std::is_copy_constructible gives the right answers for logical_const. In
> fairness, though, a lot of std:: types fail to do this.
>
> I'm not entirely sure about constructions like "&*t" and the methods that
> use them; there could be exotic smart pointers whose operator* returns a
> proxy object, so you might need to explicitly convert to Value_T& before
> taking the address, and you might need to use std::addressof() instead of
> "&". Relatedly, you should think carefully about how logical_const will
> work with unique_ptr in the case where unique_ptr::pointer is another smart
> pointer: for example, should get() and operator->() return plain pointers,
> or should they return whatever the corresponding members of T return, or
> should they actually return T? I'm actually inclined toward that last
> option, but whatever your answer is, it's worth explicitly discussing in
> the paper. It would also be nice to provide a reset() member. However, this
> raises the same issue: does it take a plain pointer, or whatever T::reset()
> takes, or does it take T?
>
> An implicit conversion operator is not how I'd expect to get access to the
> wrapped pointer. This is not only surprising, it's inconvenient (accessing
> the wrapped pointer will typically require me to name its type, which may
> be quite verbose), and potentially hazardous (implicit conversions often
> get invoked in surprising ways). This is one reason I think get() should
> probably return T, but even if you disagree, you should discuss the design
> tradeoffs here.
>
> Should logical_const<T> have a constructor and assignment operator taking
> logical_const<U>, where U is implicitly convertible to T? This is often
> important for smart pointers, so that they can provide the same implicit
> conversions as raw pointers (e.g. const-qualification, pointer-to-derived
> to pointer-to-base). Similarly, should it have a constructor and assignment
> operator taking nullptr_t? nullptr_t will normally be implicitly
> convertible to T, so the existing constructors mostly do the job, but they
> don't allow nullptr_t to be implicitly convertible to logical_const<T>.
> Generalizing the above, what should logical_const<T> be constructible and
> assignable from? There's an at least superficially plausible case to be
> made that it should behave as much as possible like the T, so it should be
> constructible and assignable from anything T is (and maybe from
> logical_const-wrapped versions of any of those?). In fact, taking this view
> to the extreme, should logical_const<T> _inherit_ from T, when T is a class
> type?
>
>
>
> On Thu, Apr 24, 2014 at 11:05 AM, Jonathan Coe <jonathanbcoe@gmail.com>wrote:
>
>> link as requested by Geoffrey Romer:
>>
>>
>> https://googledrive.com/host/0B5BUDfRWFDPvNGNsWmRJZFp1YU0/logical_const.html
>>
>>
>>
>> On Thursday, April 24, 2014 6:47:43 PM UTC+1, Jonathan Coe wrote:
>>
>>> Following discussion on the BSI and c++std-lib mailing lists I propose
>>> an addition to the C++ Standard Library to make logical const-ness easy to
>>> implement and easy to spot in code review:
>>>
>>> https://drive.google.com/file/d/0B5BUDfRWFDPva1pOM0tyR1FRWFk/
>>> edit?usp=sharing
>>>
>>> All thoughts are welcome.
>>>
>>> Kind regards,
>>>
>>> Jonathan Coe
>>>
>>  --
>>
>> ---
>> 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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Thu, Apr 24, 2014 at 1:39 PM, Geoffrey Romer <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:gromer@google.com" target=3D"_blank">gromer@google.com</a>&gt;=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Here&#39;s a bit of a =
brain-dump; sorry I don&#39;t have time to organize it more:</div><div><br>=
</div>
<div>logical_const is effectively a smart pointer, but it&#39;s missing som=
e important pieces of standard smart-pointer functionality. For example, it=
 doesn&#39;t work with std::pointer_traits, and it doesn&#39;t provide an e=
xplicit operator bool, or operator[].</div>
</div></blockquote><div><br></div><div>Thought of one more: a std::hash spe=
cialization.</div><div>=C2=A0</div><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><br></div><div>It would be helpful to SFINAE out the const T&amp; and =
const logical_const&lt;T&gt;&amp; constructors when their argument types ar=
e not copy-constructible, so that std::is_copy_constructible gives the righ=
t answers for logical_const. In fairness, though, a lot of std:: types fail=
 to do this.</div>


<div><br></div><div>I&#39;m not entirely sure about constructions like &quo=
t;&amp;*t&quot; and the methods that use them; there could be exotic smart =
pointers whose operator* returns a proxy object, so you might need to expli=
citly convert to Value_T&amp; before taking the address, and you might need=
 to use std::addressof() instead of &quot;&amp;&quot;. Relatedly, you shoul=
d think carefully about how logical_const will work with unique_ptr in the =
case where unique_ptr::pointer is another smart pointer: for example, shoul=
d get() and operator-&gt;() return plain pointers, or should they return wh=
atever the corresponding members of T return, or should they actually retur=
n T? I&#39;m actually inclined toward that last option, but whatever your a=
nswer is, it&#39;s worth explicitly discussing in the paper. It would also =
be nice to provide a reset() member. However, this raises the same issue: d=
oes it take a plain pointer, or whatever T::reset() takes, or does it take =
T?</div>

<div><br></div><div>An implicit conversion operator is not how I&#39;d expe=
ct to get access to the wrapped pointer. This is not only surprising, it&#3=
9;s inconvenient (accessing the wrapped pointer will typically require me t=
o name its type, which may be quite verbose), and potentially hazardous (im=
plicit conversions often get invoked in surprising ways). This is one reaso=
n I think get() should probably return T, but even if you disagree, you sho=
uld discuss the design tradeoffs here.<br>

<div><br></div><div>Should logical_const&lt;T&gt; have a constructor and as=
signment operator taking logical_const&lt;U&gt;, where U is implicitly conv=
ertible to T? This is often important for smart pointers, so that they can =
provide the same implicit conversions as raw pointers (e.g. const-qualifica=
tion, pointer-to-derived to pointer-to-base). Similarly, should it have a c=
onstructor and assignment operator taking nullptr_t? nullptr_t will normall=
y be implicitly convertible to T, so the existing constructors mostly do th=
e job, but they don&#39;t allow nullptr_t to be implicitly convertible to l=
ogical_const&lt;T&gt;. Generalizing the above, what should logical_const&lt=
;T&gt; be constructible and assignable from? There&#39;s an at least superf=
icially plausible case to be made that it should behave as much as possible=
 like the T, so it should be constructible and assignable from anything T i=
s (and maybe from logical_const-wrapped versions of any of those?). In fact=
, taking this view to the extreme, should logical_const&lt;T&gt; _inherit_ =
from T, when T is a class type?</div>

<div><div><br></div></div></div></div><div class=3D"HOEnZb"><div class=3D"h=
5"><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Ap=
r 24, 2014 at 11:05 AM, Jonathan Coe <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:jonathanbcoe@gmail.com" target=3D"_blank">jonathanbcoe@gmail.com</a>&gt;<=
/span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">link as requested by Geoffr=
ey Romer:<div><br></div><div><a href=3D"https://googledrive.com/host/0B5BUD=
fRWFDPvNGNsWmRJZFp1YU0/logical_const.html" target=3D"_blank">https://google=
drive.com/host/0B5BUDfRWFDPvNGNsWmRJZFp1YU0/logical_const.html</a></div>

<div><br></div><div><div><br><br>On Thursday, April 24, 2014 6:47:43 PM UTC=
+1, Jonathan Coe wrote:</div><div><div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex">

<div dir=3D"ltr"><div>Following discussion on the BSI and c++std-lib mailin=
g lists I propose an addition to the C++ Standard Library to make logical c=
onst-ness easy to implement and easy to spot in code review:</div><div><br>

</div><div><a href=3D"https://drive.google.com/file/d/0B5BUDfRWFDPva1pOM0ty=
R1FRWFk/edit?usp=3Dsharing" target=3D"_blank">https://drive.google.com/file=
/<u></u>d/<u></u>0B5BUDfRWFDPva1pOM0tyR1FRWFk/<u></u>edit?usp=3Dsharing</a>=
<br>

</div><div><br></div><div>All thoughts are welcome.</div><div><br></div><di=
v>Kind regards,</div><div><br></div><div>Jonathan Coe</div></div></blockquo=
te></div></div></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" 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></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 />

--001a11c300a6a5f9ac04f7e59432--

.

--Apple-Mail=_3CB0B0F8-DD18-47DC-A7A7-10F874AD681E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-05-27, at 3:59 AM, Douglas Boffey <douglas.boffey@gmail.com> wrote:

> In this, valB cannot be changed, due to the logical_const, but as logical=
_const itself is only a shallow const, valA can be changed.

Can you elaborate the example? I don't see what you mean. Did you intend do=
 write A *a? If so, I don't think that's a problem. Usually the current beh=
avior is correct... const is not broken except for container-like classes, =
for which mutable and const iterators are the canonical, but tricky, soluti=
on.

I do like the name deep_const though. I was going to suggest it, and now I =
see you mention the name already. There's no "logic" happening here.

--=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=_3CB0B0F8-DD18-47DC-A7A7-10F874AD681E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"><meta http-equiv=3D"Content-Type" content=3D"text/html cha=
rset=3Dwindows-1252"><meta http-equiv=3D"Content-Type" content=3D"text/html=
 charset=3Dwindows-1252"><meta http-equiv=3D"Content-Type" content=3D"text/=
html charset=3Dwindows-1252"><meta http-equiv=3D"Content-Type" content=3D"t=
ext/html charset=3Dwindows-1252"><meta http-equiv=3D"Content-Type" content=
=3D"text/html charset=3Dwindows-1252"></head><body style=3D"word-wrap: brea=
k-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><=
br><div><div>On 2014&ndash;05&ndash;27, at 3:59 AM, Douglas Boffey &lt;<a h=
ref=3D"mailto:douglas.boffey@gmail.com">douglas.boffey@gmail.com</a>&gt; wr=
ote:</div><br class=3D"Apple-interchange-newline"><blockquote type=3D"cite"=
><div dir=3D"ltr">In this, valB cannot be changed, due to the logical_const=
, but as logical_const itself is only a shallow const, valA can be changed.=
</div></blockquote><br></div><div>Can you elaborate the example? I don&rsqu=
o;t see what you mean. Did you intend do write <font face=3D"Courier">A *a<=
/font>? If so, I don&rsquo;t think that&rsquo;s a problem. Usually the curr=
ent behavior is correct&hellip; <font face=3D"Courier">const</font> is not =
broken except for container-like classes, for which mutable and const itera=
tors are the canonical, but tricky, solution.</div><div><br></div><div>I do=
 like the name <font face=3D"Courier">deep_const</font> though. I was going=
 to suggest it, and now I see you mention the name already. There&rsquo;s n=
o &ldquo;logic&rdquo; happening here.</div><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 />

--Apple-Mail=_3CB0B0F8-DD18-47DC-A7A7-10F874AD681E--

.

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


>
>  Can you elaborate the example? I don=E2=80=99t see what you mean. Did yo=
u intend=20
> do write A *a? If so, I don=E2=80=99t think that=E2=80=99s a problem. Usu=
ally the current=20
> behavior is correct=E2=80=A6 const is not broken except for container-lik=
e=20
> classes, for which mutable and const iterators are the canonical, but=20
> tricky, solution.
>
=20
Sorry, yes, I did mean A *a :)
=20
To me, constness should refer to *everything* that an object refers to,=20
whether directly or indirectly (i.e. through a pointer or reference).  No=
=20
library solution can provide such assurance.
=20

>  I do like the name deep_const though. I was going to suggest it, and now=
=20
> I see you mention the name already. There=E2=80=99s no =E2=80=9Clogic=E2=
=80=9D happening here.
>
=20
:)

--=20

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

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

<div dir=3D"ltr"><BLOCKQUOTE style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: =
0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class=3Dgmail_quote>
<DIV style=3D"WORD-WRAP: break-word">
<DIV>Can you elaborate the example? I don=E2=80=99t see what you mean. Did =
you intend do write <FONT face=3DCourier>A *a</FONT>? If so, I don=E2=80=99=
t think that=E2=80=99s a problem. Usually the current behavior is correct=
=E2=80=A6 <FONT face=3DCourier>const</FONT> is not broken except for contai=
ner-like classes, for which mutable and const iterators are the canonical, =
but tricky, solution.</DIV></DIV></BLOCKQUOTE>
<DIV>&nbsp;</DIV>
<DIV>Sorry, yes, I did mean A *a :)</DIV>
<DIV>&nbsp;</DIV>
<DIV>To me, constness should refer to <EM>everything</EM> that an object re=
fers to, whether directly or indirectly (i.e. through a pointer or referenc=
e).&nbsp; No library solution can provide such assurance.</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3Dgmail_quote>
<DIV style=3D"WORD-WRAP: break-word">
<DIV>I do like the name <FONT face=3DCourier>deep_const</FONT> though. I wa=
s going to suggest it, and now I see you mention the name already. There=E2=
=80=99s no =E2=80=9Clogic=E2=80=9D happening here.</DIV></DIV></BLOCKQUOTE>
<DIV>&nbsp;</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 />

------=_Part_9_11309625.1401188157079--

.

On Mon, May 26, 2014 at 10:45 PM, David Krauss <potswa@gmail.com> wrote:
>
> On 2014=E2=80=9305=E2=80=9327, at 3:59 AM, Douglas Boffey <douglas.boffey=
@gmail.com> wrote:
>
> In this, valB cannot be changed, due to the logical_const, but as
> logical_const itself is only a shallow const, valA can be changed.
>
>
> Can you elaborate the example? I don=E2=80=99t see what you mean. Did you=
 intend do
> write A *a? If so, I don=E2=80=99t think that=E2=80=99s a problem. Usuall=
y the current
> behavior is correct=E2=80=A6 const is not broken except for container-lik=
e classes,
> for which mutable and const iterators are the canonical, but tricky,
> solution.
>
> I do like the name deep_const though. I was going to suggest it, and now =
I
> see you mention the name already. There=E2=80=99s no =E2=80=9Clogic=E2=80=
=9D happening here.

I think the problem of constness is not only for containers. But for
everything that has reference semantics (i.e., when copies are not
disjoint). Because the only salient property of the object is _to
which object it refers to_ they end up differing on the conceptual
level. The mutable being a concept specialization of the read-only.
Which implies that we need two different models (types). Which is IMO
OK. The problem is that it is very awkward to implement both. For
iterators we can sometimes implement one templated iterator and use a
const/non-const parameterized value-type to avoid duplicate code. But
I don't think we have a canonical way to deal with this yet. If we
had/or have then we could standardize something that would make this
less awkward and more intuitive.

> --
>
> ---

Best regards,
--=20
Felipe Magno de Almeida

--=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=_FBDCB8F5-79D2-4E92-B8EF-160BFB5D9757
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-05-27, at 6:55 PM, Douglas Boffey <douglas.boffey@gmail.com> wrote:

> Can you elaborate the example? I don't see what you mean. Did you intend =
do write A *a? If so, I don't think that's a problem. Usually the current b=
ehavior is correct... const is not broken except for container-like classes=
, for which mutable and const iterators are the canonical, but tricky, solu=
tion.
> =20
> Sorry, yes, I did mean A *a :)
> =20
> To me, constness should refer to everything that an object refers to, whe=
ther directly or indirectly (i.e. through a pointer or reference).=20

That's a bit of a code smell. Such a semantic fits data structures, which s=
hould usually be modeled by container classes and not free-form structures.=
 Constness propagates to the things that compose an object, but not the ser=
vices it uses.

> No library solution can provide such assurance.

deep_const should work recursively, as long as it's consistently applied. Y=
ou just need a deep_const< A * > a instead, or perhaps a deep_const< std::u=
nique_ptr< A > >.

--=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=_FBDCB8F5-79D2-4E92-B8EF-160BFB5D9757
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;05&ndash;27, at 6:55 PM, Douglas Boffey &lt;<a href=3D"mailto:douglas=
..boffey@gmail.com">douglas.boffey@gmail.com</a>&gt; wrote:</div><br class=
=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><=
blockquote style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex;=
 PADDING-LEFT: 1ex" class=3D"gmail_quote">
<div style=3D"WORD-WRAP: break-word">
<div>Can you elaborate the example? I don&rsquo;t see what you mean. Did yo=
u intend do write <font face=3D"Courier">A *a</font>? If so, I don&rsquo;t =
think that&rsquo;s a problem. Usually the current behavior is correct&helli=
p; <font face=3D"Courier">const</font> is not broken except for container-l=
ike classes, for which mutable and const iterators are the canonical, but t=
ricky, solution.</div></div></blockquote>
<div>&nbsp;</div>
<div>Sorry, yes, I did mean A *a :)</div>
<div>&nbsp;</div>
<div>To me, constness should refer to <em>everything</em> that an object re=
fers to, whether directly or indirectly (i.e. through a pointer or referenc=
e).&nbsp; </div></div></blockquote><div><br></div><div>That&rsquo;s a bit o=
f a code smell. Such a semantic fits data structures, which should usually =
be modeled by container classes and not free-form structures. Constness pro=
pagates to the things that compose an object, but not the services it uses.=
</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div>No library soluti=
on can provide such assurance.</div></div></blockquote><div><br></div><div>=
<font face=3D"Courier">deep_const</font> should work recursively, as long a=
s it&rsquo;s consistently applied. You just need a <font face=3D"Courier">d=
eep_const&lt; A * &gt; a</font> instead, or perhaps a <font face=3D"Courier=
">deep_const&lt; std::unique_ptr&lt; A &gt; &gt;</font>.</div></div><div><b=
r></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=_FBDCB8F5-79D2-4E92-B8EF-160BFB5D9757--

.

--part1808-boundary-1524484063-1372210533
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

(Sorry top-posting, dumbphone culprit)

A recursive/deep const would be very helpful to put things in ROM.
-----Original Message-----
From: Douglas Boffey <douglas.boffey@gmail.com>
Date: Tue, 27 May 2014 03:55:56=20
To: <std-proposals@isocpp.org>
Reply-To: std-proposals@isocpp.org
Subject: Re: [std-proposals] Re: A Proposal to Add a Logical Const Wrapper =
to
 the Standard Library


>
>  Can you elaborate the example? I don=E2=80=99t see what you mean. Did yo=
u intend=20
> do write A *a? If so, I don=E2=80=99t think that=E2=80=99s a problem. Usu=
ally the current=20
> behavior is correct=E2=80=A6 const is not broken except for container-lik=
e=20
> classes, for which mutable and const iterators are the canonical, but=20
> tricky, solution.
>
=20
Sorry, yes, I did mean A *a :)
=20
To me, constness should refer to *everything* that an object refers to,=20
whether directly or indirectly (i.e. through a pointer or reference).  No=
=20
library solution can provide such assurance.
=20

>  I do like the name deep_const though. I was going to suggest it, and now=
=20
> I see you mention the name already. There=E2=80=99s no =E2=80=9Clogic=E2=
=80=9D happening here.
>
=20
:)

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

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

--part1808-boundary-1524484063-1372210533
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><html><head><=
meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type"></h=
ead><body>(Sorry top-posting, dumbphone culprit)<br/><br/>A recursive/deep =
const would be very helpful to put things in ROM.<hr/><div><b>From: </b> Do=
uglas Boffey &lt;douglas.boffey@gmail.com&gt;
</div><div><b>Date: </b>Tue, 27 May 2014 03:55:56 -0700 (PDT)</div><div><b>=
To: </b>&lt;std-proposals@isocpp.org&gt;</div><div><b>ReplyTo: </b> std-pro=
posals@isocpp.org
</div><div><b>Subject: </b>Re: [std-proposals] Re: A Proposal to Add a Logi=
cal Const Wrapper to
 the Standard Library</div><div><br/></div><div dir=3D"ltr"><BLOCKQUOTE sty=
le=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT:=
 1ex" class=3Dgmail_quote>
<DIV style=3D"WORD-WRAP: break-word">
<DIV>Can you elaborate the example? I don=E2=80=99t see what you mean. Did =
you intend do write <FONT face=3DCourier>A *a</FONT>? If so, I don=E2=80=99=
t think that=E2=80=99s a problem. Usually the current behavior is correct=
=E2=80=A6 <FONT face=3DCourier>const</FONT> is not broken except for contai=
ner-like classes, for which mutable and const iterators are the canonical, =
but tricky, solution.</DIV></DIV></BLOCKQUOTE>
<DIV>&nbsp;</DIV>
<DIV>Sorry, yes, I did mean A *a :)</DIV>
<DIV>&nbsp;</DIV>
<DIV>To me, constness should refer to <EM>everything</EM> that an object re=
fers to, whether directly or indirectly (i.e. through a pointer or referenc=
e).&nbsp; No library solution can provide such assurance.</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3Dgmail_quote>
<DIV style=3D"WORD-WRAP: break-word">
<DIV>I do like the name <FONT face=3DCourier>deep_const</FONT> though. I wa=
s going to suggest it, and now I see you mention the name already. There=E2=
=80=99s no =E2=80=9Clogic=E2=80=9D happening here.</DIV></DIV></BLOCKQUOTE>
<DIV>&nbsp;</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 />

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

--part1808-boundary-1524484063-1372210533--


.

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

I picked the name logical const to differentiate it from physical const.
Logical and physical constness seem to be well-used phrases.

Physical const is 'const' meaning the bits cannot change. Logical const is
the wrapper class and means that member pointees should not be modified in
contexts when member data cannot be modified.

The determination of when member pointees should be const is the logic
(albeit rather simple logic) that's being applied.

Regards,

Jonathan


On 27 May 2014 17:53, Daniel Gutson <danielgutson@gmail.com> wrote:

> (Sorry top-posting, dumbphone culprit)
>
> A recursive/deep const would be very helpful to put things in ROM.
> ------------------------------
> *From: * Douglas Boffey <douglas.boffey@gmail.com>
> *Date: *Tue, 27 May 2014 03:55:56 -0700 (PDT)
> *To: *<std-proposals@isocpp.org>
> *ReplyTo: * std-proposals@isocpp.org
> *Subject: *Re: [std-proposals] Re: A Proposal to Add a Logical Const
> Wrapper to the Standard Library
>
>  Can you elaborate the example? I don=E2=80=99t see what you mean. Did yo=
u intend
>> do write A *a? If so, I don=E2=80=99t think that=E2=80=99s a problem. Us=
ually the
>> current behavior is correct=E2=80=A6 const is not broken except for
>> container-like classes, for which mutable and const iterators are the
>> canonical, but tricky, solution.
>>
>
> Sorry, yes, I did mean A *a :)
>
> To me, constness should refer to *everything* that an object refers to,
> whether directly or indirectly (i.e. through a pointer or reference).  No
> library solution can provide such assurance.
>
>
>>  I do like the name deep_const though. I was going to suggest it, and
>> now I see you mention the name already. There=E2=80=99s no =E2=80=9Clogi=
c=E2=80=9D happening here.
>>
>
> :)
>
> --
>
> ---
> 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/.
>

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

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

<div dir=3D"ltr"><div>I picked the name logical const to differentiate it f=
rom physical const. Logical and physical constness seem to be well-used phr=
ases.<br></div><div><br></div><div>Physical const is &#39;const&#39; meanin=
g the bits cannot change. Logical const is the wrapper class and means that=
 member pointees should not be modified in contexts when member data cannot=
 be modified.</div>
<div><br></div><div>The determination of when member pointees should be con=
st is the logic (albeit rather simple logic) that&#39;s being applied.</div=
><div><br></div><div>Regards,</div><div><br></div><div>Jonathan</div></div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On 27 May 201=
4 17:53, Daniel Gutson <span dir=3D"ltr">&lt;<a href=3D"mailto:danielgutson=
@gmail.com" target=3D"_blank">danielgutson@gmail.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">
<u></u><div>(Sorry top-posting, dumbphone culprit)<br><br>A recursive/deep =
const would be very helpful to put things in ROM.<hr><div><b>From: </b> Dou=
glas Boffey &lt;<a href=3D"mailto:douglas.boffey@gmail.com" target=3D"_blan=
k">douglas.boffey@gmail.com</a>&gt;
</div><div><b>Date: </b>Tue, 27 May 2014 03:55:56 -0700 (PDT)</div><div><b>=
To: </b>&lt;<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">s=
td-proposals@isocpp.org</a>&gt;</div><div><b>ReplyTo: </b> <a href=3D"mailt=
o:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>
</div><div class=3D""><div><b>Subject: </b>Re: [std-proposals] Re: A Propos=
al to Add a Logical Const Wrapper to
 the Standard Library</div><div><br></div></div><div><div class=3D"h5"><div=
 dir=3D"ltr"><blockquote style=3D"BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px=
 0px 0.8ex;PADDING-LEFT:1ex" class=3D"gmail_quote">
<div style=3D"WORD-WRAP:break-word">
<div>Can you elaborate the example? I don=E2=80=99t see what you mean. Did =
you intend do write <font face=3D"Courier">A *a</font>? If so, I don=E2=80=
=99t think that=E2=80=99s a problem. Usually the current behavior is correc=
t=E2=80=A6 <font face=3D"Courier">const</font> is not broken except for con=
tainer-like classes, for which mutable and const iterators are the canonica=
l, but tricky, solution.</div>
</div></blockquote>
<div>=C2=A0</div>
<div>Sorry, yes, I did mean A *a :)</div>
<div>=C2=A0</div>
<div>To me, constness should refer to <em>everything</em> that an object re=
fers to, whether directly or indirectly (i.e. through a pointer or referenc=
e).=C2=A0 No library solution can provide such assurance.</div>
<div>=C2=A0</div>
<blockquote style=3D"BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PA=
DDING-LEFT:1ex" class=3D"gmail_quote">
<div style=3D"WORD-WRAP:break-word">
<div>I do like the name <font face=3D"Courier">deep_const</font> though. I =
was going to suggest it, and now I see you mention the name already. There=
=E2=80=99s no =E2=80=9Clogic=E2=80=9D happening here.</div></div></blockquo=
te>
<div>=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" 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></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>

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

--f46d0418258044f74804fa66637f--

.

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

FWIW, I went with the names deep_const_ptr (for raw pointers) and
deep_const (for pointers like unique_ptr) when I worked with this a couple
years back, possibly influenced by this entry in
StackOverflow<http://stackoverflow.com/questions/12410872/should-constness-=
propagate-to-member-pointer-pointees/12410946#12410946>.
Others appear to have similar
ideas<http://stackoverflow.com/questions/23058501/deep-const-ptr-copy-const=
ructor?rq=3D1>.
But I wouldn't have an objection to logical_const.


On Tue, May 27, 2014 at 3:06 PM, Jonathan Coe <jbcoe@me.com> wrote:

> I picked the name logical const to differentiate it from physical const.
> Logical and physical constness seem to be well-used phrases.
>
> Physical const is 'const' meaning the bits cannot change. Logical const i=
s
> the wrapper class and means that member pointees should not be modified i=
n
> contexts when member data cannot be modified.
>
> The determination of when member pointees should be const is the logic
> (albeit rather simple logic) that's being applied.
>
> Regards,
>
> Jonathan
>
>
> On 27 May 2014 17:53, Daniel Gutson <danielgutson@gmail.com> wrote:
>
>> (Sorry top-posting, dumbphone culprit)
>>
>> A recursive/deep const would be very helpful to put things in ROM.
>> ------------------------------
>> *From: * Douglas Boffey <douglas.boffey@gmail.com>
>> *Date: *Tue, 27 May 2014 03:55:56 -0700 (PDT)
>> *To: *<std-proposals@isocpp.org>
>> *ReplyTo: * std-proposals@isocpp.org
>> *Subject: *Re: [std-proposals] Re: A Proposal to Add a Logical Const
>> Wrapper to the Standard Library
>>
>>  Can you elaborate the example? I don=E2=80=99t see what you mean. Did y=
ou
>>> intend do write A *a? If so, I don=E2=80=99t think that=E2=80=99s a pro=
blem. Usually
>>> the current behavior is correct=E2=80=A6 const is not broken except for
>>> container-like classes, for which mutable and const iterators are the
>>> canonical, but tricky, solution.
>>>
>>
>> Sorry, yes, I did mean A *a :)
>>
>> To me, constness should refer to *everything* that an object refers to,
>> whether directly or indirectly (i.e. through a pointer or reference).  N=
o
>> library solution can provide such assurance.
>>
>>
>>>  I do like the name deep_const though. I was going to suggest it, and
>>> now I see you mention the name already. There=E2=80=99s no =E2=80=9Clog=
ic=E2=80=9D happening here.
>>>
>>
>> :)
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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 Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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 a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/NwLIq4d2-oI/=
unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/.

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

<div dir=3D"ltr">FWIW, I went with the names deep_const_ptr (for raw pointe=
rs) and deep_const (for pointers like unique_ptr) when I worked with this a=
 couple years back, possibly influenced by <a href=3D"http://stackoverflow.=
com/questions/12410872/should-constness-propagate-to-member-pointer-pointee=
s/12410946#12410946">this entry in StackOverflow</a>. Others appear to have=
 <a href=3D"http://stackoverflow.com/questions/23058501/deep-const-ptr-copy=
-constructor?rq=3D1">similar ideas</a>. But I wouldn&#39;t have an objectio=
n to logical_const.</div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue, May 2=
7, 2014 at 3:06 PM, Jonathan Coe <span dir=3D"ltr">&lt;<a href=3D"mailto:jb=
coe@me.com" target=3D"_blank">jbcoe@me.com</a>&gt;</span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
<div dir=3D"ltr"><div>I picked the name logical const to differentiate it f=
rom physical const. Logical and physical constness seem to be well-used phr=
ases.<br></div><div><br></div><div>Physical const is &#39;const&#39; meanin=
g the bits cannot change. Logical const is the wrapper class and means that=
 member pointees should not be modified in contexts when member data cannot=
 be modified.</div>

<div><br></div><div>The determination of when member pointees should be con=
st is the logic (albeit rather simple logic) that&#39;s being applied.</div=
><div><br></div><div>Regards,</div><div><br></div><div>Jonathan</div></div>
<div class=3D"HOEnZb"><div class=3D"h5">
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On 27 May 201=
4 17:53, Daniel Gutson <span dir=3D"ltr">&lt;<a href=3D"mailto:danielgutson=
@gmail.com" target=3D"_blank">danielgutson@gmail.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">

<u></u><div>(Sorry top-posting, dumbphone culprit)<br><br>A recursive/deep =
const would be very helpful to put things in ROM.<hr><div><b>From: </b> Dou=
glas Boffey &lt;<a href=3D"mailto:douglas.boffey@gmail.com" target=3D"_blan=
k">douglas.boffey@gmail.com</a>&gt;
</div><div><b>Date: </b>Tue, 27 May 2014 03:55:56 -0700 (PDT)</div><div><b>=
To: </b>&lt;<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">s=
td-proposals@isocpp.org</a>&gt;</div><div><b>ReplyTo: </b> <a href=3D"mailt=
o:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>
</div><div><div><b>Subject: </b>Re: [std-proposals] Re: A Proposal to Add a=
 Logical Const Wrapper to
 the Standard Library</div><div><br></div></div><div><div><div dir=3D"ltr">=
<blockquote style=3D"BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PA=
DDING-LEFT:1ex" class=3D"gmail_quote">
<div style=3D"WORD-WRAP:break-word">
<div>Can you elaborate the example? I don=E2=80=99t see what you mean. Did =
you intend do write <font face=3D"Courier">A *a</font>? If so, I don=E2=80=
=99t think that=E2=80=99s a problem. Usually the current behavior is correc=
t=E2=80=A6 <font face=3D"Courier">const</font> is not broken except for con=
tainer-like classes, for which mutable and const iterators are the canonica=
l, but tricky, solution.</div>

</div></blockquote>
<div>=C2=A0</div>
<div>Sorry, yes, I did mean A *a :)</div>
<div>=C2=A0</div>
<div>To me, constness should refer to <em>everything</em> that an object re=
fers to, whether directly or indirectly (i.e. through a pointer or referenc=
e).=C2=A0 No library solution can provide such assurance.</div>
<div>=C2=A0</div>
<blockquote style=3D"BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PA=
DDING-LEFT:1ex" class=3D"gmail_quote">
<div style=3D"WORD-WRAP:break-word">
<div>I do like the name <font face=3D"Courier">deep_const</font> though. I =
was going to suggest it, and now I see you mention the name already. There=
=E2=80=99s no =E2=80=9Clogic=E2=80=9D happening here.</div></div></blockquo=
te>
<div>=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" 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></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" 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>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/NwLIq4d2-oI/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/NwLIq4d2-oI=
/unsubscribe</a>.<br>

To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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>

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

--089e01537be264b0f004fa67b08e--

.

--Apple-Mail=_EBE1311D-F7B4-4C6C-A7A8-03085E3BA05E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-05-28, at 3:06 AM, Jonathan Coe <jbcoe@me.com> wrote:

> I picked the name logical const to differentiate it from physical const. =
Logical and physical constness seem to be well-used phrases.
>=20
> Physical const is 'const' meaning the bits cannot change. Logical const i=
s the wrapper class and means that member pointees should not be modified i=
n contexts when member data cannot be modified.

I've never heard the phrase "physical const," and "logical const" still see=
ms to be a neologism. ROM is the physical element, but as Daniel just said =
deep const *is* what you would use for a data structure in ROM. Indeed, the=
 only reliable way to do this now is a POD class, with public data members =
which must nevertheless be accessed by accessor functions.

This suggests that deep_const< T * > should be POD. Just mentioning this, I=
 don't know about the implications.

> The determination of when member pointees should be const is the logic (a=
lbeit rather simple logic) that's being applied.

The opposite determination is also "a logic."

--=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=_EBE1311D-F7B4-4C6C-A7A8-03085E3BA05E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;05&ndash;28, at 3:06 AM, Jonathan Coe &lt;<a href=3D"mailto:jbcoe@me.=
com">jbcoe@me.com</a>&gt; wrote:</div><br class=3D"Apple-interchange-newlin=
e"><blockquote type=3D"cite"><div dir=3D"ltr"><div>I picked the name logica=
l const to differentiate it from physical const. Logical and physical const=
ness seem to be well-used phrases.<br></div><div><br></div><div>Physical co=
nst is 'const' meaning the bits cannot change. Logical const is the wrapper=
 class and means that member pointees should not be modified in contexts wh=
en member data cannot be modified.</div></div></blockquote><div><br></div><=
div>I&rsquo;ve never heard the phrase &ldquo;physical const,&rdquo; and &ld=
quo;logical const&rdquo; still seems to be a neologism. ROM is the physical=
 element, but as Daniel just said deep const *<i>is</i>* what you would use=
 for a data structure in ROM. Indeed, the only reliable way to do this now =
is a POD class, with public data members which must nevertheless be accesse=
d by accessor functions.</div><div><br></div><div>This suggests that <font =
face=3D"Courier">deep_const&lt; T * &gt;</font> should be POD. Just mention=
ing this, I don&rsquo;t know about the implications.</div><br><blockquote t=
ype=3D"cite"><div dir=3D"ltr">
<div>The determination of when member pointees should be const is the logic=
 (albeit rather simple logic) that's being applied.</div></div></blockquote=
><div><br></div><div>The opposite determination is also &ldquo;a logic.&rdq=
uo;</div></div><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 />

--Apple-Mail=_EBE1311D-F7B4-4C6C-A7A8-03085E3BA05E--

.

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

https://isocpp.org/wiki/faq/const-correctness#logical-vs-physical-const


On 28 May 2014 03:07, David Krauss <potswa@gmail.com> wrote:

>
> On 2014=E2=80=9305=E2=80=9328, at 3:06 AM, Jonathan Coe <jbcoe@me.com> wr=
ote:
>
> I picked the name logical const to differentiate it from physical const.
> Logical and physical constness seem to be well-used phrases.
>
> Physical const is 'const' meaning the bits cannot change. Logical const i=
s
> the wrapper class and means that member pointees should not be modified i=
n
> contexts when member data cannot be modified.
>
>
> I=E2=80=99ve never heard the phrase =E2=80=9Cphysical const,=E2=80=9D and=
 =E2=80=9Clogical const=E2=80=9D still
> seems to be a neologism. ROM is the physical element, but as Daniel just
> said deep const **is** what you would use for a data structure in ROM.
> Indeed, the only reliable way to do this now is a POD class, with public
> data members which must nevertheless be accessed by accessor functions.
>
> This suggests that deep_const< T * > should be POD. Just mentioning this,
> I don=E2=80=99t know about the implications.
>
> The determination of when member pointees should be const is the logic
> (albeit rather simple logic) that's being applied.
>
>
> The opposite determination is also =E2=80=9Ca logic.=E2=80=9D
>
>  --
>
> ---
> 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/.

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

<div dir=3D"ltr"><a href=3D"https://isocpp.org/wiki/faq/const-correctness#l=
ogical-vs-physical-const">https://isocpp.org/wiki/faq/const-correctness#log=
ical-vs-physical-const</a><br></div><div class=3D"gmail_extra"><br><br><div=
 class=3D"gmail_quote">
On 28 May 2014 03:07, David Krauss <span dir=3D"ltr">&lt;<a href=3D"mailto:=
potswa@gmail.com" target=3D"_blank">potswa@gmail.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 style=3D"word-wrap:break-word"><br><div><div class=3D""><div>On 2014=
=E2=80=9305=E2=80=9328, at 3:06 AM, Jonathan Coe &lt;<a href=3D"mailto:jbco=
e@me.com" target=3D"_blank">jbcoe@me.com</a>&gt; wrote:</div><br><blockquot=
e type=3D"cite"><div dir=3D"ltr">
<div>I picked the name logical const to differentiate it from physical cons=
t. Logical and physical constness seem to be well-used phrases.<br></div><d=
iv><br></div><div>Physical const is &#39;const&#39; meaning the bits cannot=
 change. Logical const is the wrapper class and means that member pointees =
should not be modified in contexts when member data cannot be modified.</di=
v>
</div></blockquote><div><br></div></div><div>I=E2=80=99ve never heard the p=
hrase =E2=80=9Cphysical const,=E2=80=9D and =E2=80=9Clogical const=E2=80=9D=
 still seems to be a neologism. ROM is the physical element, but as Daniel =
just said deep const *<i>is</i>* what you would use for a data structure in=
 ROM. Indeed, the only reliable way to do this now is a POD class, with pub=
lic data members which must nevertheless be accessed by accessor functions.=
</div>
<div><br></div><div>This suggests that <font face=3D"Courier">deep_const&lt=
; T * &gt;</font> should be POD. Just mentioning this, I don=E2=80=99t know=
 about the implications.</div><div class=3D""><br><blockquote type=3D"cite"=
><div dir=3D"ltr">

<div>The determination of when member pointees should be const is the logic=
 (albeit rather simple logic) that&#39;s being applied.</div></div></blockq=
uote><div><br></div></div><div>The opposite determination is also =E2=80=9C=
a logic.=E2=80=9D</div>
</div><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>

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

--f46d044280de0eaf1304fa74377d--

.

--Apple-Mail=_788BFEBB-E35D-498B-B4AD-07D24DF63752
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1

The term "logical const" does happen to appear in the HTML anchor, but it a=
ppears only once in the page, surrounded by quotes and as such never used a=
s an actual term. The context is a discussion of whether nonstatic member f=
unctions should be declared const or not. What is more broadly discussed is=
 a distinction of logical vs. physical state, but this isn't what the propo=
sed class distinguishes.

 The distinction between logical and physical state does not relate to whet=
her data members are declared as pointer to const, but rather whether they =
should be declared mutable.

Consulting Google, "logical const" appears be a term most often used in the=
 D language, but still specific to methods (nonstatic member functions). Th=
is seems to be the origin of the C++ FAQ terminology. Other uses in the fir=
st page of results either refer to ROM (where the distinction is against "b=
itwise constness"), or relate to your present proposal. The next two pages =
show the same trend, but a rapid decrease in signal-to-noise.

It is clearly apparent that "logical const" is an occasional phrase mainly =
used in D, to refer to something completely different from the proposal.

The proposal does suggest that logical_const allows members to emulate "log=
ical const" accessors, but this is still wrong. The wrapper can only enforc=
e a recursive (deep) concept of physical constness. Only when it has public=
 accessibility, and forms part of the object state, does this correspond to=
 logical constness.


On 2014-05-28, at 7:35 PM, Jonathan Coe <jbcoe@me.com> wrote:

> https://isocpp.org/wiki/faq/const-correctness#logical-vs-physical-const
>=20
>=20
> On 28 May 2014 03:07, David Krauss <potswa@gmail.com> wrote:
>=20
> On 2014-05-28, at 3:06 AM, Jonathan Coe <jbcoe@me.com> wrote:
>=20
>> I picked the name logical const to differentiate it from physical const.=
 Logical and physical constness seem to be well-used phrases.
>>=20
>> Physical const is 'const' meaning the bits cannot change. Logical const =
is the wrapper class and means that member pointees should not be modified =
in contexts when member data cannot be modified.
>=20
> I've never heard the phrase "physical const," and "logical const" still s=
eems to be a neologism. ROM is the physical element, but as Daniel just sai=
d deep const *is* what you would use for a data structure in ROM. Indeed, t=
he only reliable way to do this now is a POD class, with public data member=
s which must nevertheless be accessed by accessor functions.

--=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=_788BFEBB-E35D-498B-B4AD-07D24DF63752
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><div>The term &ldquo;l=
ogical const&rdquo; does happen to appear in the HTML anchor, but it appear=
s only once in the page, surrounded by quotes and as such never used as an =
actual term. The context is a discussion of whether nonstatic member functi=
ons should be declared const or not. What is more broadly discussed is a di=
stinction of logical vs. physical state, but this isn&rsquo;t what the prop=
osed class distinguishes.</div><div><br></div><div>&nbsp;The distinction be=
tween logical and physical state does not relate to whether data members ar=
e declared as pointer to const, but rather whether they should be declared =
mutable.</div><div><br></div><div>Consulting Google, &ldquo;logical const&r=
dquo; appears be a term most often used in the D language, but still specif=
ic to methods (nonstatic member functions). This seems to be the origin of =
the C++ FAQ terminology. Other uses in the first page of results either ref=
er to ROM (where the distinction is against &ldquo;bitwise constness&rdquo;=
), or relate to your present proposal. The next two pages show the same tre=
nd, but a rapid decrease in signal-to-noise.</div><div><br></div><div>It is=
 clearly apparent that &ldquo;logical const&rdquo; is an occasional phrase =
mainly used in D, to refer to something completely different from the propo=
sal.</div><div><br></div><div>The proposal does suggest that <font face=3D"=
Courier">logical_const</font> allows members to emulate &ldquo;logical cons=
t&rdquo; accessors, but this is still wrong. The wrapper can only enforce a=
 recursive (deep) concept of physical constness. Only when it has <font fac=
e=3D"Courier">public</font> accessibility, and forms part of the object sta=
te, does this correspond to logical constness.</div><div><br></div><br><div=
><div>On 2014&ndash;05&ndash;28, at 7:35 PM, Jonathan Coe &lt;<a href=3D"ma=
ilto:jbcoe@me.com">jbcoe@me.com</a>&gt; wrote:</div><br class=3D"Apple-inte=
rchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><a href=3D"http=
s://isocpp.org/wiki/faq/const-correctness#logical-vs-physical-const">https:=
//isocpp.org/wiki/faq/const-correctness#logical-vs-physical-const</a><br></=
div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">
On 28 May 2014 03:07, David Krauss <span dir=3D"ltr">&lt;<a href=3D"mailto:=
potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</span> wrote:<=
br><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-st=
yle: solid; padding-left: 1ex; position: static; z-index: auto;">
<div style=3D"word-wrap:break-word"><br><div><div class=3D""><div>On 2014&n=
dash;05&ndash;28, at 3:06 AM, Jonathan Coe &lt;<a href=3D"mailto:jbcoe@me.c=
om" target=3D"_blank">jbcoe@me.com</a>&gt; wrote:</div><br><blockquote type=
=3D"cite"><div dir=3D"ltr">
<div>I picked the name logical const to differentiate it from physical cons=
t. Logical and physical constness seem to be well-used phrases.<br></div><d=
iv><br></div><div>Physical const is 'const' meaning the bits cannot change.=
 Logical const is the wrapper class and means that member pointees should n=
ot be modified in contexts when member data cannot be modified.</div>
</div></blockquote><div><br></div></div><div>I&rsquo;ve never heard the phr=
ase &ldquo;physical const,&rdquo; and &ldquo;logical const&rdquo; still see=
ms to be a neologism. ROM is the physical element, but as Daniel just said =
deep const *<i>is</i>* what you would use for a data structure in ROM. Inde=
ed, the only reliable way to do this now is a POD class, with public data m=
embers which must nevertheless be accessed by accessor functions.</div>
</div></div></blockquote></div></div></blockquote></div><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 />

--Apple-Mail=_788BFEBB-E35D-498B-B4AD-07D24DF63752--

.

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

Thanks for your persistence David, this has been very useful.

logical_const on deeper inspection does have a well established meaning
which is not what we want: http://dlang.org/const-faq.html#logical-const
logical_const means that the observed state of the object is unchanged
while there may be physical changes (in caches etc) - this is not what the
wrapper does at all.
Given this, we've renamed our wrapper class to 'const_safe'. This conveys
what we want more accurately. The behaviour of the wrapper class is
unchanged.

We went with 'const_safe' over 'deep_const' as 'deep_const' implies (to me)
that the object will always be const which is not the case.

Please find an updated draft linked below

https://googledrive.com/host/0B5BUDfRWFDPvNGNsWmRJZFp1YU0/const_safe.html

regards,

Jonathan



On 30 May 2014 02:47, David Krauss <potswa@gmail.com> wrote:

> The term =E2=80=9Clogical const=E2=80=9D does happen to appear in the HTM=
L anchor, but it
> appears only once in the page, surrounded by quotes and as such never use=
d
> as an actual term. The context is a discussion of whether nonstatic membe=
r
> functions should be declared const or not. What is more broadly discussed
> is a distinction of logical vs. physical state, but this isn=E2=80=99t wh=
at the
> proposed class distinguishes.
>
>  The distinction between logical and physical state does not relate to
> whether data members are declared as pointer to const, but rather whether
> they should be declared mutable.
>
> Consulting Google, =E2=80=9Clogical const=E2=80=9D appears be a term most=
 often used in
> the D language, but still specific to methods (nonstatic member functions=
).
> This seems to be the origin of the C++ FAQ terminology. Other uses in the
> first page of results either refer to ROM (where the distinction is again=
st
> =E2=80=9Cbitwise constness=E2=80=9D), or relate to your present proposal.=
 The next two
> pages show the same trend, but a rapid decrease in signal-to-noise.
>
> It is clearly apparent that =E2=80=9Clogical const=E2=80=9D is an occasio=
nal phrase mainly
> used in D, to refer to something completely different from the proposal.
>
> The proposal does suggest that logical_const allows members to emulate
> =E2=80=9Clogical const=E2=80=9D accessors, but this is still wrong. The w=
rapper can only
> enforce a recursive (deep) concept of physical constness. Only when it ha=
s
> public accessibility, and forms part of the object state, does this
> correspond to logical constness.
>
>
> On 2014=E2=80=9305=E2=80=9328, at 7:35 PM, Jonathan Coe <jbcoe@me.com> wr=
ote:
>
> https://isocpp.org/wiki/faq/const-correctness#logical-vs-physical-const
>
>
> On 28 May 2014 03:07, David Krauss <potswa@gmail.com> wrote:
>
>>
>> On 2014=E2=80=9305=E2=80=9328, at 3:06 AM, Jonathan Coe <jbcoe@me.com> w=
rote:
>>
>> I picked the name logical const to differentiate it from physical const.
>> Logical and physical constness seem to be well-used phrases.
>>
>> Physical const is 'const' meaning the bits cannot change. Logical const
>> is the wrapper class and means that member pointees should not be modifi=
ed
>> in contexts when member data cannot be modified.
>>
>>
>> I=E2=80=99ve never heard the phrase =E2=80=9Cphysical const,=E2=80=9D an=
d =E2=80=9Clogical const=E2=80=9D still
>> seems to be a neologism. ROM is the physical element, but as Daniel just
>> said deep const **is** what you would use for a data structure in ROM.
>> Indeed, the only reliable way to do this now is a POD class, with public
>> data members which must nevertheless be accessed by accessor functions.
>>
>
>  --
>
> ---
> 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/.

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

<div dir=3D"ltr">Thanks for your persistence David, this has been very usef=
ul.<div><br></div><div>logical_const on deeper inspection does have a well =
established meaning which is not what we want:=C2=A0<a href=3D"http://dlang=
..org/const-faq.html#logical-const">http://dlang.org/const-faq.html#logical-=
const</a></div>
<div>logical_const means that the observed state of the object is unchanged=
 while there may be physical changes (in caches etc) - this is not what the=
 wrapper does at all.<br></div><div>Given this, we&#39;ve renamed our wrapp=
er class to &#39;const_safe&#39;. This conveys what we want more accurately=
.. The behaviour of the wrapper class is unchanged.<br>
</div><div><br></div><div>We went with &#39;const_safe&#39; over &#39;deep_=
const&#39; as &#39;deep_const&#39; implies (to me) that the object will alw=
ays be const which is not the case.</div><div><br></div><div>Please find an=
 updated draft linked below=C2=A0</div>
<div><br></div><div><a href=3D"https://googledrive.com/host/0B5BUDfRWFDPvNG=
NsWmRJZFp1YU0/const_safe.html">https://googledrive.com/host/0B5BUDfRWFDPvNG=
NsWmRJZFp1YU0/const_safe.html</a><br></div><div><br></div><div>regards,</di=
v>
<div><br></div><div>Jonathan</div><div><br></div></div><div class=3D"gmail_=
extra"><br><br><div class=3D"gmail_quote">On 30 May 2014 02:47, David Kraus=
s <span dir=3D"ltr">&lt;<a href=3D"mailto:potswa@gmail.com" target=3D"_blan=
k">potswa@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div>The=
 term =E2=80=9Clogical const=E2=80=9D does happen to appear in the HTML anc=
hor, but it appears only once in the page, surrounded by quotes and as such=
 never used as an actual term. The context is a discussion of whether nonst=
atic member functions should be declared const or not. What is more broadly=
 discussed is a distinction of logical vs. physical state, but this isn=E2=
=80=99t what the proposed class distinguishes.</div>
<div><br></div><div>=C2=A0The distinction between logical and physical stat=
e does not relate to whether data members are declared as pointer to const,=
 but rather whether they should be declared mutable.</div><div><br></div><d=
iv>
Consulting Google, =E2=80=9Clogical const=E2=80=9D appears be a term most o=
ften used in the D language, but still specific to methods (nonstatic membe=
r functions). This seems to be the origin of the C++ FAQ terminology. Other=
 uses in the first page of results either refer to ROM (where the distincti=
on is against =E2=80=9Cbitwise constness=E2=80=9D), or relate to your prese=
nt proposal. The next two pages show the same trend, but a rapid decrease i=
n signal-to-noise.</div>
<div><br></div><div>It is clearly apparent that =E2=80=9Clogical const=E2=
=80=9D is an occasional phrase mainly used in D, to refer to something comp=
letely different from the proposal.</div><div><br></div><div>The proposal d=
oes suggest that <font face=3D"Courier">logical_const</font> allows members=
 to emulate =E2=80=9Clogical const=E2=80=9D accessors, but this is still wr=
ong. The wrapper can only enforce a recursive (deep) concept of physical co=
nstness. Only when it has <font face=3D"Courier">public</font> accessibilit=
y, and forms part of the object state, does this correspond to logical cons=
tness.</div>
<div class=3D""><div><br></div><br><div><div>On 2014=E2=80=9305=E2=80=9328,=
 at 7:35 PM, Jonathan Coe &lt;<a href=3D"mailto:jbcoe@me.com" target=3D"_bl=
ank">jbcoe@me.com</a>&gt; wrote:</div><br><blockquote type=3D"cite"><div di=
r=3D"ltr"><a href=3D"https://isocpp.org/wiki/faq/const-correctness#logical-=
vs-physical-const" target=3D"_blank">https://isocpp.org/wiki/faq/const-corr=
ectness#logical-vs-physical-const</a><br>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">
On 28 May 2014 03:07, David Krauss <span dir=3D"ltr">&lt;<a href=3D"mailto:=
potswa@gmail.com" target=3D"_blank">potswa@gmail.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 style=3D"word-wrap:break-word"><br><div><div><div>On 2014=E2=80=9305=
=E2=80=9328, at 3:06 AM, Jonathan Coe &lt;<a href=3D"mailto:jbcoe@me.com" t=
arget=3D"_blank">jbcoe@me.com</a>&gt; wrote:</div><br><blockquote type=3D"c=
ite"><div dir=3D"ltr">
<div>I picked the name logical const to differentiate it from physical cons=
t. Logical and physical constness seem to be well-used phrases.<br></div><d=
iv><br></div><div>Physical const is &#39;const&#39; meaning the bits cannot=
 change. Logical const is the wrapper class and means that member pointees =
should not be modified in contexts when member data cannot be modified.</di=
v>

</div></blockquote><div><br></div></div><div>I=E2=80=99ve never heard the p=
hrase =E2=80=9Cphysical const,=E2=80=9D and =E2=80=9Clogical const=E2=80=9D=
 still seems to be a neologism. ROM is the physical element, but as Daniel =
just said deep const *<i>is</i>* what you would use for a data structure in=
 ROM. Indeed, the only reliable way to do this now is a POD class, with pub=
lic data members which must nevertheless be accessed by accessor functions.=
</div>

</div></div></blockquote></div></div></blockquote></div><br></div></div><di=
v 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>

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

--f46d044280de71cbc604faa155d4--

.

On 2014-05-31, at 1:25 AM, Jonathan Coe <jbcoe@me.com> wrote:

> Thanks for your persistence David, this has been very useful.

OK, thanks, it does feel a bit weird arguing terminology :P .

--

---
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 Fri, May 30, 2014 at 7:25 PM, Jonathan Coe wrote:
> Please find an updated draft linked below
> https://googledrive.com/host/0B5BUDfRWFDPvNGNsWmRJZFp1YU0/const_safe.html

I like the spirit of it.

It should probably noted that such a wrapper only makes sense for
something like unique_pointer where we have unique ownership. In such
a case we can think of the pointee as beeing (logically) part of the
wrapper object and only then this "const inheritance" actually makes
sense.

We basically have these three kinds of object relationships:

(1) Objekt x is physically a part of object y. x is a real subobject.
Constness is automatically inherited by x from y in C++.

(2) Object x is "logically" a part of object y. But it is referenced
through a pointer. "Constness inheritance" is left to the author of
the wrapper via overloading. So, this requires some action of the
author of the class of y.

(3) Object x is not part of object y. y just knows some x via some
pointer member. Example: iterators. Here the constness inheritance
does not make any sense because we could simply copy such an iterator
to a new one without "outer const" to be able to mutate the referenced
data. An iterator is just like a pointer with no ownership
relationship involved.

With unique_ptr as it is right now, we kind of have a mix of 2 and 3.
It's 2 in terms of unique ownership and the responsibility to free the
pointee, but 3 with respect to constness propagation. This can lead to
some inconvenient situations in which, for example, one has a
vector<unique_ptr<T>> and wants to give some other function
const-access to the vector without giving this function any
opportunity to mutate all the pointees.

I'm not proposing to change unique_ptr. But I always thought that it
would be nice to have something in addition like unique_ptr that
propagated the constness. Let's call it boxed<T>. boxed<T> would
behave like unique_ptr except for the constness thing. And I would
actually prefer boxed<T> over const_safe<unique_ptr<T>> since in my
opinion, the use case for const_safe would be limited to unique_ptr
and it's less typing. Providing the const_safe wrapper like you
suggested would just open up the possibility for people to misuse it.
For example, someone might think that it's a good idea to put a
shared_ptr inside a const_safe wrapper hoping for some kind of
const-protection without being aware that this is actually futile:

   const const_safe<shared_ptr<int>> p (make_shared<int>(23));
   // *p += 1;    <-- would not compile, intentionally
   auto q = p;  // create a non-const copy
   *q += 1; // now we actually mutated *p as well!!!

The issue here is the possibility of aliasing. However, with unique
ownership there won't be any aliasing. boxed<T> would then feel like a
move-only value type. It would still support polymorphism etc. And it
would make the "logically internal" T inherit the wrapper's constness.

Cheers!
sg

--

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

.

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

On Wed, Jun 4, 2014 at 4:39 AM, Sebastian Gesemann <s.gesemann@gmail.com>
wrote:

> On Fri, May 30, 2014 at 7:25 PM, Jonathan Coe wrote:
> > Please find an updated draft linked below
> >
> https://googledrive.com/host/0B5BUDfRWFDPvNGNsWmRJZFp1YU0/const_safe.html
>
> I like the spirit of it.
>
> It should probably noted that such a wrapper only makes sense for
> something like unique_pointer where we have unique ownership. In such
> a case we can think of the pointee as beeing (logically) part of the
> wrapper object and only then this "const inheritance" actually makes
> sense.
>
> We basically have these three kinds of object relationships:
>
> (1) Objekt x is physically a part of object y. x is a real subobject.
> Constness is automatically inherited by x from y in C++.
>
> (2) Object x is "logically" a part of object y. But it is referenced
> through a pointer. "Constness inheritance" is left to the author of
> the wrapper via overloading. So, this requires some action of the
> author of the class of y.
>
> (3) Object x is not part of object y. y just knows some x via some
> pointer member. Example: iterators. Here the constness inheritance
> does not make any sense because we could simply copy such an iterator
> to a new one without "outer const" to be able to mutate the referenced
> data. An iterator is just like a pointer with no ownership
> relationship involved.
>
>
Maybe I've lost track of the conversation, but isn't a const_iterator a
"logically const" iterator?
So (some) iterators are actually good examples?

Is const_iterator isomorphic to const_safe<iterator> ?

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

--089e0141a74e4f6c0604fb37d332
Content-Type: text/html; charset=UTF-8

<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 4, 2014 at 4:39 AM, Sebastian Gesemann <span dir="ltr">&lt;<a href="mailto:s.gesemann@gmail.com" target="_blank">s.gesemann@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Fri, May 30, 2014 at 7:25 PM, Jonathan Coe wrote:<br>
&gt; Please find an updated draft linked below<br>
&gt; <a href="https://googledrive.com/host/0B5BUDfRWFDPvNGNsWmRJZFp1YU0/const_safe.html" target="_blank">https://googledrive.com/host/0B5BUDfRWFDPvNGNsWmRJZFp1YU0/const_safe.html</a><br>
<br>
</div>I like the spirit of it.<br>
<br>
It should probably noted that such a wrapper only makes sense for<br>
something like unique_pointer where we have unique ownership. In such<br>
a case we can think of the pointee as beeing (logically) part of the<br>
wrapper object and only then this &quot;const inheritance&quot; actually makes<br>
sense.<br>
<br>
We basically have these three kinds of object relationships:<br>
<br>
(1) Objekt x is physically a part of object y. x is a real subobject.<br>
Constness is automatically inherited by x from y in C++.<br>
<br>
(2) Object x is &quot;logically&quot; a part of object y. But it is referenced<br>
through a pointer. &quot;Constness inheritance&quot; is left to the author of<br>
the wrapper via overloading. So, this requires some action of the<br>
author of the class of y.<br>
<br>
(3) Object x is not part of object y. y just knows some x via some<br>
pointer member. Example: iterators. Here the constness inheritance<br>
does not make any sense because we could simply copy such an iterator<br>
to a new one without &quot;outer const&quot; to be able to mutate the referenced<br>
data. An iterator is just like a pointer with no ownership<br>
relationship involved.<br>
<br></blockquote><div><br></div><div>Maybe I&#39;ve lost track of the conversation, but isn&#39;t a const_iterator a &quot;logically const&quot; iterator?<br></div><div>So (some) iterators are actually good examples?<br>
<br></div><div>Is const_iterator isomorphic to const_safe&lt;iterator&gt; ?<br><br></div>Tony<br></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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

--089e0141a74e4f6c0604fb37d332--

.

--Apple-Mail=_804F6767-0A8B-455A-8F05-2A6B4C3F7499
Content-Type: text/plain; charset=ISO-8859-1


On 2014-06-07, at 12:58 PM, Tony V E <tvaneerd@gmail.com> wrote:

> Maybe I've lost track of the conversation, but isn't a const_iterator a "logically const" iterator?
> So (some) iterators are actually good examples?

The "logically const" term was misplaced. It relates to OO semantics and qualification of member functions, not ownership.

> Is const_iterator isomorphic to const_safe<iterator> ?

No; const_safe< iterator > behaves like iterator but const_safe< iterator > const behaves like const_iterator. Perhaps the name should reflect what is being made more safe, but straw polls can be taken for that.

The proposed wrapper only makes sense as a nonstatic member variable; you will still need to declare local loop iterators as iterator or const_iterator.

--

---
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=_804F6767-0A8B-455A-8F05-2A6B4C3F7499
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;06&ndash;07, at 12:58 PM, Tony V E &lt;<a href=3D"mailto:tvaneerd@gma=
il.com">tvaneerd@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-interchan=
ge-newline"><blockquote type=3D"cite"><div dir=3D"ltr">Maybe I've lost trac=
k of the conversation, but isn't a const_iterator a "logically const" itera=
tor?<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>So (some=
) iterators are actually good examples?<br></div></div></div></div></blockq=
uote><div><br></div><div>The &ldquo;logically const&rdquo; term was misplac=
ed. It relates to OO semantics and qualification of member functions, not o=
wnership.</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D=
"gmail_extra"><div class=3D"gmail_quote"><div>Is const_iterator isomorphic =
to const_safe&lt;iterator&gt; ?</div></div></div></div></blockquote><div><b=
r></div><div>No; <font face=3D"Courier">const_safe&lt; iterator &gt;</font>=
 behaves like&nbsp;<font face=3D"Courier">iterator</font> but <font face=3D=
"Courier">const_safe&lt; iterator &gt; const</font> behaves like <font face=
=3D"Courier">const_iterator</font>. Perhaps the name should reflect what is=
 being made more safe, but straw polls can be taken for that.</div><div><br=
></div><div>The proposed wrapper only makes sense as a nonstatic member var=
iable; you will still need to declare local loop iterators as <font face=3D=
"Courier">iterator</font> or <font face=3D"Courier">const_iterator</font>.<=
/div><div><br></div></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=_804F6767-0A8B-455A-8F05-2A6B4C3F7499--

.

--Apple-Mail-A7686646-8AE1-4E18-858F-DD0EF62FA36F
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I agree with David here.
The wrapper class only makes sense as a non-static member variable.

Maybe the name needs further adjustment?

J

> On 7 Jun 2014, at 06:05, David Krauss <potswa@gmail.com> wrote:
>=20
>=20
>> On 2014=E2=80=9306=E2=80=9307, at 12:58 PM, Tony V E <tvaneerd@gmail.com=
> wrote:
>>=20
>> Maybe I've lost track of the conversation, but isn't a const_iterator a =
"logically const" iterator?
>> So (some) iterators are actually good examples?
>=20
> The =E2=80=9Clogically const=E2=80=9D term was misplaced. It relates to O=
O semantics and qualification of member functions, not ownership.
>=20
>> Is const_iterator isomorphic to const_safe<iterator> ?
>=20
> No; const_safe< iterator > behaves like iterator but const_safe< iterator=
 > const behaves like const_iterator. Perhaps the name should reflect what =
is being made more safe, but straw polls can be taken for that.
>=20
> The proposed wrapper only makes sense as a nonstatic member variable; you=
 will still need to declare local loop iterators as iterator or const_itera=
tor.
>=20
> --=20
>=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=
 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-propo=
sals/.

--=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-A7686646-8AE1-4E18-858F-DD0EF62FA36F
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div>I agree with David here.</div><div=
>The wrapper class only makes sense as a non-static member variable.</div><=
div><br></div><div>Maybe the name needs further adjustment?</div><div><br><=
/div><div>J</div><div><br>On 7 Jun 2014, at 06:05, David Krauss &lt;<a href=
=3D"mailto:potswa@gmail.com">potswa@gmail.com</a>&gt; wrote:<br><br></div><=
blockquote type=3D"cite"><div><meta http-equiv=3D"Content-Type" content=3D"=
text/html charset=3Dwindows-1252"><br><div><div>On 2014=E2=80=9306=E2=80=93=
07, at 12:58 PM, Tony V E &lt;<a href=3D"mailto:tvaneerd@gmail.com">tvaneer=
d@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-interchange-newline"><bl=
ockquote type=3D"cite"><div dir=3D"ltr">Maybe I've lost track of the conver=
sation, but isn't a const_iterator a "logically const" iterator?<br><div cl=
ass=3D"gmail_extra"><div class=3D"gmail_quote"><div>So (some) iterators are=
 actually good examples?<br></div></div></div></div></blockquote><div><br><=
/div><div>The =E2=80=9Clogically const=E2=80=9D term was misplaced. It rela=
tes to OO semantics and qualification of member functions, not ownership.</=
div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extr=
a"><div class=3D"gmail_quote"><div>Is const_iterator isomorphic to const_sa=
fe&lt;iterator&gt; ?</div></div></div></div></blockquote><div><br></div><di=
v>No; <font face=3D"Courier">const_safe&lt; iterator &gt;</font> behaves li=
ke&nbsp;<font face=3D"Courier">iterator</font> but <font face=3D"Courier">c=
onst_safe&lt; iterator &gt; const</font> behaves like <font face=3D"Courier=
">const_iterator</font>. Perhaps the name should reflect what is being made=
 more safe, but straw polls can be taken for that.</div><div><br></div><div=
>The proposed wrapper only makes sense as a nonstatic member variable; you =
will still need to declare local loop iterators as <font face=3D"Courier">i=
terator</font> or <font face=3D"Courier">const_iterator</font>.</div><div><=
br></div></div>

<p></p>

-- <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 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>
</div></blockquote></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-A7686646-8AE1-4E18-858F-DD0EF62FA36F--

.

On 2014-06-07, at 3:49 PM, Jonathan Coe <jonathanbcoe@gmail.com> wrote:

> I agree with David here.
> The wrapper class only makes sense as a non-static member variable.
>
> Maybe the name needs further adjustment?

Naming dilemmas are common. The usual approach in this sort of situation is to collect a number of names in the proposal and then the committee may choose the best, perhaps semi-democratically.

--

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

.

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

I have updated the draft again with a new name following suggestions from
the BSI.

https://googledrive.com/host/0B5BUDfRWFDPvNGNsWmRJZFp1YU0/const_safe.html

regards,

Jonathan


On 7 June 2014 09:40, David Krauss <potswa@gmail.com> wrote:

>
> On 2014-06-07, at 3:49 PM, Jonathan Coe <jonathanbcoe@gmail.com> wrote:
>
> > I agree with David here.
> > The wrapper class only makes sense as a non-static member variable.
> >
> > Maybe the name needs further adjustment?
>
> Naming dilemmas are common. The usual approach in this sort of situation
> is to collect a number of names in the proposal and then the committee may
> choose the best, perhaps semi-democratically.
>
> --
>
> ---
> 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/.

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

<div dir=3D"ltr">I have updated the draft again with a new name following s=
uggestions from the BSI.<div><br></div><div><a href=3D"https://googledrive.=
com/host/0B5BUDfRWFDPvNGNsWmRJZFp1YU0/const_safe.html" target=3D"_blank" st=
yle=3D"font-family:arial,sans-serif;font-size:13px">https://googledrive.com=
/host/0B5BUDfRWFDPvNGNsWmRJZFp1YU0/const_safe.html</a><br>
</div><div><br></div><div>regards,</div><div><br></div><div>Jonathan</div><=
/div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On 7 Jun=
e 2014 09:40, David Krauss <span dir=3D"ltr">&lt;<a href=3D"mailto:potswa@g=
mail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D""><br>
On 2014-06-07, at 3:49 PM, Jonathan Coe &lt;<a href=3D"mailto:jonathanbcoe@=
gmail.com">jonathanbcoe@gmail.com</a>&gt; wrote:<br>
<br>
&gt; I agree with David here.<br>
&gt; The wrapper class only makes sense as a non-static member variable.<br=
>
&gt;<br>
&gt; Maybe the name needs further adjustment?<br>
<br>
</div>Naming dilemmas are common. The usual approach in this sort of situat=
ion is to collect a number of names in the proposal and then the committee =
may choose the best, perhaps semi-democratically.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></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 />

--089e0111db40324cef04fbe16f9f--

.

2014-06-15 17:19 GMT+02:00 Jonathan Coe <jbcoe@me.com>:
> I have updated the draft again with a new name following suggestions from
> the BSI.
>
> https://googledrive.com/host/0B5BUDfRWFDPvNGNsWmRJZFp1YU0/const_safe.html

Thanks for the updated proposal.

Question: What is "Technical Specifications" intended to mean
precisely? (I suggest to use the term "Proposed Wording", if that is
the actually proposed wording for the standard)

If this is "proposed wording"-like: I would strongly recommend to
replace the explicit "enable_if"-construction within the class
template  propagate_const synopsis: The standard has taken much care
not to specify the mechanism (in most cases), if some construction
should be ill-formed or should not participate in overload resolution.
In This case I suggest to replace the enable-if-form by wording (for
the "false" case that says that

"If propagate_const is instantiated with a template argument T, such
that is_lvalue_reference<reference_type>::value is false, the program
is ill-formed"

This would allow different forms of diagnostics, such as one based on
a static_assert instead.

Furthermore, the proposal should discuss why it does not specify and
form of (potentially dependent) of noexcept specifications. One good
candidate for unconditional noexcept(true) would be the provided
explicit operator bool().

std::unique_ptr supports pointer-like types that are not necessarily
"built-in" pointers. Why does the proposal depend on get() returning a
"built-in" pointer?

- Daniel

--

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

.

"Technical Specifications" is a working implementation, not proposed wordin=
g.

I'm looking for stronger guidelines on use of noexcept before putting it in=
 but agree that operator bool looks like a good candidate. Conditional noex=
cept is a murky area to me.

Kind regards,

Jonathan

> On 15 Jun 2014, at 16:46, Daniel Kr=C3=BCgler <daniel.kruegler@gmail.com>=
 wrote:
>=20
> 2014-06-15 17:19 GMT+02:00 Jonathan Coe <jbcoe@me.com>:
>> I have updated the draft again with a new name following suggestions fro=
m
>> the BSI.
>>=20
>> https://googledrive.com/host/0B5BUDfRWFDPvNGNsWmRJZFp1YU0/const_safe.htm=
l
>=20
> Thanks for the updated proposal.
>=20
> Question: What is "Technical Specifications" intended to mean
> precisely? (I suggest to use the term "Proposed Wording", if that is
> the actually proposed wording for the standard)
>=20
> If this is "proposed wording"-like: I would strongly recommend to
> replace the explicit "enable_if"-construction within the class
> template  propagate_const synopsis: The standard has taken much care
> not to specify the mechanism (in most cases), if some construction
> should be ill-formed or should not participate in overload resolution.
> In This case I suggest to replace the enable-if-form by wording (for
> the "false" case that says that
>=20
> "If propagate_const is instantiated with a template argument T, such
> that is_lvalue_reference<reference_type>::value is false, the program
> is ill-formed"
>=20
> This would allow different forms of diagnostics, such as one based on
> a static_assert instead.
>=20
> Furthermore, the proposal should discuss why it does not specify and
> form of (potentially dependent) of noexcept specifications. One good
> candidate for unconditional noexcept(true) would be the provided
> explicit operator bool().
>=20
> std::unique_ptr supports pointer-like types that are not necessarily
> "built-in" pointers. Why does the proposal depend on get() returning a
> "built-in" pointer?
>=20
> - Daniel
>=20
> --=20
>=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=
 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-propo=
sals/.

--=20

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

.

------=_Part_322_6667366.1403250500627
Content-Type: text/plain; charset=UTF-8

I have two comments.

  1) Remove the destructor.

      Declaring the destructor (even if it's defaulted) prevents the
compiler
      from generating the move constructor. This doesn't prevent
propagate_const
      from being movable because the following constructor will do the right
      thing.

      template <typename U>
      propagate_const(propagate_const<U>&& pu) : t{std::move(pu.t)} {
      }

      However, propagate_const<T*> will not be trivially move constructible.
      More precisely, this static_assert fails:

      static_assert(
        std::is_trivially_move_constructible<propagate_const<int*>>::value,
"");

      but will pass if the declaration of the destructor is removed.

  2) Forwarding copy constructor must be constraint.

      Currently, this code fails to compile:

      propagate_const<int*> p1(nullptr);
      propagate_const<int*> p2(p1);

      The last line above doesn't call the copy constructor because it has
the
      following declaration:

      propagate_const(const propagate_const&);

      and since p1 is not const the forwarding constructor is a better match

      template <typename U>
      propagate_const(U&& u) : t{std::forward<U>(u)}
      {
      }

      However, this construct tries to construct t, which has type int*,
from u,
      which has type propagate_const<int*>&.

      The assignment operator has the same issue.

      Considering what 30.3.1.2/4 says about a thread constructor that can
pose
      the same issue, I believe, the implementation should be

      template <typename U, typename = typename std::enable_if<
        !std::is_same<std::decay_t<U>, propagate_const>::value>::type
      >
      propagate_const(U&& u) : t{std::forward<U>(u)}
      {
      }

      I'm not sure whether std::decay_t is the correct transformation or
not.

      Of course, an implementation won't be standardized but the wording
must
      reflect the idea. It should say something similar to:

      Remarks: This constructor shall not participate in overload resolution
      if decay_t<U> is the same type as propagate_const<T>.

--

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

<div dir=3D"ltr">I have two comments.<br><br>&nbsp; 1) Remove the destructo=
r.<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Declaring the destructor (even if =
it's defaulted) prevents the compiler<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fro=
m generating the move constructor. This doesn't prevent propagate_const<br>=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; from being movable because the following con=
structor will do the right<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; thing.<br><br>=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; template &lt;typename U&gt;<br>&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; propagate_const(propagate_const&lt;U&gt;&amp;&amp; pu) : =
t{std::move(pu.t)} {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br><br>&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; However, propagate_const&lt;T*&gt; will not be triviall=
y move constructible.<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; More precisely, thi=
s static_assert fails:<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; static_assert(=
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; std::is_trivially_move_const=
ructible&lt;propagate_const&lt;int*&gt;&gt;::value, "");<br><br>&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; but will pass if the declaration of the destructor is r=
emoved.<br><br>&nbsp; 2) Forwarding copy constructor must be constraint.<br=
><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Currently, this code fails to compile:<=
br>&nbsp;&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; propagate_const&lt=
;int*&gt; p1(nullptr);<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; propagate_const&lt=
;int*&gt; p2(p1);<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The last line above=
 doesn't call the copy constructor because it has the<br>&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; following declaration:<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp; propagate_const(const propagate_const&amp;);<=
br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and si=
nce p1 is not const the forwarding constructor is a better match<br>&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; template &lt;typ=
ename U&gt;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; propagate_const(U&amp;&amp; u=
) : t{std::forward&lt;U&gt;(u)}<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {<br>&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; }<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; However, this construct tries to construct t, which =
has type int*, from u,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; which has type pro=
pagate_const&lt;int*&gt;&amp;.<br>&nbsp;&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; The assignment operator has the same issue.<br>&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Considering what 30.3.1.=
2/4 says about a thread constructor that can pose<br>&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; the same issue, I believe, the implementation should be<br>&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; template &lt;typ=
ename U, typename =3D typename std::enable_if&lt;<br>&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; !std::is_same&lt;std::decay_t&lt;U&gt;, propagate_cons=
t&gt;::value&gt;::type<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;<br>&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; propagate_const(U&amp;&amp; u) : t{std::forward&lt;U&g=
t;(u)}<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; }<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I'=
m not sure whether std::decay_t is the correct transformation or not.<br>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Of course, =
an implementation won't be standardized but the wording must<br>&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; reflect the idea. It should say something similar to:<b=
r>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Remarks=
: This constructor shall not participate in overload resolution<br>&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; if decay_t&lt;U&gt; is the same type as propagate_co=
nst&lt;T&gt;.<br><br></div>

<p></p>

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

------=_Part_322_6667366.1403250500627--

.

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

Thanks Cassio, I'll update the sample implementation.

kind regards,

Jon


On 20 June 2014 09:48, Cassio Neri <cassio.neri@gmail.com> wrote:

> I have two comments.
>
>   1) Remove the destructor.
>
>       Declaring the destructor (even if it's defaulted) prevents the
> compiler
>       from generating the move constructor. This doesn't prevent
> propagate_const
>       from being movable because the following constructor will do the
> right
>       thing.
>
>       template <typename U>
>       propagate_const(propagate_const<U>&& pu) : t{std::move(pu.t)} {
>       }
>
>       However, propagate_const<T*> will not be trivially move
> constructible.
>       More precisely, this static_assert fails:
>
>       static_assert(
>
> std::is_trivially_move_constructible<propagate_const<int*>>::value, "");
>
>       but will pass if the declaration of the destructor is removed.
>
>   2) Forwarding copy constructor must be constraint.
>
>       Currently, this code fails to compile:
>
>       propagate_const<int*> p1(nullptr);
>       propagate_const<int*> p2(p1);
>
>       The last line above doesn't call the copy constructor because it has
> the
>       following declaration:
>
>       propagate_const(const propagate_const&);
>
>       and since p1 is not const the forwarding constructor is a better
> match
>
>       template <typename U>
>       propagate_const(U&& u) : t{std::forward<U>(u)}
>       {
>       }
>
>       However, this construct tries to construct t, which has type int*,
> from u,
>       which has type propagate_const<int*>&.
>
>       The assignment operator has the same issue.
>
>       Considering what 30.3.1.2/4 says about a thread constructor that
> can pose
>       the same issue, I believe, the implementation should be
>
>       template <typename U, typename = typename std::enable_if<
>         !std::is_same<std::decay_t<U>, propagate_const>::value>::type
>       >
>       propagate_const(U&& u) : t{std::forward<U>(u)}
>       {
>       }
>
>       I'm not sure whether std::decay_t is the correct transformation or
> not.
>
>       Of course, an implementation won't be standardized but the wording
> must
>       reflect the idea. It should say something similar to:
>
>       Remarks: This constructor shall not participate in overload
> resolution
>       if decay_t<U> is the same type as propagate_const<T>.
>
>  --
>
> ---
> 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/.

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

<div dir=3D"ltr">Thanks Cassio, I&#39;ll update the sample implementation.<=
div><br></div><div>kind regards,</div><div><br></div><div>Jon</div></div><d=
iv class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On 20 June 2014=
 09:48, Cassio Neri <span dir=3D"ltr">&lt;<a href=3D"mailto:cassio.neri@gma=
il.com" target=3D"_blank">cassio.neri@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">I have two comments.<br><br=
>=C2=A0 1) Remove the destructor.<br><br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Dec=
laring the destructor (even if it&#39;s defaulted) prevents the compiler<br=
>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 from generating the move constructor. This d=
oesn&#39;t prevent propagate_const<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 from b=
eing movable because the following constructor will do the right<br>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 thing.<br><br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 templ=
ate &lt;typename U&gt;<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 propagate_const(propagate_const&lt;U&gt;&amp=
;&amp; pu) : t{std::move(pu.t)} {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br><b=
r>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 However, propagate_const&lt;T*&gt; will no=
t be trivially move constructible.<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 More p=
recisely, this static_assert fails:<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 static_assert(<br>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 std::is_trivially_move_constructible&lt;propagate_con=
st&lt;int*&gt;&gt;::value, &quot;&quot;);<br><br>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 but will pass if the declaration of the destructor is removed.<br><b=
r>=C2=A0 2) Forwarding copy constructor must be constraint.<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Currently, this code fails to compile:<b=
r>=C2=A0=C2=A0=C2=A0 <br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 propagate_const&lt;=
int*&gt; p1(nullptr);<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 propagate_const&lt;=
int*&gt; p2(p1);<br><br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The last line above =
doesn&#39;t call the copy constructor because it has the<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 following declaration:<br>=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 <br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 propagate_const(const propa=
gate_const&amp;);<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <br>=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 and since p1 is not const the forwarding constructor is a bett=
er match<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 template &lt;typename U&gt;<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 propagate_const(U&amp;&amp; u) : t{std::forw=
ard&lt;U&gt;(u)}<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 }<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <br>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 However, this construct tries to construct t, which has type int*=
, from u,<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 which has type propagate_const&=
lt;int*&gt;&amp;.<br>
=C2=A0=C2=A0=C2=A0 <br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The assignment operat=
or has the same issue.<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <br>=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 Considering what <a href=3D"http://30.3.1.2/4" target=3D=
"_blank">30.3.1.2/4</a> says about a thread constructor that can pose<br>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the same issue, I believe, the implementatio=
n should be<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 template =
&lt;typename U, typename =3D typename std::enable_if&lt;<br>=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 !std::is_same&lt;std::decay_t&lt;U&gt;, propaga=
te_const&gt;::value&gt;::type<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &gt;<br>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 propagate_const(U&amp;&amp; u) : t{std::forward=
&lt;U&gt;(u)}<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 <br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I&#39;m not =
sure whether std::decay_t is the correct transformation or not.<br>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 <br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Of course, an i=
mplementation won&#39;t be standardized but the wording must<br>=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 reflect the idea. It should say something similar to:=
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Remarks: =
This constructor shall not participate in overload resolution<br>=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 if decay_t&lt;U&gt; is the same type as propagate_con=
st&lt;T&gt;.<br><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>

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

--001a11c1bafe418a4504fc3fc630--

.

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

Some smart observations there from Mr Neri.

Rob
On Jun 20, 2014 8:52 AM, "Jonathan Coe" <jbcoe@me.com> wrote:

> Thanks Cassio, I'll update the sample implementation.
>
> kind regards,
>
> Jon
>
>
> On 20 June 2014 09:48, Cassio Neri <cassio.neri@gmail.com> wrote:
>
>> I have two comments.
>>
>>   1) Remove the destructor.
>>
>>       Declaring the destructor (even if it's defaulted) prevents the
>> compiler
>>       from generating the move constructor. This doesn't prevent
>> propagate_const
>>       from being movable because the following constructor will do the
>> right
>>       thing.
>>
>>       template <typename U>
>>       propagate_const(propagate_const<U>&& pu) : t{std::move(pu.t)} {
>>       }
>>
>>       However, propagate_const<T*> will not be trivially move
>> constructible.
>>       More precisely, this static_assert fails:
>>
>>       static_assert(
>>
>> std::is_trivially_move_constructible<propagate_const<int*>>::value, "");
>>
>>       but will pass if the declaration of the destructor is removed.
>>
>>   2) Forwarding copy constructor must be constraint.
>>
>>       Currently, this code fails to compile:
>>
>>       propagate_const<int*> p1(nullptr);
>>       propagate_const<int*> p2(p1);
>>
>>       The last line above doesn't call the copy constructor because it
>> has the
>>       following declaration:
>>
>>       propagate_const(const propagate_const&);
>>
>>       and since p1 is not const the forwarding constructor is a better
>> match
>>
>>       template <typename U>
>>       propagate_const(U&& u) : t{std::forward<U>(u)}
>>       {
>>       }
>>
>>       However, this construct tries to construct t, which has type int*,
>> from u,
>>       which has type propagate_const<int*>&.
>>
>>       The assignment operator has the same issue.
>>
>>       Considering what 30.3.1.2/4 says about a thread constructor that
>> can pose
>>       the same issue, I believe, the implementation should be
>>
>>       template <typename U, typename = typename std::enable_if<
>>         !std::is_same<std::decay_t<U>, propagate_const>::value>::type
>>       >
>>       propagate_const(U&& u) : t{std::forward<U>(u)}
>>       {
>>       }
>>
>>       I'm not sure whether std::decay_t is the correct transformation or
>> not.
>>
>>       Of course, an implementation won't be standardized but the wording
>> must
>>       reflect the idea. It should say something similar to:
>>
>>       Remarks: This constructor shall not participate in overload
>> resolution
>>       if decay_t<U> is the same type as propagate_const<T>.
>>
>>  --
>>
>> ---
>> 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 a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/NwLIq4d2-oI/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/.

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

<p>Some smart observations there from Mr Neri.</p>
<p>Rob</p>
<div class=3D"gmail_quote">On Jun 20, 2014 8:52 AM, &quot;Jonathan Coe&quot=
; &lt;<a href=3D"mailto:jbcoe@me.com">jbcoe@me.com</a>&gt; wrote:<br type=
=3D"attribution"><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">Thanks Cassio, I&#39;ll update the sample implementation.<=
div><br></div><div>kind regards,</div><div><br></div><div>Jon</div></div><d=
iv class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On 20 June 2014=
 09:48, Cassio Neri <span dir=3D"ltr">&lt;<a href=3D"mailto:cassio.neri@gma=
il.com" target=3D"_blank">cassio.neri@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">I have two comments.<br><br=
>=C2=A0 1) Remove the destructor.<br><br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Dec=
laring the destructor (even if it&#39;s defaulted) prevents the compiler<br=
>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 from generating the move constructor. This d=
oesn&#39;t prevent propagate_const<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 from b=
eing movable because the following constructor will do the right<br>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 thing.<br><br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 templ=
ate &lt;typename U&gt;<br>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 propagate_const(propagate_const&lt;U&gt;&amp=
;&amp; pu) : t{std::move(pu.t)} {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br><b=
r>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 However, propagate_const&lt;T*&gt; will no=
t be trivially move constructible.<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 More p=
recisely, this static_assert fails:<br>

<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 static_assert(<br>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 std::is_trivially_move_constructible&lt;propagate_con=
st&lt;int*&gt;&gt;::value, &quot;&quot;);<br><br>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 but will pass if the declaration of the destructor is removed.<br><b=
r>=C2=A0 2) Forwarding copy constructor must be constraint.<br>

<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Currently, this code fails to compile:<b=
r>=C2=A0=C2=A0=C2=A0 <br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 propagate_const&lt;=
int*&gt; p1(nullptr);<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 propagate_const&lt;=
int*&gt; p2(p1);<br><br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The last line above =
doesn&#39;t call the copy constructor because it has the<br>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 following declaration:<br>=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 <br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 propagate_const(const propa=
gate_const&amp;);<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <br>=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 and since p1 is not const the forwarding constructor is a bett=
er match<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 template &lt;typename U&gt;<br>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 propagate_const(U&amp;&amp; u) : t{std::forw=
ard&lt;U&gt;(u)}<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 }<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <br>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 However, this construct tries to construct t, which has type int*=
, from u,<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 which has type propagate_const&=
lt;int*&gt;&amp;.<br>

=C2=A0=C2=A0=C2=A0 <br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The assignment operat=
or has the same issue.<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <br>=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 Considering what <a href=3D"http://30.3.1.2/4" target=3D=
"_blank">30.3.1.2/4</a> says about a thread constructor that can pose<br>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the same issue, I believe, the implementatio=
n should be<br>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 template =
&lt;typename U, typename =3D typename std::enable_if&lt;<br>=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 !std::is_same&lt;std::decay_t&lt;U&gt;, propaga=
te_const&gt;::value&gt;::type<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &gt;<br>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 propagate_const(U&amp;&amp; u) : t{std::forward=
&lt;U&gt;(u)}<br>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 <br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I&#39;m not =
sure whether std::decay_t is the correct transformation or not.<br>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 <br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Of course, an i=
mplementation won&#39;t be standardized but the wording must<br>=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 reflect the idea. It should say something similar to:=
<br>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Remarks: =
This constructor shall not participate in overload resolution<br>=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 if decay_t&lt;U&gt; is the same type as propagate_con=
st&lt;T&gt;.<br><br></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" 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>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/NwLIq4d2-oI/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/NwLIq4d2-oI=
/unsubscribe</a>.<br>

To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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>
</blockquote></div>

<p></p>

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

--001a11c3529e8aa72304fc47d736--

.

------=_Part_1_22808083.1404302232594
Content-Type: text/plain; charset=UTF-8

Paper updated following comments on this list and at the Rapperswil meeting:

https://fa164c0271784b8ad77195d88aaed277e2e36a04.googledrive.com/host/0B5BUDfRWFDPvNGNsWmRJZFp1YU0/propagate_const.html

We will work on formal wording next.

Comments welcome as always.

Regards,

Jon

--

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

<div dir=3D"ltr">Paper updated following comments on this list and at the R=
apperswil meeting:<div><br></div><div><a href=3D"https://fa164c0271784b8ad7=
7195d88aaed277e2e36a04.googledrive.com/host/0B5BUDfRWFDPvNGNsWmRJZFp1YU0/pr=
opagate_const.html">https://fa164c0271784b8ad77195d88aaed277e2e36a04.google=
drive.com/host/0B5BUDfRWFDPvNGNsWmRJZFp1YU0/propagate_const.html</a><br></d=
iv><div><br></div><div>We will work on formal wording next.</div><div><br><=
/div><div>Comments welcome as always.</div><div><br></div><div>Regards,</di=
v><div><br></div><div>Jon</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_1_22808083.1404302232594--

.