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

Sometimes default construction or move-from leaves an object in a state
where it's no use for anything but later assignment. It would be handy to
have an attribute to signify this and help static analyzers.

Any thoughts?

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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAAbBDD9jLYvL1Y2Bah1T6G5%2B_YABGYbj03cHdiMODu6etThhwg%40mail.gmail.com.

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

<div dir=3D"ltr">Sometimes default construction or move-from leaves an obje=
ct in a state where it&#39;s no use for anything but later assignment. It w=
ould be handy to have an attribute to signify this and help static analyzer=
s.<div><br></div><div>Any thoughts?</div><div><br></div><div>Jon</div></div=
>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAAbBDD9jLYvL1Y2Bah1T6G5%2B_YABGYbj03=
cHdiMODu6etThhwg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAAbBDD9jLYvL1Y=
2Bah1T6G5%2B_YABGYbj03cHdiMODu6etThhwg%40mail.gmail.com</a>.<br />

--94eb2c048d247479d705366f790c--

.

------=_Part_280_999584353.1467229679635
Content-Type: multipart/alternative;
 boundary="----=_Part_281_609805801.1467229679636"

------=_Part_281_609805801.1467229679636
Content-Type: text/plain; charset=UTF-8

Would this concept be extensible to operations besides default
construction? Say... move assignment for the source object? Are those cases
similar enough that a single attribute makes sense?

A related question is whether this is useful for all constructors? An
example I have in production code would be a matrix4x4 class that
default-initializes to an identity affine transformation, but also has a
tagged constructor (that takes an object of type uninitialized_t, generally
initialized from the global constant named 'uninitialized') that leaves the
data uninitialized, in case you know you're going to be overwriting the
whole thing and don't trust the optimized to remove dead stores (this
unfortunately also requires some custom type traits to support the concept
of non-default trivial constructors for container optimizations). So,
could/should we potentially apply an uninitialized attribute to these kinds
of constructors?

On Wednesday, June 29, 2016 at 12:08:12 PM UTC-7, Jonathan Coe wrote:
>
> Sometimes default construction or move-from leaves an object in a state
> where it's no use for anything but later assignment. It would be handy to
> have an attribute to signify this and help static analyzers.
>
> Any thoughts?
>
> 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8b88f9fd-069f-403b-8252-614e5500e198%40isocpp.org.

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

<div dir=3D"ltr">Would this concept be extensible to operations besides def=
ault construction? Say... move assignment for the source object? Are those =
cases similar enough that a single attribute makes sense?<div><br></div><di=
v>A related question is whether this is useful for all constructors? An exa=
mple I have in production code would be a matrix4x4 class that default-init=
ializes to an identity affine transformation, but also has a tagged constru=
ctor (that takes an object of type uninitialized_t, generally initialized f=
rom the global constant named &#39;uninitialized&#39;) that leaves the data=
 uninitialized, in case you know you&#39;re going to be overwriting the who=
le thing and don&#39;t trust the optimized to remove dead stores (this unfo=
rtunately also requires some custom type traits to support the concept of n=
on-default trivial constructors for container optimizations). So, could/sho=
uld we potentially apply an uninitialized attribute to these kinds of const=
ructors?<br><br>On Wednesday, June 29, 2016 at 12:08:12 PM UTC-7, Jonathan =
Coe wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Som=
etimes default construction or move-from leaves an object in a state where =
it&#39;s no use for anything but later assignment. It would be handy to hav=
e an attribute to signify this and help static analyzers.<div><br></div><di=
v>Any thoughts?</div><div><br></div><div>Jon</div></div>
</blockquote></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8b88f9fd-069f-403b-8252-614e5500e198%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8b88f9fd-069f-403b-8252-614e5500e198=
%40isocpp.org</a>.<br />

------=_Part_281_609805801.1467229679636--

------=_Part_280_999584353.1467229679635--

.

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

If I have a type that does heap allocation (like a matrix) then a default
constructed object would be empty (and useless without assignment) and a
moved-from object would have its heap allocated resources stolen and would
be empty again. An empty matrix is valid but not useful. If I'm reading
from it, odds are it's a bug. Perhaps I could use the attribute
[[uninitialized]] as follows:

class matrix
{
  [[uninitialized]] matrix();
  matrix(matrix&& m[[uninitialized]]); // m will be put into an empty state
  ...
};

Maybe [[empty]] would be a better name?

On 29 June 2016 at 20:47, Sean Middleditch <sean.middleditch@gmail.com>
wrote:

> Would this concept be extensible to operations besides default
> construction? Say... move assignment for the source object? Are those cases
> similar enough that a single attribute makes sense?
>
> A related question is whether this is useful for all constructors? An
> example I have in production code would be a matrix4x4 class that
> default-initializes to an identity affine transformation, but also has a
> tagged constructor (that takes an object of type uninitialized_t, generally
> initialized from the global constant named 'uninitialized') that leaves the
> data uninitialized, in case you know you're going to be overwriting the
> whole thing and don't trust the optimized to remove dead stores (this
> unfortunately also requires some custom type traits to support the concept
> of non-default trivial constructors for container optimizations). So,
> could/should we potentially apply an uninitialized attribute to these kinds
> of constructors?
>
>
> On Wednesday, June 29, 2016 at 12:08:12 PM UTC-7, Jonathan Coe wrote:
>>
>> Sometimes default construction or move-from leaves an object in a state
>> where it's no use for anything but later assignment. It would be handy to
>> have an attribute to signify this and help static analyzers.
>>
>> Any thoughts?
>>
>> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8b88f9fd-069f-403b-8252-614e5500e198%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8b88f9fd-069f-403b-8252-614e5500e198%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAAbBDD_SyzkOoeL8Fjdb%3D6hVKJX2tLGF17wcvjZSh2m%3D7OwDyA%40mail.gmail.com.

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

<div dir=3D"ltr">If I have a type that does heap allocation (like a matrix)=
 then a default constructed object would be empty (and useless without assi=
gnment) and a moved-from object would have its heap allocated resources sto=
len and would be empty again. An empty matrix is valid but not useful. If I=
&#39;m reading from it, odds are it&#39;s a bug. Perhaps I could use the at=
tribute [[uninitialized]] as follows:<div><br></div><div>class matrix</div>=
<div>{=C2=A0</div><div>=C2=A0 [[uninitialized]] matrix();=C2=A0</div><div>=
=C2=A0 matrix(matrix&amp;&amp; m[[uninitialized]]); // m will be put into a=
n empty state</div><div>=C2=A0 ...</div><div>};</div><div><br></div><div>Ma=
ybe [[empty]] would be a better name?</div></div><div class=3D"gmail_extra"=
><br><div class=3D"gmail_quote">On 29 June 2016 at 20:47, Sean Middleditch =
<span dir=3D"ltr">&lt;<a href=3D"mailto:sean.middleditch@gmail.com" target=
=3D"_blank">sean.middleditch@gmail.com</a>&gt;</span> wrote:<br><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr">Would this concept be extensible to op=
erations besides default construction? Say... move assignment for the sourc=
e object? Are those cases similar enough that a single attribute makes sens=
e?<div><br></div><div>A related question is whether this is useful for all =
constructors? An example I have in production code would be a matrix4x4 cla=
ss that default-initializes to an identity affine transformation, but also =
has a tagged constructor (that takes an object of type uninitialized_t, gen=
erally initialized from the global constant named &#39;uninitialized&#39;) =
that leaves the data uninitialized, in case you know you&#39;re going to be=
 overwriting the whole thing and don&#39;t trust the optimized to remove de=
ad stores (this unfortunately also requires some custom type traits to supp=
ort the concept of non-default trivial constructors for container optimizat=
ions). So, could/should we potentially apply an uninitialized attribute to =
these kinds of constructors?<div><div class=3D"h5"><br><br>On Wednesday, Ju=
ne 29, 2016 at 12:08:12 PM UTC-7, Jonathan Coe wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr">Sometimes default construction or move-f=
rom leaves an object in a state where it&#39;s no use for anything but late=
r assignment. It would be handy to have an attribute to signify this and he=
lp static analyzers.<div><br></div><div>Any thoughts?</div><div><br></div><=
div>Jon</div></div>
</blockquote></div></div></div></div><span class=3D"HOEnZb"><font color=3D"=
#888888">

<p></p>

-- <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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8b88f9fd-069f-403b-8252-614e5500e198%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8b88f9fd-069f-=
403b-8252-614e5500e198%40isocpp.org</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAAbBDD_SyzkOoeL8Fjdb%3D6hVKJX2tLGF17=
wcvjZSh2m%3D7OwDyA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAAbBDD_SyzkO=
oeL8Fjdb%3D6hVKJX2tLGF17wcvjZSh2m%3D7OwDyA%40mail.gmail.com</a>.<br />

--001a11404b900d4eb30536707f1e--

.

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

On 29 June 2016 at 14:08, Jonathan Coe <jbcoe@me.com> wrote:

> Sometimes default construction or move-from leaves an object in a state
> where it's no use for anything but later assignment.


Well, it isn't uninitialized, because you have to be able to destroy the
object.  We should discourage people from weaken their class invariants;
optional<T> is a much better solution for these situations.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BM6guUio-Z2MzBVQZb%2BAabH884SQ_9bEQ0RbG1NbFCfxA%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra">On 29 June 2016 at 14:08, Jonat=
han Coe <span dir=3D"ltr">&lt;<a href=3D"mailto:jbcoe@me.com" target=3D"_bl=
ank">jbcoe@me.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">Sometimes default construction or move-from leave=
s an object in a state where it&#39;s no use for anything but later assignm=
ent.</blockquote></div><br>Well, it isn&#39;t uninitialized, because you ha=
ve to be able to destroy the object.=C2=A0 We should discourage people from=
 weaken their class invariants; optional&lt;T&gt; is a much better solution=
 for these situations.</div><div class=3D"gmail_extra">-- <br><div data-sma=
rtmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=
=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@evi=
loverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt; =C2=A0<a hr=
ef=3D"tel:%2B1-847-691-1404" value=3D"+18476911404" target=3D"_blank">+1-84=
7-691-1404</a></div></div></div></div></div>
</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BM6guUio-Z2MzBVQZb%2BAabH884S=
Q_9bEQ0RbG1NbFCfxA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BM6gu=
Uio-Z2MzBVQZb%2BAabH884SQ_9bEQ0RbG1NbFCfxA%40mail.gmail.com</a>.<br />

--001a114480fee35890053671ecfd--

.

On 29 June 2016 at 22:47, Sean Middleditch <sean.middleditch@gmail.com> wrote:
> Would this concept be extensible to operations besides default construction?
> Say... move assignment for the source object? Are those cases similar enough
> that a single attribute makes sense?
>
> A related question is whether this is useful for all constructors? An
> example I have in production code would be a matrix4x4 class that
> default-initializes to an identity affine transformation, but also has a
> tagged constructor (that takes an object of type uninitialized_t, generally
> initialized from the global constant named 'uninitialized') that leaves the
> data uninitialized, in case you know you're going to be overwriting the
> whole thing and don't trust the optimized to remove dead stores (this
> unfortunately also requires some custom type traits to support the concept
> of non-default trivial constructors for container optimizations). So,
> could/should we potentially apply an uninitialized attribute to these kinds
> of constructors?


Perhaps such features should be done as part of Contracts?

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUZgPtYitHgEJpZ0QO9B_N7TjPGSt3T22xB1_humfzPJuw%40mail.gmail.com.

.

> On Jun 29, 2016, at 5:10 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>
> Perhaps such features should be done as part of Contracts?

That sounds like a better fit.
--
 Nevin ":-)" Liber <mailto:nevin@eviloverlord.com>  +1-312-623-5420

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/72AD5FD9-18EA-4C88-ACE2-C29F3123F317%40gmail.com.

.

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

Suppose I call it [[empty]], does that change your thoughts at all?

My weak aim is to help the optimizer and static analyzer. Weak motivating
example follows:

A foo() {
  A a; // where we declared [[empty]] A() = default;
  auto x = some_input();
  if ( x == 0 ) a = f0();
  if ( x != 0 ) a = f1();
  return a;
}

A bar() {
  A a; // where we declared [[empty]] A() = default;
  auto x = some_input();
  if ( x == 0 ) a = f0();
  if ( x == 1 ) a = f1();
  return a; // Compiler can warn about the potential return of an [[empty]]
object
}

On 29 June 2016 at 23:02, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 29 June 2016 at 14:08, Jonathan Coe <jbcoe@me.com> wrote:
>
>> Sometimes default construction or move-from leaves an object in a state
>> where it's no use for anything but later assignment.
>
>
> Well, it isn't uninitialized, because you have to be able to destroy the
> object.  We should discourage people from weaken their class invariants;
> optional<T> is a much better solution for these situations.
> --
>  Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BM6guUio-Z2MzBVQZb%2BAabH884SQ_9bEQ0RbG1NbFCfxA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BM6guUio-Z2MzBVQZb%2BAabH884SQ_9bEQ0RbG1NbFCfxA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAAbBDD_H0Uoo2FWc3jnvV5pJEoQbd6mYkRNoyZKv9kp6ihXNeA%40mail.gmail.com.

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

<div dir=3D"ltr">Suppose I call it [[empty]], does that change your thought=
s at all?<div><br></div><div>My weak aim is to help the optimizer and stati=
c analyzer. Weak motivating example follows:</div><div><br></div><div>A foo=
() {</div><div>=C2=A0 A a; // where we declared [[empty]] A() =3D default;<=
/div><div>=C2=A0 auto x =3D some_input();</div><div>=C2=A0 if ( x =3D=3D 0 =
) a =3D f0();</div><div>=C2=A0 if ( x !=3D 0 ) a =3D f1();<br></div><div>=
=C2=A0 return a;</div><div>}</div><div><br></div><div><div>A bar() {</div><=
div>=C2=A0 A a; // where we declared [[empty]] A() =3D default;</div><div>=
=C2=A0 auto x =3D some_input();</div><div>=C2=A0 if ( x =3D=3D 0 ) a =3D f0=
();</div><div>=C2=A0 if ( x =3D=3D 1 ) a =3D f1();<br></div><div>=C2=A0 ret=
urn a; // Compiler can warn about the potential return of an [[empty]] obje=
ct</div><div>}</div></div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On 29 June 2016 at 23:02, Nevin Liber <span dir=3D"ltr">&l=
t;<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evilove=
rlord.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_extra"><span class=3D"">On 29 June 2016 at 14:=
08, Jonathan Coe <span dir=3D"ltr">&lt;<a href=3D"mailto:jbcoe@me.com" targ=
et=3D"_blank">jbcoe@me.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quo=
te"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">Sometimes default construction or move-f=
rom leaves an object in a state where it&#39;s no use for anything but late=
r assignment.</blockquote></div><br></span>Well, it isn&#39;t uninitialized=
, because you have to be able to destroy the object.=C2=A0 We should discou=
rage people from weaken their class invariants; optional&lt;T&gt; is a much=
 better solution for these situations.</div><div class=3D"gmail_extra">-- <=
br><div data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=
=3D"ltr"><div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D=
"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a=
>&gt; =C2=A0<a href=3D"tel:%2B1-847-691-1404" value=3D"+18476911404" target=
=3D"_blank">+1-847-691-1404</a></div></div></div></div></div>
</div></div><span class=3D"">

<p></p>

-- <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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BM6guUio-Z2MzBVQZb%2BAabH884S=
Q_9bEQ0RbG1NbFCfxA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CAGg_6%2BM6guUio-Z2MzBVQZb%2BAabH884SQ_9bEQ0RbG1NbFCfxA%40mail.gma=
il.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAAbBDD_H0Uoo2FWc3jnvV5pJEoQbd6mYkRNo=
yZKv9kp6ihXNeA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAAbBDD_H0Uoo2FWc=
3jnvV5pJEoQbd6mYkRNoyZKv9kp6ihXNeA%40mail.gmail.com</a>.<br />

--94eb2c048d2464fb570536721126--

.

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

On 29 June 2016 at 23:13, Jonathan Coe <jbcoe@me.com> wrote:

> Suppose I call it [[empty]], does that change your thoughts at all?
>
> My weak aim is to help the optimizer and static analyzer. Weak motivating
> example follows:
>
> A foo() {
>   A a; // where we declared [[empty]] A() = default;
>   auto x = some_input();
>   if ( x == 0 ) a = f0();
>   if ( x != 0 ) a = f1();
>   return a;
> }
>
> A bar() {
>   A a; // where we declared [[empty]] A() = default;
>   auto x = some_input();
>   if ( x == 0 ) a = f0();
>   if ( x == 1 ) a = f1();
>   return a; // Compiler can warn about the potential return of an
> [[empty]] object
> }
>
> On 29 June 2016 at 23:02, Nevin Liber <nevin@eviloverlord.com> wrote:
>
>> On 29 June 2016 at 14:08, Jonathan Coe <jbcoe@me.com> wrote:
>>
>>> Sometimes default construction or move-from leaves an object in a state
>>> where it's no use for anything but later assignment.
>>
>>
>> Well, it isn't uninitialized, because you have to be able to destroy the
>> object.  We should discourage people from weaken their class invariants;
>> optional<T> is a much better solution for these situations.
>>
>
std::optional may be a bad fit because that type says, 'you have to check
it'.

I'm interested in cases where being in an empty (or 'uninitialized') state
is always a bug.



> --
>>  Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BM6guUio-Z2MzBVQZb%2BAabH884SQ_9bEQ0RbG1NbFCfxA%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BM6guUio-Z2MzBVQZb%2BAabH884SQ_9bEQ0RbG1NbFCfxA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAAbBDD_htg%3DTHdJBmdTd2PapdEA%3D9pJEJPU%2B9uwL1DDE%2BoEJXg%40mail.gmail.com.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 29 June 2016 at 23:13, Jonathan Coe <span dir=3D"ltr">&lt;<a href=3D=
"mailto:jbcoe@me.com" target=3D"_blank">jbcoe@me.com</a>&gt;</span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli=
d;padding-left:1ex"><div dir=3D"ltr">Suppose I call it [[empty]], does that=
 change your thoughts at all?<div><br></div><div>My weak aim is to help the=
 optimizer and static analyzer. Weak motivating example follows:</div><div>=
<br></div><div>A foo() {</div><div>=C2=A0 A a; // where we declared [[empty=
]] A() =3D default;</div><div>=C2=A0 auto x =3D some_input();</div><div>=C2=
=A0 if ( x =3D=3D 0 ) a =3D f0();</div><div>=C2=A0 if ( x !=3D 0 ) a =3D f1=
();<br></div><div>=C2=A0 return a;</div><div>}</div><div><br></div><div><di=
v>A bar() {</div><div>=C2=A0 A a; // where we declared [[empty]] A() =3D de=
fault;</div><div>=C2=A0 auto x =3D some_input();</div><div>=C2=A0 if ( x =
=3D=3D 0 ) a =3D f0();</div><div>=C2=A0 if ( x =3D=3D 1 ) a =3D f1();<br></=
div><div>=C2=A0 return a; // Compiler can warn about the potential return o=
f an [[empty]] object</div><div>}</div></div></div><div class=3D""><div cla=
ss=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 29 J=
une 2016 at 23:02, Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"mailto:nevi=
n@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-st=
yle:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><sp=
an>On 29 June 2016 at 14:08, Jonathan Coe <span dir=3D"ltr">&lt;<a href=3D"=
mailto:jbcoe@me.com" target=3D"_blank">jbcoe@me.com</a>&gt;</span> wrote:<b=
r><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,2=
04);border-left-style:solid;padding-left:1ex">Sometimes default constructio=
n or move-from leaves an object in a state where it&#39;s no use for anythi=
ng but later assignment.</blockquote></div><br></span>Well, it isn&#39;t un=
initialized, because you have to be able to destroy the object.=C2=A0 We sh=
ould discourage people from weaken their class invariants; optional&lt;T&gt=
; is a much better solution for these situations.</div></div></blockquote><=
/div></div></div></div></blockquote><div><br></div><div><div>std::optional =
may be a bad fit because that type says, &#39;you have to check it&#39;.<br=
></div><div><br></div><div>I&#39;m interested in cases where being in an em=
pty (or &#39;uninitialized&#39;) state is always a bug.</div></div><div><br=
></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b=
order-left-style:solid;padding-left:1ex"><div class=3D""><div class=3D"h5">=
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border=
-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div=
 dir=3D"ltr"><div class=3D"gmail_extra">-- <br><div data-smartmail=3D"gmail=
_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &quot;:=
-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" t=
arget=3D"_blank">nevin@eviloverlord.com</a>&gt; =C2=A0<a href=3D"tel:%2B1-8=
47-691-1404" value=3D"+18476911404" target=3D"_blank">+1-847-691-1404</a></=
div></div></div></div></div>
</div></div><span>

<p></p>

-- <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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BM6guUio-Z2MzBVQZb%2BAabH884S=
Q_9bEQ0RbG1NbFCfxA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CAGg_6%2BM6guUio-Z2MzBVQZb%2BAabH884SQ_9bEQ0RbG1NbFCfxA%40mail.gma=
il.com</a>.<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAAbBDD_htg%3DTHdJBmdTd2PapdEA%3D9pJE=
JPU%2B9uwL1DDE%2BoEJXg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAAbBDD_h=
tg%3DTHdJBmdTd2PapdEA%3D9pJEJPU%2B9uwL1DDE%2BoEJXg%40mail.gmail.com</a>.<br=
 />

--001a11409368aa61640536722566--

.

On quarta-feira, 29 de junho de 2016 23:13:48 PDT Jonathan Coe wrote:
> Suppose I call it [[empty]], does that change your thoughts at all?
>
> My weak aim is to help the optimizer and static analyzer.

Help doing what?

> A bar() {
>   A a; // where we declared [[empty]] A() = default;
>   auto x = some_input();
>   if ( x == 0 ) a = f0();
>   if ( x == 1 ) a = f1();
>   return a; // Compiler can warn about the potential return of an [[empty]]
> object
> }

Indeed it can. But the compiler already *does* warn in this case. So what's
the point of the attribute here?

I understand the attribute in the parameter of the move constructor, but if
that one is inline doing:

 A (A &&other) { swap(*this, other); }

Then the compiler should already warn on use of the moved-from object.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2719895.xNxzpsSCD4%40tjmaciei-mobl1.

.

------=_Part_506_1349695409.1467240407630
Content-Type: multipart/alternative;
 boundary="----=_Part_507_22898112.1467240407630"

------=_Part_507_22898112.1467240407630
Content-Type: text/plain; charset=UTF-8



On Wednesday, June 29, 2016 at 11:28:48 PM UTC+1, Thiago Macieira wrote:
>
> On quarta-feira, 29 de junho de 2016 23:13:48 PDT Jonathan Coe wrote:
> > Suppose I call it [[empty]], does that change your thoughts at all?
> >
> > My weak aim is to help the optimizer and static analyzer.
>
> Help doing what?
>
> > A bar() {
> >   A a; // where we declared [[empty]] A() = default;
> >   auto x = some_input();
> >   if ( x == 0 ) a = f0();
> >   if ( x == 1 ) a = f1();
> >   return a; // Compiler can warn about the potential return of an
> [[empty]]
> > object
> > }
>
> Indeed it can. But the compiler already *does* warn in this case. So
> what's


I'm not being very clear, sorry.
A in this case does have a default constructor that initializes all
members, it just puts it into an 'empty' state like a shared pointer with
no object or an empty matrix.
I don't think that the compiler can possibly know to warn in such case,
that's what the attribute could be helpful for.


> the point of the attribute here?
>
> I understand the attribute in the parameter of the move constructor, but
> if
> that one is inline doing:
>
>         A (A &&other) { swap(*this, other); }
>
> Then the compiler should already warn on use of the moved-from object.
>
>
I've not seen compiler warnings for use-after-move. I'll have to experiment
with this tomorrow.


> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/274f2eb2-d995-4991-b086-e654c14dc112%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Wednesday, June 29, 2016 at 11:28:48 PM UTC+1, =
Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On quart=
a-feira, 29 de junho de 2016 23:13:48 PDT Jonathan Coe wrote:
<br>&gt; Suppose I call it [[empty]], does that change your thoughts at all=
?
<br>&gt;=20
<br>&gt; My weak aim is to help the optimizer and static analyzer.=20
<br>
<br>Help doing what?
<br>
<br>&gt; A bar() {
<br>&gt; =C2=A0 A a; // where we declared [[empty]] A() =3D default;
<br>&gt; =C2=A0 auto x =3D some_input();
<br>&gt; =C2=A0 if ( x =3D=3D 0 ) a =3D f0();
<br>&gt; =C2=A0 if ( x =3D=3D 1 ) a =3D f1();
<br>&gt; =C2=A0 return a; // Compiler can warn about the potential return o=
f an [[empty]]
<br>&gt; object
<br>&gt; }
<br>
<br>Indeed it can. But the compiler already *does* warn in this case. So wh=
at&#39;s </blockquote><div><br></div><div>I&#39;m not being very clear, sor=
ry.</div><div>A in this case does have a default constructor that initializ=
es all members, it just puts it into an &#39;empty&#39; state like a shared=
 pointer with no object or an empty matrix.</div><div>I don&#39;t think tha=
t the compiler can possibly know to warn in such case, that&#39;s what the =
attribute could be helpful for.</div><div><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;">
<br>the point of the attribute here?
<br>
<br>I understand the attribute in the parameter of the move constructor, bu=
t if=20
<br>that one is inline doing:
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0A (A &amp;&amp;other) {=
 swap(*this, other); }
<br>
<br>Then the compiler should already warn on use of the moved-from object.
<br>
<br></blockquote><div><br></div><div>I&#39;ve not seen compiler warnings fo=
r use-after-move. I&#39;ll have to experiment with this tomorrow.</div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/274f2eb2-d995-4991-b086-e654c14dc112%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/274f2eb2-d995-4991-b086-e654c14dc112=
%40isocpp.org</a>.<br />

------=_Part_507_22898112.1467240407630--

------=_Part_506_1349695409.1467240407630--

.

On quarta-feira, 29 de junho de 2016 15:46:47 PDT Jonathan Coe wrote:
> I'm not being very clear, sorry.
> A in this case does have a default constructor that initializes all
> members, it just puts it into an 'empty' state like a shared pointer with
> no object or an empty matrix.
> I don't think that the compiler can possibly know to warn in such case,
> that's what the attribute could be helpful for.

So you're saying that this constructor is not trivial but leaves the object in
a state that is not useful. Correct?

Why are you doing that in the first place?

> > the point of the attribute here?
> >
> > I understand the attribute in the parameter of the move constructor, but
> > if
> >
> > that one is inline doing:
> >         A (A &&other) { swap(*this, other); }
> >
> > Then the compiler should already warn on use of the moved-from object.
>
> I've not seen compiler warnings for use-after-move. I'll have to experiment
> with this tomorrow.

That kind of new warning, possibly with an attribute would be nice.


--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2121825.pRQqcVa9VF%40tjmaciei-mobl1.

.

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

On 29 June 2016 at 17:46, Jonathan Coe <jonathanbcoe@gmail.com> wrote:

>
>
> On Wednesday, June 29, 2016 at 11:28:48 PM UTC+1, Thiago Macieira wrote:
>>
>> On quarta-feira, 29 de junho de 2016 23:13:48 PDT Jonathan Coe wrote:
>> > Suppose I call it [[empty]], does that change your thoughts at all?
>> >
>> > My weak aim is to help the optimizer and static analyzer.
>>
>> Help doing what?
>>
>> > A bar() {
>> >   A a; // where we declared [[empty]] A() = default;
>> >   auto x = some_input();
>> >   if ( x == 0 ) a = f0();
>> >   if ( x == 1 ) a = f1();
>> >   return a; // Compiler can warn about the potential return of an
>> [[empty]]
>> > object
>> > }
>>
>> Indeed it can. But the compiler already *does* warn in this case. So
>> what's
>
>
> I'm not being very clear, sorry.
> A in this case does have a default constructor that initializes all
> members, it just puts it into an 'empty' state like a shared pointer with
> no object or an empty matrix.
>

But on a shared_ptr I can still call .get() on it, copy it, etc.
Basically, I can call any function that doesn't have a precondition.

You are looking for something far more restrictive than this.  It looks
like you are doing so for the two-phase construction anti-pattern.

It's actually worse than that, as you can normally copy, move, etc. things
on objects in a weakened invariant state, all of which you want to
restrict.  Even the following code becomes problematic:

vector<T> v(1);
v.emplace_back();

As the emplace_back may have to move/copy the objects that it already holds.

It's the same reason we didn't want std::variant to be default constructed
into the invalid state.

The invalid state in std::variant only exists as a compromise to get some
kind of discriminated union into the standard.  We should not encourage
that design for other things.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMOL8S0ezKaC%3D4P-prQF-ONthgJ-ae8j4S4KHNPgXEVsg%40mail.gmail.com.

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

<div dir=3D"ltr">On 29 June 2016 at 17:46, Jonathan Coe <span dir=3D"ltr">&=
lt;<a href=3D"mailto:jonathanbcoe@gmail.com" target=3D"_blank">jonathanbcoe=
@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span clas=
s=3D""><br><br>On Wednesday, June 29, 2016 at 11:28:48 PM UTC+1, Thiago Mac=
ieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On quarta-feira, 29 de =
junho de 2016 23:13:48 PDT Jonathan Coe wrote:
<br>&gt; Suppose I call it [[empty]], does that change your thoughts at all=
?
<br>&gt;=20
<br>&gt; My weak aim is to help the optimizer and static analyzer.=20
<br>
<br>Help doing what?
<br>
<br>&gt; A bar() {
<br>&gt; =C2=A0 A a; // where we declared [[empty]] A() =3D default;
<br>&gt; =C2=A0 auto x =3D some_input();
<br>&gt; =C2=A0 if ( x =3D=3D 0 ) a =3D f0();
<br>&gt; =C2=A0 if ( x =3D=3D 1 ) a =3D f1();
<br>&gt; =C2=A0 return a; // Compiler can warn about the potential return o=
f an [[empty]]
<br>&gt; object
<br>&gt; }
<br>
<br>Indeed it can. But the compiler already *does* warn in this case. So wh=
at&#39;s </blockquote><div><br></div></span><div>I&#39;m not being very cle=
ar, sorry.</div><div>A in this case does have a default constructor that in=
itializes all members, it just puts it into an &#39;empty&#39; state like a=
 shared pointer with no object or an empty matrix.</div></div></blockquote>=
<div><br></div><div>But on a shared_ptr I can still call .get() on it, copy=
 it, etc.=C2=A0 Basically, I can call any function that doesn&#39;t have a =
precondition.</div><div><br></div><div>You are looking for something far mo=
re restrictive than this.=C2=A0 It looks like you are doing so for the two-=
phase construction anti-pattern.</div><div><br></div><div>It&#39;s actually=
 worse than that, as you can normally copy, move, etc. things on objects in=
 a weakened invariant state, all of which you want to restrict.=C2=A0 Even =
the following code becomes problematic:</div><div><br></div><div>vector&lt;=
T&gt; v(1);</div><div>v.emplace_back();</div><div><br></div><div>As the emp=
lace_back may have to move/copy the objects that it already holds.</div><di=
v><br></div><div>It&#39;s the same reason we didn&#39;t want std::variant t=
o be default constructed into the invalid state.</div><div><br></div><div>T=
he invalid state in std::variant only exists as a compromise to get some ki=
nd of discriminated union into the standard.=C2=A0 We should not encourage =
that design for other things.</div></div>-- <br><div class=3D"gmail_signatu=
re" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"lt=
r"><div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailt=
o:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt; =
=C2=A0+1-847-691-1404</div></div></div></div></div>
</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMOL8S0ezKaC%3D4P-prQF-ONthgJ=
-ae8j4S4KHNPgXEVsg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMOL8=
S0ezKaC%3D4P-prQF-ONthgJ-ae8j4S4KHNPgXEVsg%40mail.gmail.com</a>.<br />

--001a113fd41c129d390536761dcf--

.

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

On 29 June 2016 at 17:19, Jonathan Coe <jbcoe@me.com> wrote:

>
>
>
>>> Well, it isn't uninitialized, because you have to be able to destroy the
>>> object.  We should discourage people from weaken their class invariants;
>>> optional<T> is a much better solution for these situations.
>>>
>>
> std::optional may be a bad fit because that type says, 'you have to check
> it'.
>

You don't have to check it.  Take dereferencing: as long as your code can
establish that the optional is engaged, you  can dereference it, as in:

optional<T> ot;
//...
ot = T(0);
cout << *ot << endl;

No checking required.


> I'm interested in cases where being in an empty (or 'uninitialized') state
> is always a bug.
>

If it is always a bug, don't make that a valid state of your object.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNmPPHoVgZfYb-pM%2BsnYOH4ro7P3J8kgMtWc%3DjK-mL9Lw%40mail.gmail.com.

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

<div dir=3D"ltr">On 29 June 2016 at 17:19, Jonathan Coe <span dir=3D"ltr">&=
lt;<a href=3D"mailto:jbcoe@me.com" target=3D"_blank">jbcoe@me.com</a>&gt;</=
span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_extra"><=
br><div class=3D"gmail_quote"><span class=3D""><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-c=
olor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><=
div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-=
left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div =
dir=3D"ltr"><div class=3D"gmail_extra"><span><br></span>Well, it isn&#39;t =
uninitialized, because you have to be able to destroy the object.=C2=A0 We =
should discourage people from weaken their class invariants; optional&lt;T&=
gt; is a much better solution for these situations.</div></div></blockquote=
></div></div></div></div></blockquote><div><br></div></span><div><div>std::=
optional may be a bad fit because that type says, &#39;you have to check it=
&#39;.<br></div></div></div></div></div></blockquote><div><br></div><div>Yo=
u don&#39;t have to check it.=C2=A0 Take dereferencing: as long as your cod=
e can establish that the optional is engaged, you =C2=A0can dereference it,=
 as in:</div><div><br></div><div>optional&lt;T&gt; ot;</div><div>//...</div=
><div>ot =3D T(0);</div><div>cout &lt;&lt; *ot &lt;&lt; endl;</div><div><br=
></div><div>No checking required.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><div></div><div>I&#39;m interested in cases where being in an emp=
ty (or &#39;uninitialized&#39;) state is always a bug.<br></div></div></div=
></div></blockquote><div><br></div><div>If it is always a bug, don&#39;t ma=
ke that a valid state of your object.</div></div>-- <br><div class=3D"gmail=
_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div d=
ir=3D"ltr"><div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=
=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com=
</a>&gt; =C2=A0+1-847-691-1404</div></div></div></div></div>
</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNmPPHoVgZfYb-pM%2BsnYOH4ro7P=
3J8kgMtWc%3DjK-mL9Lw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNm=
PPHoVgZfYb-pM%2BsnYOH4ro7P3J8kgMtWc%3DjK-mL9Lw%40mail.gmail.com</a>.<br />

--001a1145f528ea2cef0536762a36--

.

------=_Part_3942_880700945.1467281695699
Content-Type: multipart/alternative;
 boundary="----=_Part_3943_394096437.1467281695709"

------=_Part_3943_394096437.1467281695709
Content-Type: text/plain; charset=UTF-8

This is a problem with objects that have "special" states in general, so
one option is to avoid designing objects like that when possible. To have
static analyzers be able to determine that an object is in a potentially
invalid state at compile time would not be easy for custom types.

For example

int* p = nullptr;
int i;

if (someCondition)
    p = &i;

*p = 8;

is easy to analyze since int* is not a custom type and the analyzer knows
that dereferencing a null pointer is a bug.

Now consider

vector<int> ints;

if (someCondition)
   ints.push_back(1);

ints.pop_back();

for an analyzer to determine that pop_back has a pre-condition that
!vector::empty(), and that the default constructor creates an empty vector,
we need something more than a [[empty]] or [[uninitialized]] attribute.

One option would be to specify the state required to call a method and the
state the instance is in after the method call but that would be very
verbose IMO. Maybe something like:

class VoidPointer
{
public:
    [[post_state="null"]] explicit VoidPointer() = default;
    [[post_state="null"]] explicit VoidPointer(nullptr_t);
    explicit VoidPointer(void*);

    [[pre_state!="null"]] void* get() const;

    [[post_state="null"]] void reset();

    ...
};

{
    VoidPointer p(nullptr);
    p.get(); // error
}

{
    void* vp = nullptr;
    VoidPointer p(vp);
    p.get(); // no error? VoidPointer(void*) does not specify post_state.
}

To me, it just seems like a lot of work for not that much gain but it does
have the upside of documenting the pre-requirements and post-state in code.

On Wednesday, June 29, 2016 at 10:08:12 PM UTC+3, Jonathan Coe wrote:
>
> Sometimes default construction or move-from leaves an object in a state
> where it's no use for anything but later assignment. It would be handy to
> have an attribute to signify this and help static analyzers.
>
> Any thoughts?
>
> 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c6050305-e867-4227-b64a-e451cd925105%40isocpp.org.

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

<div dir=3D"ltr">This is a problem with objects that have &quot;special&quo=
t; states in general, so one option is to avoid designing objects like that=
 when possible. To have static analyzers be able to determine that an objec=
t is in a potentially invalid state at compile time would not be easy for c=
ustom types.<div><br></div><div>For example</div><div><br></div><div><div c=
lass=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wr=
ap: break-word; background-color: rgb(250, 250, 250);"><code class=3D"prett=
yprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D=
"styled-by-prettify">int</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> p </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">nullptr</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> i</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br><br></span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">if</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">someConditi=
on</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0=
 p </span><font color=3D"#666600"><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">i</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></font><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">p </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">8</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">;</span></div></code></div><br>is easy to analyze since int* is not a=
 custom type and the analyzer knows that dereferencing a null pointer is a =
bug.=C2=A0</div><div><br></div><div>Now consider</div><div><br></div><div><=
div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); wo=
rd-wrap: break-word; background-color: rgb(250, 250, 250);"><code class=3D"=
prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">vector</span><span style=3D"color: #080;" class=
=3D"styled-by-prettify">&lt;int&gt;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> ints</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">if</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">someCondition</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0ints</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">push_back</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #066;" class=3D"styled-by-prettify">1</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br><br>ints</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">pop_back</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">();</span><font color=3D"#666600"></font></div></code></d=
iv><br>for an analyzer to determine that pop_back has a pre-condition that =
!vector::empty(), and that the default constructor creates an empty vector,=
 we need something more than a [[empty]] or [[uninitialized]] attribute.</d=
iv><div><br></div><div>One option would be to specify the state required to=
 call a method and the state the instance is in after the method call but t=
hat would be very verbose IMO. Maybe something like:</div><div><br></div><d=
iv><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187)=
; word-wrap: break-word; background-color: rgb(250, 250, 250);"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styl=
ed-by-prettify">VoidPointer</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">publ=
ic</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0=
 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">[[</span>=
<font color=3D"#000088"><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">post_state</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">=3D</span><span style=3D"color: #080;" class=3D"styled-by-prettify">=
&quot;null&quot;</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">]]</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">explicit</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #606;" class=3D"styled-by-prettify">VoidPointer</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">default</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span></font><span style=3D"color: #000;" class=3D"styled-=
by-prettify">=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">[[</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">post_state</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">=3D</span><span style=3D"color: #080;" class=3D"styled-by-prettify=
">&quot;null&quot;</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">]]</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">explicit<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #606;" class=3D"styled-by-prettify">VoidPointer</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">nullptr_t</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">explicit</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">VoidPointer</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">void</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">*);</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">[[</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">pre_state</span><font color=3D"#008800"><span style=3D=
"color: #660;" class=3D"styled-by-prettify">!=3D</span><span style=3D"color=
: #080;" class=3D"styled-by-prettify">&quot;null&quot;</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">]]</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">void</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">*</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">get</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br></span></font><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">[[</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">post_state</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #0=
80;" class=3D"styled-by-prettify">&quot;null&quot;</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">]]</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> reset</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">()</span><font color=3D"#000000"><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br></span></font><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">...</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br><br></span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>=C2=A0 =C2=A0 </span><span style=3D"color: #606;" class=3D"styled-by-pr=
ettify">VoidPointer</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> p</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">nullptr<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 p=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">get</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #80=
0;" class=3D"styled-by-prettify">// error</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br><br></span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">void</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> v=
p </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">nullptr</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">VoidPointer</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> p</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">vp</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>=C2=A0 =C2=A0 p</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">.</span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">get</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">();</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// no e=
rror? VoidPointer(void*) does not specify post_state.</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">}</span></div></code></div><br>To me, =
it just seems like a lot of work for not that much gain but it does have th=
e upside of documenting the pre-requirements and post-state in code.<br><br=
>On Wednesday, June 29, 2016 at 10:08:12 PM UTC+3, Jonathan Coe wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Sometimes default =
construction or move-from leaves an object in a state where it&#39;s no use=
 for anything but later assignment. It would be handy to have an attribute =
to signify this and help static analyzers.<div><br></div><div>Any thoughts?=
</div><div><br></div><div>Jon</div></div>
</blockquote></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c6050305-e867-4227-b64a-e451cd925105%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c6050305-e867-4227-b64a-e451cd925105=
%40isocpp.org</a>.<br />

------=_Part_3943_394096437.1467281695709--

------=_Part_3942_880700945.1467281695699--

.

On 2016-06-29 19:47, Thiago Macieira wrote:
> So you're saying that this constructor is not trivial but leaves the object in
> a state that is not useful. Correct?
>
> Why are you doing that in the first place?

....performance? You're familiar with Eigen, yes? (Most Eigen types, or
at least the ubiquitous Matrix type in all its incarnations, does this;
if you just default-construct it, the contents are undefined. I've been
bitten by this before, so I can relate to the desire to be able to warn
about it.)

TBH I'm not sure I agree with this behavior, but some people obviously
think it's useful.

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nl3819%24jjm%241%40ger.gmane.org.

.

On quinta-feira, 30 de junho de 2016 09:49:29 PDT Matthew Woehlke wrote:
> On 2016-06-29 19:47, Thiago Macieira wrote:
> > So you're saying that this constructor is not trivial but leaves the
> > object in a state that is not useful. Correct?
> >
> > Why are you doing that in the first place?
>
> ...performance? You're familiar with Eigen, yes? (Most Eigen types, or
> at least the ubiquitous Matrix type in all its incarnations, does this;
> if you just default-construct it, the contents are undefined. I've been
> bitten by this before, so I can relate to the desire to be able to warn
> about it.)

Those constructors are usually trivial.

I'm asking about why have a non-trivial constructor that leaves the object in
an unusable state.

> TBH I'm not sure I agree with this behavior, but some people obviously
> think it's useful.


--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/33370469.tDjGk97ozn%40tjmaciei-mobl1.

.

On 2016-06-30 11:03, Thiago Macieira wrote:
> On quinta-feira, 30 de junho de 2016 09:49:29 PDT Matthew Woehlke wrote:
>> On 2016-06-29 19:47, Thiago Macieira wrote:
>>> So you're saying that this constructor is not trivial but leaves the
>>> object in a state that is not useful. Correct?
>>>
>>> Why are you doing that in the first place?
>>
>> ...performance? You're familiar with Eigen, yes? (Most Eigen types, or
>> at least the ubiquitous Matrix type in all its incarnations, does this;
>> if you just default-construct it, the contents are undefined. I've been
>> bitten by this before, so I can relate to the desire to be able to warn
>> about it.)
>
> Those constructors are usually trivial.
>
> I'm asking about why have a non-trivial constructor that leaves the object in
> an unusable state.

Define "unusable". I don't think we're talking about cases where the
object is actually "unusable", just where its state is "unspecified".

For example, QImage(int width, int height, Format format):

  "This will create a QImage with uninitialized data."

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nl3h1n%24ekb%241%40ger.gmane.org.

.

On quinta-feira, 30 de junho de 2016 12:23:19 PDT Matthew Woehlke wrote:
> > I'm asking about why have a non-trivial constructor that leaves the object
> > in an unusable state.
>
> Define "unusable". I don't think we're talking about cases where the
> object is actually "unusable", just where its state is "unspecified".
>
> For example, QImage(int width, int height, Format format):
>
>   "This will create a QImage with uninitialized data."

Which is a valid state and the compiler should not warn about.

The example from the OP was more like "any use you make of this prior to
assigning a new object will have unspecified results". It would be akin to
having a std::vector created, but the size left uninitialised.


--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1984403.4isUTqnnaS%40tjmaciei-mobl1.

.

On 2016-06-30 13:04, Thiago Macieira wrote:
> On quinta-feira, 30 de junho de 2016 12:23:19 PDT Matthew Woehlke wrote:
>>> I'm asking about why have a non-trivial constructor that leaves the object
>>> in an unusable state.
>>
>> Define "unusable". I don't think we're talking about cases where the
>> object is actually "unusable", just where its state is "unspecified".
>>
>> For example, QImage(int width, int height, Format format):
>>
>>   "This will create a QImage with uninitialized data."
>
> Which is a valid state and the compiler should not warn about.
>
> The example from the OP was more like "any use you make of this prior to
> assigning a new object will have unspecified results". It would be akin to
> having a std::vector created, but the size left uninitialised.

Uh... yeah?

  int i;
  qDebug() << i; // warning; 'i' is uninitialized
  QImage image(64, 64, Qimage::Format_ARGB32);
  qDebug() << image.pixel(0, 0); // warning; 'image' is uninitialized

The first warning exists. As I read it, the OP would like the second to
also warn. (You'd need to know what functions fully initialize the
object, though; this probably would not be easy to implement.)

And the above *does* have unspecified results, at least in that the
value you get is unspecified.

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nl3ooe%24fmv%241%40ger.gmane.org.

.

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

On 30 June 2016 at 19:34, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:

> On 2016-06-30 13:04, Thiago Macieira wrote:
> > On quinta-feira, 30 de junho de 2016 12:23:19 PDT Matthew Woehlke wrote:
> >>> I'm asking about why have a non-trivial constructor that leaves the
> object
> >>> in an unusable state.
> >>
> >> Define "unusable". I don't think we're talking about cases where the
> >> object is actually "unusable", just where its state is "unspecified".
> >>
> >> For example, QImage(int width, int height, Format format):
> >>
> >>   "This will create a QImage with uninitialized data."
> >
> > Which is a valid state and the compiler should not warn about.
> >
> > The example from the OP was more like "any use you make of this prior to
> > assigning a new object will have unspecified results". It would be akin
> to
> > having a std::vector created, but the size left uninitialised.
>
>
The example I had in mind was just an undesirable state that coding
convention assumes (or hopes) the object won't be found in. I've seen the
null state of shared pointers (rightly or otherwise) treated in such a
manner.

'Undesirable' covers 'uninitialised' and "any use you make of this prior to
assigning a new object will have unspecified results".


> Uh... yeah?
>
>   int i;
>   qDebug() << i; // warning; 'i' is uninitialized
>   QImage image(64, 64, Qimage::Format_ARGB32);
>   qDebug() << image.pixel(0, 0); // warning; 'image' is uninitialized
>
> The first warning exists. As I read it, the OP would like the second to
> also warn. (You'd need to know what functions fully initialize the
> object, though; this probably would not be easy to implement.)
>
>
I really only had the default constructor and move-construction/-assignment
in mind.


> And the above *does* have unspecified results, at least in that the
> value you get is unspecified.
>
> --
> Matthew
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nl3ooe%24fmv%241%40ger.gmane.org
> .
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAAbBDD8Yx4zP93Yx_OLxcyvitzOM26-NiL2LajbJvKs1CeM4Vw%40mail.gmail.com.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 30 June 2016 at 19:34, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex"><span class=3D"">On 2016-06-=
30 13:04, Thiago Macieira wrote:<br>
&gt; On quinta-feira, 30 de junho de 2016 12:23:19 PDT Matthew Woehlke wrot=
e:<br>
&gt;&gt;&gt; I&#39;m asking about why have a non-trivial constructor that l=
eaves the object<br>
&gt;&gt;&gt; in an unusable state.<br>
&gt;&gt;<br>
&gt;&gt; Define &quot;unusable&quot;. I don&#39;t think we&#39;re talking a=
bout cases where the<br>
&gt;&gt; object is actually &quot;unusable&quot;, just where its state is &=
quot;unspecified&quot;.<br>
&gt;&gt;<br>
&gt;&gt; For example, QImage(int width, int height, Format format):<br>
&gt;&gt;<br>
&gt;&gt;=C2=A0 =C2=A0&quot;This will create a QImage with uninitialized dat=
a.&quot;<br>
&gt;<br>
&gt; Which is a valid state and the compiler should not warn about.<br>
&gt;<br>
&gt; The example from the OP was more like &quot;any use you make of this p=
rior to<br>
&gt; assigning a new object will have unspecified results&quot;. It would b=
e akin to<br>
&gt; having a std::vector created, but the size left uninitialised.<br>
<br></span></blockquote><div><br></div><div>The example I had in mind was j=
ust an undesirable state that coding convention assumes (or hopes) the obje=
ct won&#39;t be found in. I&#39;ve seen the null state of shared pointers (=
rightly or otherwise) treated in such a manner.=C2=A0</div><div><br></div><=
div>&#39;Undesirable&#39; covers &#39;uninitialised&#39; and &quot;any use =
you make of this prior to</div>assigning a new object will have unspecified=
 results&quot;.<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,20=
4,204);border-left-style:solid;padding-left:1ex"><span class=3D"">
</span>Uh... yeah?<br>
<br>
=C2=A0 int i;<br>
=C2=A0 qDebug() &lt;&lt; i; // warning; &#39;i&#39; is uninitialized<br>
=C2=A0 QImage image(64, 64, Qimage::Format_ARGB32);<br>
=C2=A0 qDebug() &lt;&lt; image.pixel(0, 0); // warning; &#39;image&#39; is =
uninitialized<br>
<br>
The first warning exists. As I read it, the OP would like the second to<br>
also warn. (You&#39;d need to know what functions fully initialize the<br>
object, though; this probably would not be easy to implement.)<br>
<br></blockquote><div><br></div><div>I really only had the default construc=
tor and move-construction/-assignment in mind.</div><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding=
-left:1ex">
And the above *does* have unspecified results, at least in that the<br>
value you get is unspecified.<br>
<br>
--<br>
Matthew<br>
<span class=3D""><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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/nl3ooe%24fmv%241%40ger.gmane.o=
rg" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/nl3ooe%24fmv%241%40ger.gmane.org</a>.<br>
</blockquote></div><br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAAbBDD8Yx4zP93Yx_OLxcyvitzOM26-NiL2L=
ajbJvKs1CeM4Vw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAAbBDD8Yx4zP93Yx=
_OLxcyvitzOM26-NiL2LajbJvKs1CeM4Vw%40mail.gmail.com</a>.<br />

--001a11429012e2585f053685abcd--

.

------=_Part_5777_888589017.1467325579962
Content-Type: multipart/alternative;
 boundary="----=_Part_5778_1479362546.1467325579962"

------=_Part_5778_1479362546.1467325579962
Content-Type: text/plain; charset=UTF-8

Perhaps the correct name for such an attribute would be [[unspecified]] as
in:

[[unspecified]] atomic() = default;

There are many places in the standard where objects are in an "unspecified"
state (i.e. after being moved from, trivial constructors, state of object
after an exception for the basic exception guarantee). It would be great of
compilers could be told to warn about some set of operations on objects in
this state (EoP refers to this as the partially-formed state). A value in
an unspecified state has no meaning, at the very least it would be nice to
get a compiler warning if the object is read from.

I'm in favor of only allowing destruction and assigning to an object in an
unspecified state. I know others have argued that member functions, like
vector::clear(), which are equivalent to assignment should be allowed but I
don't see any compelling argument for this. There should probably be an
attribute to specify that an object satisfies the strong exception
guarantee (as basic is assumed).  [[unspecified]] should also be the
assumed as the default for moved from objects.

Having such an attribute that compilers could enforce might well alleviate
some of the damage done by the current "valid but unspecified" language in
the standard. We cannot have both efficiency and safety, provably, and so
we need to learn how to take a structured approach for dealing with unsafe
operations (like move).
<http://sean-parent.github.io/2014/05/30/about-move/> (there is also
related info in my "Better Code" talk
<https://github.com/sean-parent/sean-parent.github.io/wiki/Papers-and-Presentations>.

I have not done the work to know the pros/cons of such an attribute but I
think it is worth consideration.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/07935905-b804-49f2-9f2b-6684a29bf67a%40isocpp.org.

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

<div dir=3D"ltr">Perhaps the correct name for such an attribute would be [[=
unspecified]] as in:<div><br></div><div>[[unspecified]] atomic() =3D defaul=
t;</div><div><br></div><div>There are many places in the standard where obj=
ects are in an &quot;unspecified&quot; state (i.e. after being moved from, =
trivial constructors, state of object after an exception for the basic exce=
ption guarantee). It would be great of compilers could be told to warn abou=
t some set of operations on objects in this state (EoP refers to this as th=
e partially-formed state). A value in an unspecified state has no meaning, =
at the very least it would be nice to get a compiler warning if the object =
is read from.</div><div><br></div><div>I&#39;m in favor of only allowing de=
struction and assigning to an object in an unspecified state. I know others=
 have argued that member functions, like vector::clear(), which are equival=
ent to assignment should be allowed but I don&#39;t see any compelling argu=
ment for this. There should probably be an attribute to specify that an obj=
ect satisfies the strong exception guarantee (as basic is assumed). =C2=A0[=
[unspecified]] should also be the assumed as the default for moved from obj=
ects.</div><div><br></div><div>Having such an attribute that compilers coul=
d enforce might well alleviate some of the damage done by the current &quot=
;valid but unspecified&quot; language in the standard. We cannot have both =
efficiency and safety, provably, and so we need to learn how to take a stru=
ctured approach for dealing with unsafe operations (like move). &lt;http://=
sean-parent.github.io/2014/05/30/about-move/&gt; (there is also related inf=
o in my &quot;Better Code&quot; talk &lt;https://github.com/sean-parent/sea=
n-parent.github.io/wiki/Papers-and-Presentations&gt;.</div><div><br></div><=
div>I have not done the work to know the pros/cons of such an attribute but=
 I think it is worth consideration.</div><div><br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/07935905-b804-49f2-9f2b-6684a29bf67a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/07935905-b804-49f2-9f2b-6684a29bf67a=
%40isocpp.org</a>.<br />

------=_Part_5778_1479362546.1467325579962--

------=_Part_5777_888589017.1467325579962--

.

------=_Part_9413_1115302934.1467329462395
Content-Type: multipart/alternative;
 boundary="----=_Part_9414_1904920250.1467329462396"

------=_Part_9414_1904920250.1467329462396
Content-Type: text/plain; charset=UTF-8

On Thursday, June 30, 2016 at 6:26:20 PM UTC-4, sean....@gmail.com wrote:
>
> Perhaps the correct name for such an attribute would be [[unspecified]] as
> in:
>
> [[unspecified]] atomic() = default;
>
> There are many places in the standard where objects are in an
> "unspecified" state (i.e. after being moved from, trivial constructors,
> state of object after an exception for the basic exception guarantee). It
> would be great of compilers could be told to warn about some set of
> operations on objects in this state (EoP refers to this as the
> partially-formed state). A value in an unspecified state has no meaning, at
> the very least it would be nice to get a compiler warning if the object is
> read from.
>
> I'm in favor of only allowing destruction and assigning to an object in an
> unspecified state. I know others have argued that member functions, like
> vector::clear(), which are equivalent to assignment should be allowed but I
> don't see any compelling argument for this. There should probably be an
> attribute to specify that an object satisfies the strong exception
> guarantee (as basic is assumed).  [[unspecified]] should also be the
> assumed as the default for moved from objects.
>
> Having such an attribute that compilers could enforce might well alleviate
> some of the damage done by the current "valid but unspecified" language in
> the standard. We cannot have both efficiency and safety, provably, and so
> we need to learn how to take a structured approach for dealing with unsafe
> operations (like move). <
> http://sean-parent.github.io/2014/05/30/about-move/> (there is also
> related info in my "Better Code" talk <
> https://github.com/sean-parent/sean-parent.github.io/wiki/Papers-and-Presentations
> >.
>
> I have not done the work to know the pros/cons of such an attribute but I
> think it is worth consideration.
>

This is all stuff that I think would be better handled in a proper
contracts system. That would allow us to handle calling `clear` and other
functions on a moved-from `vector`, where appropriate. Indeed, it would
allow us to state up-front all kinds of things, not just dealing with
whether the state of an object is "valid-but-unspecified".

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/97b9dea2-98ca-4773-a878-6fee26ca0eea%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, June 30, 2016 at 6:26:20 PM UTC-4, sean....@g=
mail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
">Perhaps the correct name for such an attribute would be [[unspecified]] a=
s in:<div><br></div><div>[[unspecified]] atomic() =3D default;</div><div><b=
r></div><div>There are many places in the standard where objects are in an =
&quot;unspecified&quot; state (i.e. after being moved from, trivial constru=
ctors, state of object after an exception for the basic exception guarantee=
). It would be great of compilers could be told to warn about some set of o=
perations on objects in this state (EoP refers to this as the partially-for=
med state). A value in an unspecified state has no meaning, at the very lea=
st it would be nice to get a compiler warning if the object is read from.</=
div><div><br></div><div>I&#39;m in favor of only allowing destruction and a=
ssigning to an object in an unspecified state. I know others have argued th=
at member functions, like vector::clear(), which are equivalent to assignme=
nt should be allowed but I don&#39;t see any compelling argument for this. =
There should probably be an attribute to specify that an object satisfies t=
he strong exception guarantee (as basic is assumed). =C2=A0[[unspecified]] =
should also be the assumed as the default for moved from objects.</div><div=
><br></div><div>Having such an attribute that compilers could enforce might=
 well alleviate some of the damage done by the current &quot;valid but unsp=
ecified&quot; language in the standard. We cannot have both efficiency and =
safety, provably, and so we need to learn how to take a structured approach=
 for dealing with unsafe operations (like move). &lt;<a href=3D"http://sean=
-parent.github.io/2014/05/30/about-move/" target=3D"_blank" rel=3D"nofollow=
" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F=
%2Fsean-parent.github.io%2F2014%2F05%2F30%2Fabout-move%2F\x26sa\x3dD\x26snt=
z\x3d1\x26usg\x3dAFQjCNEDLFq29Ih3idGpBJaqebMc5gqkEg&#39;;return true;" oncl=
ick=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fsean-pa=
rent.github.io%2F2014%2F05%2F30%2Fabout-move%2F\x26sa\x3dD\x26sntz\x3d1\x26=
usg\x3dAFQjCNEDLFq29Ih3idGpBJaqebMc5gqkEg&#39;;return true;">http://sean-pa=
rent.github.io/<wbr>2014/05/30/about-move/</a>&gt; (there is also related i=
nfo in my &quot;Better Code&quot; talk &lt;<a href=3D"https://github.com/se=
an-parent/sean-parent.github.io/wiki/Papers-and-Presentations" target=3D"_b=
lank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.c=
om/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fsean-parent%2Fsean-parent.github.io%=
2Fwiki%2FPapers-and-Presentations\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
kkU4fL-v9qZ2-tMSr6kaLLFkHSg&#39;;return true;" onclick=3D"this.href=3D&#39;=
https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fsean-parent%2Fse=
an-parent.github.io%2Fwiki%2FPapers-and-Presentations\x26sa\x3dD\x26sntz\x3=
d1\x26usg\x3dAFQjCNHkkU4fL-v9qZ2-tMSr6kaLLFkHSg&#39;;return true;">https://=
github.com/sean-<wbr>parent/sean-parent.github.io/<wbr>wiki/Papers-and-Pres=
entations</a>&gt;<wbr>.</div><div><br></div><div>I have not done the work t=
o know the pros/cons of such an attribute but I think it is worth considera=
tion.</div></div></blockquote><div><br>This is all stuff that I think would=
 be better handled in a proper contracts system. That would allow us to han=
dle calling `clear` and other functions on a moved-from `vector`, where app=
ropriate. Indeed, it would allow us to state up-front all kinds of things, =
not just dealing with whether the state of an object is &quot;valid-but-uns=
pecified&quot;.<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/97b9dea2-98ca-4773-a878-6fee26ca0eea%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/97b9dea2-98ca-4773-a878-6fee26ca0eea=
%40isocpp.org</a>.<br />

------=_Part_9414_1904920250.1467329462396--

------=_Part_9413_1115302934.1467329462395--

.

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

Is there an existing contract system that would have these capabilities for
static analysis? How would you state "if this member function throws an
exception then the object is left in a partially-formed state" with a
contract system? Every contract system I'm aware of consists of runtime
checks - there is no runtime check one can make to say "is this value
unspecified?" - the answer, by definition, is undefined.

Although I could imagine [[ensures: unspecified()]] where unspecified() is
some magic built in function - that would seem to be an abuse of a contract
system.

The problem is much closer to a concept issue than one of contracts.
Sean

On Thu, Jun 30, 2016 at 4:31 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Thursday, June 30, 2016 at 6:26:20 PM UTC-4, sean....@gmail.com wrote:
>>
>> Perhaps the correct name for such an attribute would be [[unspecified]]
>> as in:
>>
>> [[unspecified]] atomic() = default;
>>
>> There are many places in the standard where objects are in an
>> "unspecified" state (i.e. after being moved from, trivial constructors,
>> state of object after an exception for the basic exception guarantee). It
>> would be great of compilers could be told to warn about some set of
>> operations on objects in this state (EoP refers to this as the
>> partially-formed state). A value in an unspecified state has no meaning, at
>> the very least it would be nice to get a compiler warning if the object is
>> read from.
>>
>> I'm in favor of only allowing destruction and assigning to an object in
>> an unspecified state. I know others have argued that member functions, like
>> vector::clear(), which are equivalent to assignment should be allowed but I
>> don't see any compelling argument for this. There should probably be an
>> attribute to specify that an object satisfies the strong exception
>> guarantee (as basic is assumed).  [[unspecified]] should also be the
>> assumed as the default for moved from objects.
>>
>> Having such an attribute that compilers could enforce might well
>> alleviate some of the damage done by the current "valid but unspecified"
>> language in the standard. We cannot have both efficiency and safety,
>> provably, and so we need to learn how to take a structured approach for
>> dealing with unsafe operations (like move). <
>> http://sean-parent.github.io/2014/05/30/about-move/> (there is also
>> related info in my "Better Code" talk <
>> https://github.com/sean-parent/sean-parent.github.io/wiki/Papers-and-Presentations
>> >.
>>
>> I have not done the work to know the pros/cons of such an attribute but I
>> think it is worth consideration.
>>
>
> This is all stuff that I think would be better handled in a proper
> contracts system. That would allow us to handle calling `clear` and other
> functions on a moved-from `vector`, where appropriate. Indeed, it would
> allow us to state up-front all kinds of things, not just dealing with
> whether the state of an object is "valid-but-unspecified".
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOxbGoHxZb94EhdEw1yf_WQHaDx-coRVG_AVpH%2BgC-QE3o6JYA%40mail.gmail.com.

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

<div dir=3D"ltr">Is there an existing contract system that would have these=
 capabilities for static analysis? How would you state &quot;if this member=
 function throws an exception then the object is left in a partially-formed=
 state&quot; with a contract system? Every contract system I&#39;m aware of=
 consists of runtime checks - there is no runtime check one can make to say=
 &quot;is this value unspecified?&quot; - the answer, by definition, is und=
efined.<div><br></div><div>Although I could imagine [[ensures: unspecified(=
)]] where=C2=A0unspecified() is some magic built in function - that would s=
eem to be an abuse of a contract system.<br><div><br></div><div>The problem=
 is much closer to a concept issue than one of contracts.</div><div>Sean</d=
iv></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On=
 Thu, Jun 30, 2016 at 4:31 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D=
"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;<=
/span> wrote:<br><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"><span clas=
s=3D"">On Thursday, June 30, 2016 at 6:26:20 PM UTC-4, <a href=3D"mailto:se=
an....@gmail.com" target=3D"_blank">sean....@gmail.com</a> wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"ltr">Perhaps the correct name for=
 such an attribute would be [[unspecified]] as in:<div><br></div><div>[[uns=
pecified]] atomic() =3D default;</div><div><br></div><div>There are many pl=
aces in the standard where objects are in an &quot;unspecified&quot; state =
(i.e. after being moved from, trivial constructors, state of object after a=
n exception for the basic exception guarantee). It would be great of compil=
ers could be told to warn about some set of operations on objects in this s=
tate (EoP refers to this as the partially-formed state). A value in an unsp=
ecified state has no meaning, at the very least it would be nice to get a c=
ompiler warning if the object is read from.</div><div><br></div><div>I&#39;=
m in favor of only allowing destruction and assigning to an object in an un=
specified state. I know others have argued that member functions, like vect=
or::clear(), which are equivalent to assignment should be allowed but I don=
&#39;t see any compelling argument for this. There should probably be an at=
tribute to specify that an object satisfies the strong exception guarantee =
(as basic is assumed). =C2=A0[[unspecified]] should also be the assumed as =
the default for moved from objects.</div><div><br></div><div>Having such an=
 attribute that compilers could enforce might well alleviate some of the da=
mage done by the current &quot;valid but unspecified&quot; language in the =
standard. We cannot have both efficiency and safety, provably, and so we ne=
ed to learn how to take a structured approach for dealing with unsafe opera=
tions (like move). &lt;<a href=3D"http://sean-parent.github.io/2014/05/30/a=
bout-move/" rel=3D"nofollow" target=3D"_blank">http://sean-parent.github.io=
/2014/05/30/about-move/</a>&gt; (there is also related info in my &quot;Bet=
ter Code&quot; talk &lt;<a href=3D"https://github.com/sean-parent/sean-pare=
nt.github.io/wiki/Papers-and-Presentations" rel=3D"nofollow" target=3D"_bla=
nk">https://github.com/sean-parent/sean-parent.github.io/wiki/Papers-and-Pr=
esentations</a>&gt;.</div><div><br></div><div>I have not done the work to k=
now the pros/cons of such an attribute but I think it is worth consideratio=
n.</div></div></blockquote></span><div><br>This is all stuff that I think w=
ould be better handled in a proper contracts system. That would allow us to=
 handle calling `clear` and other functions on a moved-from `vector`, where=
 appropriate. Indeed, it would allow us to state up-front all kinds of thin=
gs, not just dealing with whether the state of an object is &quot;valid-but=
-unspecified&quot;.<br></div></div></blockquote></div><br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOxbGoHxZb94EhdEw1yf_WQHaDx-coRVG_AV=
pH%2BgC-QE3o6JYA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOxbGoHxZb94Eh=
dEw1yf_WQHaDx-coRVG_AVpH%2BgC-QE3o6JYA%40mail.gmail.com</a>.<br />

--94eb2c06d0c2ca1d4c053687b7a5--

.

On 2016-06-30 17:37, Jonathan Coe wrote:
> On 30 June 2016 at 19:34, Matthew Woehlke wrote:
>>   int i;
>>   qDebug() << i; // warning; 'i' is uninitialized
>>   QImage image(64, 64, Qimage::Format_ARGB32);
>>   qDebug() << image.pixel(0, 0); // warning; 'image' is uninitialized
>>
>> The first warning exists. As I read it, the OP would like the second to
>> also warn. (You'd need to know what functions fully initialize the
>> object, though; this probably would not be easy to implement.)
>
> I really only had the default constructor and move-construction/-assignment
> in mind.

So, replace QImage with a fixed-size Eigen matrix. (Although that, as
Thiago noted, may be a trivial ctor.)

I still think this is a hard problem... not to say it wouldn't be great
if we could solve it, just that it's hard. Again considering the Eigen
matrix, the default ctor leaves its value unspecified, but there are
ways besides assignment to rectify that. The trick is being able to tell
when all parts of the object are specified, when you have methods that
work with only part of the object.

(Traditionally, this is solved by tools like valgrind by marking memory
as uninitialized at the byte level during execution.)

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nl5t99%249k5%241%40ger.gmane.org.

.

------=_Part_4313_1567879871.1467418244192
Content-Type: multipart/alternative;
 boundary="----=_Part_4314_1595332151.1467418244199"

------=_Part_4314_1595332151.1467418244199
Content-Type: text/plain; charset=UTF-8

On Thursday, June 30, 2016 at 8:03:39 PM UTC-4, Sean Parent wrote:
>
> Is there an existing contract system that would have these capabilities
> for static analysis? How would you state "if this member function throws an
> exception then the object is left in a partially-formed state" with a
> contract system?
>

Presumably with the same tools that allow you to say that the state of an
object will be valid-but-unspecified after calling a move constructor with
it.

vector<int> v = {4, 3};
vector<int> j(std::move(v));
v[1] = 4;

If a contract system can't catch something as simple as that, then really,
what good is it? Isn't the point of a contract system to verify
preconditions?

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e4ae9864-6591-4f39-a78a-a1ba816d6bd3%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, June 30, 2016 at 8:03:39 PM UTC-4, Sean Paren=
t wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Is th=
ere an existing contract system that would have these capabilities for stat=
ic analysis? How would you state &quot;if this member function throws an ex=
ception then the object is left in a partially-formed state&quot; with a co=
ntract system?</div></blockquote><div><br>Presumably with the same tools th=
at allow you to say that the state of an object will be valid-but-unspecifi=
ed after calling a move constructor with it. <br><br><div class=3D"prettypr=
int" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, =
187, 187); border-style: solid; border-width: 1px; word-wrap: break-word;">=
<code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">vector</span><span style=3D"color:=
 #080;" class=3D"styled-by-prettify">&lt;int&gt;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> v </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #066;" class=3D"styled-by-pret=
tify">4</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #066;" class=3D"styled-by-prettify">3</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>vector</span><span style=3D"colo=
r: #080;" class=3D"styled-by-prettify">&lt;int&gt;</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> j</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">move</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">v</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">));</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br>v</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">[</span><span style=3D"colo=
r: #066;" class=3D"styled-by-prettify">1</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">]</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">4</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span></div=
></code></div><br>If a contract system can&#39;t catch something as simple =
as that, then really, what good is it? Isn&#39;t the point of a contract sy=
stem to verify preconditions?</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e4ae9864-6591-4f39-a78a-a1ba816d6bd3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e4ae9864-6591-4f39-a78a-a1ba816d6bd3=
%40isocpp.org</a>.<br />

------=_Part_4314_1595332151.1467418244199--

------=_Part_4313_1567879871.1467418244192--

.

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

A contract system is typically runtime checked (at least everyone I've ever
looked at). The reason for the valid but unspecified language is that the
object invariants are not violated in a traditional sense. There is no
state in the object that can be verified to see if it is unspecified, by
definition. In your example, indexing into the object may or may not work.
A precondition could be specified as:

T& operator[](size_t i) [[ expects: i < size() ]];

And for an unspecified value size() is unspecified so the precondition may
or maynot be satisfied. Adding state would decrease efficiency and would
also make nearly everything an optional value. The point at which an object
may be unspecified in the code is always known at compile time. Although
someone could propose a way to add "unspecified" to a contract system - it
would make for an odd mix of runtime and compile time assertions.

One way this could be approached is to start with regular types:

The rules for regular types is that the only valid calls from the regular
basis operations on a partially formed object (what the standard calls
unspecified) are to destruct and to assign to the object. We could
generalize from that to say that it is only valid to write to, or destruct
an object.

For the vector example, what would actually fail is the call to size() in
the precondition.

Sean
On Jul 1, 2016 5:10 PM, "Nicol Bolas" <jmckesson@gmail.com> wrote:

On Thursday, June 30, 2016 at 8:03:39 PM UTC-4, Sean Parent wrote:
>
> Is there an existing contract system that would have these capabilities
> for static analysis? How would you state "if this member function throws an
> exception then the object is left in a partially-formed state" with a
> contract system?
>

Presumably with the same tools that allow you to say that the state of an
object will be valid-but-unspecified after calling a move constructor with
it.

vector<int> v = {4, 3};
vector<int> j(std::move(v));
v[1] = 4;

If a contract system can't catch something as simple as that, then really,
what good is it? Isn't the point of a contract system to verify
preconditions?

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOxbGoEA0FD%2BUx147w%2BzJj1dm%3D_nLh%3DidTxOZJik4GCcO8RGgA%40mail.gmail.com.

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

<div dir=3D"ltr"><p dir=3D"ltr">A contract system is typically runtime chec=
ked (at least everyone I&#39;ve ever looked at). The reason for the valid b=
ut unspecified language is that the object invariants are not violated in a=
 traditional sense. There is no state in the object that can be verified to=
 see if it is unspecified, by definition. In your example, indexing into th=
e object may or may not work. A precondition could be specified as:</p><p>T=
&amp; operator[](size_t i) [[ expects: i &lt; size() ]];</p><p>And for an u=
nspecified value size() is unspecified so the precondition may or maynot be=
 satisfied. Adding state would decrease efficiency and would also make near=
ly everything an optional value. The point at which an object may be unspec=
ified in the code is always known at compile time. Although someone could p=
ropose a way to add &quot;unspecified&quot; to a contract system - it would=
 make for an odd mix of runtime and compile time assertions.</p><p>One way =
this could be approached is to start with regular types:</p><p>The rules fo=
r regular types is that the only valid calls from the regular basis operati=
ons on a partially formed object (what the standard calls unspecified) are =
to destruct and to assign to the object. We could generalize from that to s=
ay that it is only valid to write to, or destruct an object.</p><p>For the =
vector example, what would actually fail is the call to size() in the preco=
ndition.=C2=A0<br></p><p>Sean</p>
<div class=3D"gmail_quote">On Jul 1, 2016 5:10 PM, &quot;Nicol Bolas&quot; =
&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmai=
l.com</a>&gt; wrote:<br type=3D"attribution"><blockquote style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-c=
olor:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>On Thursday, =
June 30, 2016 at 8:03:39 PM UTC-4, Sean Parent wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-=
left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr">Is there an existing contract system that would have these capa=
bilities for static analysis? How would you state &quot;if this member func=
tion throws an exception then the object is left in a partially-formed stat=
e&quot; with a contract system?</div></blockquote></div><div><br>Presumably=
 with the same tools that allow you to say that the state of an object will=
 be valid-but-unspecified after calling a move constructor with it. <br><br=
><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;backg=
round-color:rgb(250,250,250)"><code><div><span style=3D"color:rgb(0,0,0)">v=
ector</span><span style=3D"color:rgb(0,136,0)">&lt;int&gt;</span><span styl=
e=3D"color:rgb(0,0,0)"> v </span><span style=3D"color:rgb(102,102,0)">=3D</=
span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,=
102,0)">{</span><span style=3D"color:rgb(0,102,102)">4</span><span style=3D=
"color:rgb(102,102,0)">,</span><span style=3D"color:rgb(0,0,0)"> </span><sp=
an style=3D"color:rgb(0,102,102)">3</span><span style=3D"color:rgb(102,102,=
0)">};</span><span style=3D"color:rgb(0,0,0)"><br>vector</span><span style=
=3D"color:rgb(0,136,0)">&lt;int&gt;</span><span style=3D"color:rgb(0,0,0)">=
 j</span><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:=
rgb(0,0,0)">std</span><span style=3D"color:rgb(102,102,0)">::</span><span s=
tyle=3D"color:rgb(0,0,0)">move</span><span style=3D"color:rgb(102,102,0)">(=
</span><span style=3D"color:rgb(0,0,0)">v</span><span style=3D"color:rgb(10=
2,102,0)">));</span><span style=3D"color:rgb(0,0,0)"><br>v</span><span styl=
e=3D"color:rgb(102,102,0)">[</span><span style=3D"color:rgb(0,102,102)">1</=
span><span style=3D"color:rgb(102,102,0)">]</span><span style=3D"color:rgb(=
0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">=3D</span><span style=
=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,102,102)">4</span>=
<span style=3D"color:rgb(102,102,0)">;</span></div></code></div><br>If a co=
ntract system can&#39;t catch something as simple as that, then really, wha=
t good is it? Isn&#39;t the point of a contract system to verify preconditi=
ons?</div></div></blockquote></div>
</div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOxbGoEA0FD%2BUx147w%2BzJj1dm%3D_nLh=
%3DidTxOZJik4GCcO8RGgA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOxbGoEA=
0FD%2BUx147w%2BzJj1dm%3D_nLh%3DidTxOZJik4GCcO8RGgA%40mail.gmail.com</a>.<br=
 />

--001a11c1662af97b7705369eb477--

.

--Apple-Mail-3D1F984B-4024-4869-A4D0-4C51B807733A
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I think there enough interest in this idea for me to sketch it out in a bit=
 more detail. Is this the right list for a draft language evolution paper?

Thanks for all the input so far,

Jon

> On 2 Jul 2016, at 04:29, Sean Parent <sean.parent@gmail.com> wrote:
>=20
> A contract system is typically runtime checked (at least everyone I've ev=
er looked at). The reason for the valid but unspecified language is that th=
e object invariants are not violated in a traditional sense. There is no st=
ate in the object that can be verified to see if it is unspecified, by defi=
nition. In your example, indexing into the object may or may not work. A pr=
econdition could be specified as:
>=20
> T& operator[](size_t i) [[ expects: i < size() ]];
>=20
> And for an unspecified value size() is unspecified so the precondition ma=
y or maynot be satisfied. Adding state would decrease efficiency and would =
also make nearly everything an optional value. The point at which an object=
 may be unspecified in the code is always known at compile time. Although s=
omeone could propose a way to add "unspecified" to a contract system - it w=
ould make for an odd mix of runtime and compile time assertions.
>=20
> One way this could be approached is to start with regular types:
>=20
> The rules for regular types is that the only valid calls from the regular=
 basis operations on a partially formed object (what the standard calls uns=
pecified) are to destruct and to assign to the object. We could generalize =
from that to say that it is only valid to write to, or destruct an object.
>=20
> For the vector example, what would actually fail is the call to size() in=
 the precondition.=20
>=20
> Sean
>=20
> On Jul 1, 2016 5:10 PM, "Nicol Bolas" <jmckesson@gmail.com> wrote:
>> On Thursday, June 30, 2016 at 8:03:39 PM UTC-4, Sean Parent wrote:
>> Is there an existing contract system that would have these capabilities =
for static analysis? How would you state "if this member function throws an=
 exception then the object is left in a partially-formed state" with a cont=
ract system?
>=20
>=20
> Presumably with the same tools that allow you to say that the state of an=
 object will be valid-but-unspecified after calling a move constructor with=
 it.=20
>=20
> vector<int> v =3D {4, 3};
> vector<int> j(std::move(v));
> v[1] =3D 4;
>=20
> If a contract system can't catch something as simple as that, then really=
, what good is it? Isn't the point of a contract system to verify precondit=
ions?
> --=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.
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/CAOxbGoEA0FD%2BUx147w%2BzJj1dm%3D_nLh%3DidTxOZ=
Jik4GCcO8RGgA%40mail.gmail.com.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/76564367-C16A-4ED1-9140-D06EC25D9299%40gmail.com=
..

--Apple-Mail-3D1F984B-4024-4869-A4D0-4C51B807733A
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></div><div>I think there enough in=
terest in this idea for me to sketch it out in a bit more detail. Is this t=
he right list for a draft language evolution paper?</div><div><br></div><di=
v>Thanks for all the input so far,</div><div><br></div><div>Jon</div><div><=
br>On 2 Jul 2016, at 04:29, Sean Parent &lt;<a href=3D"mailto:sean.parent@g=
mail.com">sean.parent@gmail.com</a>&gt; wrote:<br><br></div><blockquote typ=
e=3D"cite"><div><div dir=3D"ltr"><p dir=3D"ltr">A contract system is typica=
lly runtime checked (at least everyone I've ever looked at). The reason for=
 the valid but unspecified language is that the object invariants are not v=
iolated in a traditional sense. There is no state in the object that can be=
 verified to see if it is unspecified, by definition. In your example, inde=
xing into the object may or may not work. A precondition could be specified=
 as:</p><p>T&amp; operator[](size_t i) [[ expects: i &lt; size() ]];</p><p>=
And for an unspecified value size() is unspecified so the precondition may =
or maynot be satisfied. Adding state would decrease efficiency and would al=
so make nearly everything an optional value. The point at which an object m=
ay be unspecified in the code is always known at compile time. Although som=
eone could propose a way to add "unspecified" to a contract system - it wou=
ld make for an odd mix of runtime and compile time assertions.</p><p>One wa=
y this could be approached is to start with regular types:</p><p>The rules =
for regular types is that the only valid calls from the regular basis opera=
tions on a partially formed object (what the standard calls unspecified) ar=
e to destruct and to assign to the object. We could generalize from that to=
 say that it is only valid to write to, or destruct an object.</p><p>For th=
e vector example, what would actually fail is the call to size() in the pre=
condition.&nbsp;<br></p><p>Sean</p>
<div class=3D"gmail_quote">On Jul 1, 2016 5:10 PM, "Nicol Bolas" &lt;<a hre=
f=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&=
gt; wrote:<br type=3D"attribution"><blockquote style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(2=
04,204,204);padding-left:1ex"><div dir=3D"ltr"><div>On Thursday, June 30, 2=
016 at 8:03:39 PM UTC-4, Sean Parent wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style=
:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr=
">Is there an existing contract system that would have these capabilities f=
or static analysis? How would you state "if this member function throws an =
exception then the object is left in a partially-formed state" with a contr=
act system?</div></blockquote></div><div><br>Presumably with the same tools=
 that allow you to say that the state of an object will be valid-but-unspec=
ified after calling a move constructor with it. <br><br><div style=3D"borde=
r:1px solid rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,=
250,250)"><code><div><span style=3D"color:rgb(0,0,0)">vector</span><span st=
yle=3D"color:rgb(0,136,0)">&lt;int&gt;</span><span style=3D"color:rgb(0,0,0=
)"> v </span><span style=3D"color:rgb(102,102,0)">=3D</span><span style=3D"=
color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">{</span><spa=
n style=3D"color:rgb(0,102,102)">4</span><span style=3D"color:rgb(102,102,0=
)">,</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rg=
b(0,102,102)">3</span><span style=3D"color:rgb(102,102,0)">};</span><span s=
tyle=3D"color:rgb(0,0,0)"><br>vector</span><span style=3D"color:rgb(0,136,0=
)">&lt;int&gt;</span><span style=3D"color:rgb(0,0,0)"> j</span><span style=
=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,0)">std</spa=
n><span style=3D"color:rgb(102,102,0)">::</span><span style=3D"color:rgb(0,=
0,0)">move</span><span style=3D"color:rgb(102,102,0)">(</span><span style=
=3D"color:rgb(0,0,0)">v</span><span style=3D"color:rgb(102,102,0)">));</spa=
n><span style=3D"color:rgb(0,0,0)"><br>v</span><span style=3D"color:rgb(102=
,102,0)">[</span><span style=3D"color:rgb(0,102,102)">1</span><span style=
=3D"color:rgb(102,102,0)">]</span><span style=3D"color:rgb(0,0,0)"> </span>=
<span style=3D"color:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(0,0=
,0)"> </span><span style=3D"color:rgb(0,102,102)">4</span><span style=3D"co=
lor:rgb(102,102,0)">;</span></div></code></div><br>If a contract system can=
't catch something as simple as that, then really, what good is it? Isn't t=
he point of a contract system to verify preconditions?</div></div></blockqu=
ote></div>
</div>

<p></p>

-- <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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOxbGoEA0FD%2BUx147w%2BzJj1dm%3D_nLh=
%3DidTxOZJik4GCcO8RGgA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=
=3Dfooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAO=
xbGoEA0FD%2BUx147w%2BzJj1dm%3D_nLh%3DidTxOZJik4GCcO8RGgA%40mail.gmail.com</=
a>.<br>
</div></blockquote></body></html>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/76564367-C16A-4ED1-9140-D06EC25D9299%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/76564367-C16A-4ED1-9140-D06EC25D9299%=
40gmail.com</a>.<br />

--Apple-Mail-3D1F984B-4024-4869-A4D0-4C51B807733A--

.

------=_Part_5142_1921294696.1467979188179
Content-Type: multipart/alternative;
 boundary="----=_Part_5143_1540484874.1467979188179"

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



W dniu czwartek, 30 czerwca 2016 00:03:39 UTC+2 u=C5=BCytkownik Nevin ":-)"=
=20
Liber napisa=C5=82:
>
> On 29 June 2016 at 14:08, Jonathan Coe <jb...@me.com <javascript:>> wrote=
:
>
>> Sometimes default construction or move-from leaves an object in a state=
=20
>> where it's no use for anything but later assignment.
>
>
> Well, it isn't uninitialized, because you have to be able to destroy the=
=20
> object.  We should discourage people from weaken their class invariants;=
=20
> optional<T> is a much better solution for these situations.
>

While, I agree that a world (of C++ programs) would be better off without=
=20
"weak invariants", I must observe that every RAII-like object representing=
=20
a resource and offering move semantics already must provide this "zombie"=
=20
state. It looks like move-semantics encourages having week invariants.

Regards,
&rze;=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/d38370ea-3a97-4fe7-9260-ffb3c6ec399a%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>W dniu czwartek, 30 czerwca 2016 00:03:39 UTC+2 u=
=C5=BCytkownik Nevin &quot;:-)&quot; Liber napisa=C5=82:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div>On 29 June 2016 at 14:08,=
 Jonathan Coe <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blan=
k" gdf-obfuscated-mailto=3D"zGhsIvXGBgAJ" rel=3D"nofollow" onmousedown=3D"t=
his.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;=
javascript:&#39;;return true;">jb...@me.com</a>&gt;</span> wrote:<br><div c=
lass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sometimes default const=
ruction or move-from leaves an object in a state where it&#39;s no use for =
anything but later assignment.</blockquote></div><br>Well, it isn&#39;t uni=
nitialized, because you have to be able to destroy the object.=C2=A0 We sho=
uld discourage people from weaken their class invariants; optional&lt;T&gt;=
 is a much better solution for these situations.</div><div></div></div></bl=
ockquote><div><br>While, I agree that a world (of C++ programs) would be be=
tter off=20
without &quot;weak invariants&quot;, I must observe that every RAII-like ob=
ject=20
representing a resource and offering move semantics already must provide
 this &quot;zombie&quot; state. It looks like move-semantics encourages hav=
ing=20
week invariants.<br><br>Regards,<br>&amp;rze; <br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d38370ea-3a97-4fe7-9260-ffb3c6ec399a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d38370ea-3a97-4fe7-9260-ffb3c6ec399a=
%40isocpp.org</a>.<br />

------=_Part_5143_1540484874.1467979188179--

------=_Part_5142_1921294696.1467979188179--

.

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

Not necessarily; the moved-from state can often be equivalent to a default
state, which does not lead to weakening the invariants. We can make move
faster by being more agressive, but in many (most?) cases the moved-from
state does not need to be zombie-like (taking =C2=ABzombie-like=C2=BB as =
=C2=ABfor which
invariants are broken/ weakened for on which dtor and assignment can still
be applied=C2=BB). Am I misunderstanding what you meant by =C2=ABzombie=C2=
=BB state or
=C2=ABweak invariants=C2=BB?

Cheers!

2016-07-08 7:59 GMT-04:00 Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com>:

>
>
> W dniu czwartek, 30 czerwca 2016 00:03:39 UTC+2 u=C5=BCytkownik Nevin ":-=
)"
> Liber napisa=C5=82:
>>
>> On 29 June 2016 at 14:08, Jonathan Coe <jb...@me.com> wrote:
>>
>>> Sometimes default construction or move-from leaves an object in a state
>>> where it's no use for anything but later assignment.
>>
>>
>> Well, it isn't uninitialized, because you have to be able to destroy the
>> object.  We should discourage people from weaken their class invariants;
>> optional<T> is a much better solution for these situations.
>>
>
> While, I agree that a world (of C++ programs) would be better off without
> "weak invariants", I must observe that every RAII-like object representin=
g
> a resource and offering move semantics already must provide this "zombie"
> state. It looks like move-semantics encourages having week invariants.
>
> Regards,
> &rze;
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d38370ea-3a9=
7-4fe7-9260-ffb3c6ec399a%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d38370ea-3a=
97-4fe7-9260-ffb3c6ec399a%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAKiZDp1Gdtm98%2BBfVUY9%3DKDRSsXXB8C2suMMNCBKyg0=
FgbaytA%40mail.gmail.com.

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

<div dir=3D"ltr"><div>Not necessarily; the moved-from state can often be eq=
uivalent to a default state, which does not lead to weakening the invariant=
s. We can make move faster by being more agressive, but in many (most?) cas=
es the moved-from state does not need to be zombie-like (taking =C2=ABzombi=
e-like=C2=BB as =C2=ABfor which invariants are broken/ weakened for on whic=
h dtor and assignment can still be applied=C2=BB). Am I misunderstanding wh=
at you meant by =C2=ABzombie=C2=BB state or =C2=ABweak invariants=C2=BB?<br=
><br></div>Cheers!<br></div><div class=3D"gmail_extra"><br><div class=3D"gm=
ail_quote">2016-07-08 7:59 GMT-04:00 Andrzej Krzemie=C5=84ski <span dir=3D"=
ltr">&lt;<a href=3D"mailto:akrzemi1@gmail.com" target=3D"_blank">akrzemi1@g=
mail.com</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><br><br>W dniu czwartek, 30 czerwca 2016 00:03:39 UTC+2 u=C5=BCytkownik Ne=
vin &quot;:-)&quot; Liber napisa=C5=82:<span class=3D""><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div>On 29 June 2016 at 14:08, Jona=
than Coe <span dir=3D"ltr">&lt;<a rel=3D"nofollow">jb...@me.com</a>&gt;</sp=
an> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Som=
etimes default construction or move-from leaves an object in a state where =
it&#39;s no use for anything but later assignment.</blockquote></div><br>We=
ll, it isn&#39;t uninitialized, because you have to be able to destroy the =
object.=C2=A0 We should discourage people from weaken their class invariant=
s; optional&lt;T&gt; is a much better solution for these situations.</div><=
div></div></div></blockquote></span><div><br>While, I agree that a world (o=
f C++ programs) would be better off=20
without &quot;weak invariants&quot;, I must observe that every RAII-like ob=
ject=20
representing a resource and offering move semantics already must provide
 this &quot;zombie&quot; state. It looks like move-semantics encourages hav=
ing=20
week invariants.<br><br>Regards,<br>&amp;rze; <br></div></div><span class=
=3D"">

<p></p>

-- <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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d38370ea-3a97-4fe7-9260-ffb3c6ec399a%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d38370ea-3a97-=
4fe7-9260-ffb3c6ec399a%40isocpp.org</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp1Gdtm98%2BBfVUY9%3DKDRSsXXB8C2=
suMMNCBKyg0FgbaytA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp1Gdtm9=
8%2BBfVUY9%3DKDRSsXXB8C2suMMNCBKyg0FgbaytA%40mail.gmail.com</a>.<br />

--94eb2c0919b2c1113a053724e9d0--

.

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

The problem is the "not necessarily" part - see the long discussion on the
state a variant is left in if assignment fails. The problem is in
specifying the _requirements_ of a moved from type. IMO move should be
required to be noexcept and the requirements of the moved from type should
only be that it is partially formed. Most types can (and do) provide
stronger guarantees.

On Fri, Jul 8, 2016 at 12:36 PM, Patrice Roy <patricer@gmail.com> wrote:

> Not necessarily; the moved-from state can often be equivalent to a defaul=
t
> state, which does not lead to weakening the invariants. We can make move
> faster by being more agressive, but in many (most?) cases the moved-from
> state does not need to be zombie-like (taking =C2=ABzombie-like=C2=BB as =
=C2=ABfor which
> invariants are broken/ weakened for on which dtor and assignment can stil=
l
> be applied=C2=BB). Am I misunderstanding what you meant by =C2=ABzombie=
=C2=BB state or
> =C2=ABweak invariants=C2=BB?
>
> Cheers!
>
> 2016-07-08 7:59 GMT-04:00 Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com>:
>
>>
>>
>> W dniu czwartek, 30 czerwca 2016 00:03:39 UTC+2 u=C5=BCytkownik Nevin ":=
-)"
>> Liber napisa=C5=82:
>>>
>>> On 29 June 2016 at 14:08, Jonathan Coe <jb...@me.com> wrote:
>>>
>>>> Sometimes default construction or move-from leaves an object in a stat=
e
>>>> where it's no use for anything but later assignment.
>>>
>>>
>>> Well, it isn't uninitialized, because you have to be able to destroy th=
e
>>> object.  We should discourage people from weaken their class invariants=
;
>>> optional<T> is a much better solution for these situations.
>>>
>>
>> While, I agree that a world (of C++ programs) would be better off withou=
t
>> "weak invariants", I must observe that every RAII-like object representi=
ng
>> a resource and offering move semantics already must provide this "zombie=
"
>> state. It looks like move-semantics encourages having week invariants.
>>
>> Regards,
>> &rze;
>>
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d38370ea-3a=
97-4fe7-9260-ffb3c6ec399a%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d38370ea-3=
a97-4fe7-9260-ffb3c6ec399a%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
> --
> 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/aZG6VRPQ8n8/=
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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp1Gdtm=
98%2BBfVUY9%3DKDRSsXXB8C2suMMNCBKyg0FgbaytA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp1Gdt=
m98%2BBfVUY9%3DKDRSsXXB8C2suMMNCBKyg0FgbaytA%40mail.gmail.com?utm_medium=3D=
email&utm_source=3Dfooter>
> .
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAOxbGoEhw2ibg--rf7FKF%3D1CKkDNA%2Bax3mPk02wYAO_=
1ngdtKg%40mail.gmail.com.

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

<div dir=3D"ltr">The problem is the &quot;not necessarily&quot; part - see =
the long discussion on the state a variant is left in if assignment fails. =
The problem is in specifying the _requirements_ of a moved from type. IMO m=
ove should be required to be noexcept and the requirements of the moved fro=
m type should only be that it is partially formed. Most types can (and do) =
provide stronger guarantees.</div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Fri, Jul 8, 2016 at 12:36 PM, Patrice Roy <span dir=3D"=
ltr">&lt;<a href=3D"mailto:patricer@gmail.com" target=3D"_blank">patricer@g=
mail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div>Not necessarily; the moved-from state can often be equivalent=
 to a default state, which does not lead to weakening the invariants. We ca=
n make move faster by being more agressive, but in many (most?) cases the m=
oved-from state does not need to be zombie-like (taking =C2=ABzombie-like=
=C2=BB as =C2=ABfor which invariants are broken/ weakened for on which dtor=
 and assignment can still be applied=C2=BB). Am I misunderstanding what you=
 meant by =C2=ABzombie=C2=BB state or =C2=ABweak invariants=C2=BB?<br><br><=
/div>Cheers!<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_qu=
ote"><span class=3D"">2016-07-08 7:59 GMT-04:00 Andrzej Krzemie=C5=84ski <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:akrzemi1@gmail.com" target=3D"_blank"=
>akrzemi1@gmail.com</a>&gt;</span>:<br></span><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><span class=3D""><div dir=3D"ltr"><br><br>W dniu czwartek, 30 czerwca 201=
6 00:03:39 UTC+2 u=C5=BCytkownik Nevin &quot;:-)&quot; Liber napisa=C5=82:<=
span><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>On 29 Ju=
ne 2016 at 14:08, Jonathan Coe <span dir=3D"ltr">&lt;<a rel=3D"nofollow">jb=
....@me.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">Sometimes default construction or move-from leaves an ob=
ject in a state where it&#39;s no use for anything but later assignment.</b=
lockquote></div><br>Well, it isn&#39;t uninitialized, because you have to b=
e able to destroy the object.=C2=A0 We should discourage people from weaken=
 their class invariants; optional&lt;T&gt; is a much better solution for th=
ese situations.</div><div></div></div></blockquote></span><div><br>While, I=
 agree that a world (of C++ programs) would be better off=20
without &quot;weak invariants&quot;, I must observe that every RAII-like ob=
ject=20
representing a resource and offering move semantics already must provide
 this &quot;zombie&quot; state. It looks like move-semantics encourages hav=
ing=20
week invariants.<br><br>Regards,<br>&amp;rze; <br></div></div></span><span>

<p></p>

-- <br><span class=3D"">
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></span>
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>.<span class=3D""><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></span></span><spa=
n class=3D"">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d38370ea-3a97-4fe7-9260-ffb3c6ec399a%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d38370ea-3a97-=
4fe7-9260-ffb3c6ec399a%40isocpp.org</a>.<br>
</span></blockquote></div><br></div><span class=3D"">

<p></p>

-- <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/aZG6VRPQ8n8/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/aZG6VRPQ8n8=
/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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp1Gdtm98%2BBfVUY9%3DKDRSsXXB8C2=
suMMNCBKyg0FgbaytA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CAKiZDp1Gdtm98%2BBfVUY9%3DKDRSsXXB8C2suMMNCBKyg0FgbaytA%40mail.gma=
il.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOxbGoEhw2ibg--rf7FKF%3D1CKkDNA%2Bax=
3mPk02wYAO_1ngdtKg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOxbGoEhw2ib=
g--rf7FKF%3D1CKkDNA%2Bax3mPk02wYAO_1ngdtKg%40mail.gmail.com</a>.<br />

--001a11c1662ac8554f053725af4d--

.

------=_Part_1435_1470564173.1468011233692
Content-Type: multipart/alternative;
 boundary="----=_Part_1436_1440247322.1468011233692"

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



W dniu pi=C4=85tek, 8 lipca 2016 21:36:05 UTC+2 u=C5=BCytkownik Patrice Roy=
 napisa=C5=82:
>
> Not necessarily; the moved-from state can often be equivalent to a defaul=
t=20
> state, which does not lead to weakening the invariants. We can make move=
=20
> faster by being more agressive, but in many (most?) cases the moved-from=
=20
> state does not need to be zombie-like (taking =C2=ABzombie-like=C2=BB as =
=C2=ABfor which=20
> invariants are broken/ weakened for on which dtor and assignment can stil=
l=20
> be applied=C2=BB). Am I misunderstanding what you meant by =C2=ABzombie=
=C2=BB state or=20
> =C2=ABweak invariants=C2=BB?
>

I mean, even default constructor will often weaken an invariant of a=20
resource-managing class. Not an ideal example, but consider an fstream:

    std::ofstream f {}; // default constructed file-handle whrapper
    f.exceptions ( std::ifstream::failbit | std::ifstream::badbit );
    f << 0; // oops cannot write to not-a-file

`f` is in a "poor" state where it does not really represent a resource. I=
=20
cannot write to it unless I manually check whether it really owns a=20
resource at the moment.

Regards,
&rzej;

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/a6572f4c-4935-49ca-b4e5-07d1b9ebeed2%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>W dniu pi=C4=85tek, 8 lipca 2016 21:36:05 UTC+2 u=
=C5=BCytkownik Patrice Roy napisa=C5=82:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><div>Not necessarily; the moved-from state can o=
ften be equivalent to a default state, which does not lead to weakening the=
 invariants. We can make move faster by being more agressive, but in many (=
most?) cases the moved-from state does not need to be zombie-like (taking =
=C2=ABzombie-like=C2=BB as =C2=ABfor which invariants are broken/ weakened =
for on which dtor and assignment can still be applied=C2=BB). Am I misunder=
standing what you meant by =C2=ABzombie=C2=BB state or =C2=ABweak invariant=
s=C2=BB?</div></div></blockquote><div><br>I mean, even default constructor =
will often weaken an invariant of a resource-managing class. Not an ideal e=
xample, but consider an fstream:<br><div class=3D"prettyprint" style=3D"bac=
kground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border=
-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pr=
ettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 std</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">ofstream f </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">{};</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-b=
y-prettify">// default constructed file-handle whrapper</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 f</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">exceptions </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">ifstream</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">failbit </span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">|</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:=
:</span><span style=3D"color: #000;" class=3D"styled-by-prettify">ifstream<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">badbit </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 f </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;&lt;</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"=
styled-by-prettify">// oops cannot write to not-a-file</span></div></code><=
/div><br>`f` is in a &quot;poor&quot; state where it does not really repres=
ent a resource. I cannot write to it unless I manually check whether it rea=
lly owns a resource at the moment.<br><br>Regards,<br>&amp;rzej;<br> <br></=
div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a6572f4c-4935-49ca-b4e5-07d1b9ebeed2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a6572f4c-4935-49ca-b4e5-07d1b9ebeed2=
%40isocpp.org</a>.<br />

------=_Part_1436_1440247322.1468011233692--

------=_Part_1435_1470564173.1468011233692--

.