I think I've seen this.

Problem:
  - when adding a new ctor, a programmer may inadvertently leave
uninitialized attributes (specially PODs). Similarly, when adding a
new attribute, a programmer may forget to call its ctor (or initialize
it) in all the ctors of the class (again, specially when the new
attribute is a POD).

Problem Example1:

//before the change:
struct S
{
    int x;
    S(/*some signature*/) : x(1) {}
};

//after the change:
struct S
{
    int x;
    S(/*some signature*/) : x(1) {}
    S(/*some OTHER signature*/) {} // x is uninitialized
};

Problem Example 2:
//before the change:
struct S
{
    int x;
    S(/*some signature*/) : x(1) {}
};

//after the change:
struct S
{
    int x;
    int y; // new attribute
    S(/*some signature*/) : x(1) {} // y is uninitialized
};

- Why this problem is important?
    The more attributes / ctors the class has, the problem gets worse
(though that might be caused by a bad design of poor modularization).
    The problem is relevant when writing maintainable code, since
future maintainers may incur in the errors mentioned above.

- How people is working around this issue nowadays?
    There are both static checkers and dynamic checkers (such as
valgrind) that may detect use of uninitialized data.
    People can =3Ddelete the default ctor of the contained objects.

- Alternative proposed solutions
   Solution 1: library approach. Provide a type wrapper without a
default ctor (such as initialization_required<T>). Such wrapper could
be implemented extending the template type (inheriting from it) and
removing the default ctor, and should be template-specialized for PODs
with all the operations of each POD.

struct S
{
    initialization_required<int> x;
    initialization_required<int> y;
   S(/*some signature*/) : x(1) {} // error: y initialization missing
};

   Solution 2: prefix the attribute declaration with some keyword
(such as "explicit").

struct S
{
    explicit int x;
    explicit int y;
    S(/*some signature*/) : x(1) {} // error: y is uninitialized
};

 - Discussion: what happens with inheritance?
     As mentioned above, this problem gets relevant with PODs so
inheritance wouldn't apply in that case (unless we propose the ability
to extend from PODs some day ;-) ).
     Nevertheless, both solutions could be applicable to inheritance:

Sol1:   struct S : initialization_required<T> { ... };
Sol2:   struct S : explicit T { ... };

Ideas? Is this worth to write a formal proposal?

Thanks,

    Daniel.



--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=20

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

.

On 29 April 2015 at 21:57, dgutson . <danielgutson@gmail.com> wrote:
> I think I've seen this.
>
> Problem:
>   - when adding a new ctor, a programmer may inadvertently leave
> uninitialized attributes (specially PODs). Similarly, when adding a
> new attribute, a programmer may forget to call its ctor (or initialize
> it) in all the ctors of the class (again, specially when the new
> attribute is a POD).
>
> Problem Example1:
>
> //before the change:
> struct S
> {
>     int x;
>     S(/*some signature*/) : x(1) {}
> };
>
> //after the change:
> struct S
> {
>     int x;
>     S(/*some signature*/) : x(1) {}
>     S(/*some OTHER signature*/) {} // x is uninitialized
> };
>
> Problem Example 2:
> //before the change:
> struct S
> {
>     int x;
>     S(/*some signature*/) : x(1) {}
> };
>
> //after the change:
> struct S
> {
>     int x;
>     int y; // new attribute
>     S(/*some signature*/) : x(1) {} // y is uninitialized
> };
>
> - Why this problem is important?
>     The more attributes / ctors the class has, the problem gets worse
> (though that might be caused by a bad design of poor modularization).
>     The problem is relevant when writing maintainable code, since
> future maintainers may incur in the errors mentioned above.
>
> - How people is working around this issue nowadays?
>     There are both static checkers and dynamic checkers (such as
> valgrind) that may detect use of uninitialized data.
>     People can =delete the default ctor of the contained objects.
>
> - Alternative proposed solutions
>    Solution 1: library approach. Provide a type wrapper without a
> default ctor (such as initialization_required<T>). Such wrapper could
> be implemented extending the template type (inheriting from it) and
> removing the default ctor, and should be template-specialized for PODs
> with all the operations of each POD.
>
> struct S
> {
>     initialization_required<int> x;
>     initialization_required<int> y;
>    S(/*some signature*/) : x(1) {} // error: y initialization missing
> };
>
>    Solution 2: prefix the attribute declaration with some keyword
> (such as "explicit").
>
> struct S
> {
>     explicit int x;
>     explicit int y;
>     S(/*some signature*/) : x(1) {} // error: y is uninitialized
> };
>
>  - Discussion: what happens with inheritance?
>      As mentioned above, this problem gets relevant with PODs so
> inheritance wouldn't apply in that case (unless we propose the ability
> to extend from PODs some day ;-) ).
>      Nevertheless, both solutions could be applicable to inheritance:
>
> Sol1:   struct S : initialization_required<T> { ... };
> Sol2:   struct S : explicit T { ... };
>
> Ideas? Is this worth to write a formal proposal?


Any particular reason why you're not using non-static data member initializers?
That is,
struct S
 {
     int x=42;
     int y=666;
     S(/*some signature*/) : x(1) {} // y is 666 since nothing else was provided
};

You can make the NSDMI throw or even terminate if explicit
initialization is not provided
in a ctor-initializer.

--

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

.

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

El 29/4/2015 16:12, "Ville Voutilainen" <ville.voutilainen@gmail.com>
escribi=C3=B3:
>
> On 29 April 2015 at 21:57, dgutson . <danielgutson@gmail.com> wrote:
> > I think I've seen this.
> >
> > Problem:
> >   - when adding a new ctor, a programmer may inadvertently leave
> > uninitialized attributes (specially PODs). Similarly, when adding a
> > new attribute, a programmer may forget to call its ctor (or initialize
> > it) in all the ctors of the class (again, specially when the new
> > attribute is a POD).
> >
> > Problem Example1:
> >
> > //before the change:
> > struct S
> > {
> >     int x;
> >     S(/*some signature*/) : x(1) {}
> > };
> >
> > //after the change:
> > struct S
> > {
> >     int x;
> >     S(/*some signature*/) : x(1) {}
> >     S(/*some OTHER signature*/) {} // x is uninitialized
> > };
> >
> > Problem Example 2:
> > //before the change:
> > struct S
> > {
> >     int x;
> >     S(/*some signature*/) : x(1) {}
> > };
> >
> > //after the change:
> > struct S
> > {
> >     int x;
> >     int y; // new attribute
> >     S(/*some signature*/) : x(1) {} // y is uninitialized
> > };
> >
> > - Why this problem is important?
> >     The more attributes / ctors the class has, the problem gets worse
> > (though that might be caused by a bad design of poor modularization).
> >     The problem is relevant when writing maintainable code, since
> > future maintainers may incur in the errors mentioned above.
> >
> > - How people is working around this issue nowadays?
> >     There are both static checkers and dynamic checkers (such as
> > valgrind) that may detect use of uninitialized data.
> >     People can =3Ddelete the default ctor of the contained objects.
> >
> > - Alternative proposed solutions
> >    Solution 1: library approach. Provide a type wrapper without a
> > default ctor (such as initialization_required<T>). Such wrapper could
> > be implemented extending the template type (inheriting from it) and
> > removing the default ctor, and should be template-specialized for PODs
> > with all the operations of each POD.
> >
> > struct S
> > {
> >     initialization_required<int> x;
> >     initialization_required<int> y;
> >    S(/*some signature*/) : x(1) {} // error: y initialization missing
> > };
> >
> >    Solution 2: prefix the attribute declaration with some keyword
> > (such as "explicit").
> >
> > struct S
> > {
> >     explicit int x;
> >     explicit int y;
> >     S(/*some signature*/) : x(1) {} // error: y is uninitialized
> > };
> >
> >  - Discussion: what happens with inheritance?
> >      As mentioned above, this problem gets relevant with PODs so
> > inheritance wouldn't apply in that case (unless we propose the ability
> > to extend from PODs some day ;-) ).
> >      Nevertheless, both solutions could be applicable to inheritance:
> >
> > Sol1:   struct S : initialization_required<T> { ... };
> > Sol2:   struct S : explicit T { ... };
> >
> > Ideas? Is this worth to write a formal proposal?
>
>
> Any particular reason why you're not using non-static data member
initializers?

Yes: because that solves a different problem, which is "release the
programmer to initialize the attribute always with the same value unless
specified" whereas the problem I want to address is "require to ALWAYS
initialize the attribute, no matter of the value (either always the same or
some different)". Moreover, non-static member initialization goes in the
opposite direction of the intention of this issue.

> That is,
> struct S
>  {
>      int x=3D42;
>      int y=3D666;
>      S(/*some signature*/) : x(1) {} // y is 666 since nothing else was
provided
> };
>
> You can make the NSDMI throw or even terminate if explicit
> initialization is not provided
> in a ctor-initializer.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
http://groups.google.com/a/isocpp.org/group/std-proposals/.

--=20

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

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

<p dir=3D"ltr"><br>
El 29/4/2015 16:12, &quot;Ville Voutilainen&quot; &lt;<a href=3D"mailto:vil=
le.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt; escribi=C3=B3=
:<br>
&gt;<br>
&gt; On 29 April 2015 at 21:57, dgutson . &lt;<a href=3D"mailto:danielgutso=
n@gmail.com">danielgutson@gmail.com</a>&gt; wrote:<br>
&gt; &gt; I think I&#39;ve seen this.<br>
&gt; &gt;<br>
&gt; &gt; Problem:<br>
&gt; &gt;=C2=A0 =C2=A0- when adding a new ctor, a programmer may inadverten=
tly leave<br>
&gt; &gt; uninitialized attributes (specially PODs). Similarly, when adding=
 a<br>
&gt; &gt; new attribute, a programmer may forget to call its ctor (or initi=
alize<br>
&gt; &gt; it) in all the ctors of the class (again, specially when the new<=
br>
&gt; &gt; attribute is a POD).<br>
&gt; &gt;<br>
&gt; &gt; Problem Example1:<br>
&gt; &gt;<br>
&gt; &gt; //before the change:<br>
&gt; &gt; struct S<br>
&gt; &gt; {<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0int x;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0S(/*some signature*/) : x(1) {}<br>
&gt; &gt; };<br>
&gt; &gt;<br>
&gt; &gt; //after the change:<br>
&gt; &gt; struct S<br>
&gt; &gt; {<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0int x;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0S(/*some signature*/) : x(1) {}<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0S(/*some OTHER signature*/) {} // x is uniniti=
alized<br>
&gt; &gt; };<br>
&gt; &gt;<br>
&gt; &gt; Problem Example 2:<br>
&gt; &gt; //before the change:<br>
&gt; &gt; struct S<br>
&gt; &gt; {<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0int x;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0S(/*some signature*/) : x(1) {}<br>
&gt; &gt; };<br>
&gt; &gt;<br>
&gt; &gt; //after the change:<br>
&gt; &gt; struct S<br>
&gt; &gt; {<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0int x;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0int y; // new attribute<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0S(/*some signature*/) : x(1) {} // y is uninit=
ialized<br>
&gt; &gt; };<br>
&gt; &gt;<br>
&gt; &gt; - Why this problem is important?<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0The more attributes / ctors the class has, the=
 problem gets worse<br>
&gt; &gt; (though that might be caused by a bad design of poor modularizati=
on).<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0The problem is relevant when writing maintaina=
ble code, since<br>
&gt; &gt; future maintainers may incur in the errors mentioned above.<br>
&gt; &gt;<br>
&gt; &gt; - How people is working around this issue nowadays?<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0There are both static checkers and dynamic che=
ckers (such as<br>
&gt; &gt; valgrind) that may detect use of uninitialized data.<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0People can =3Ddelete the default ctor of the c=
ontained objects.<br>
&gt; &gt;<br>
&gt; &gt; - Alternative proposed solutions<br>
&gt; &gt;=C2=A0 =C2=A0 Solution 1: library approach. Provide a type wrapper=
 without a<br>
&gt; &gt; default ctor (such as initialization_required&lt;T&gt;). Such wra=
pper could<br>
&gt; &gt; be implemented extending the template type (inheriting from it) a=
nd<br>
&gt; &gt; removing the default ctor, and should be template-specialized for=
 PODs<br>
&gt; &gt; with all the operations of each POD.<br>
&gt; &gt;<br>
&gt; &gt; struct S<br>
&gt; &gt; {<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0initialization_required&lt;int&gt; x;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0initialization_required&lt;int&gt; y;<br>
&gt; &gt;=C2=A0 =C2=A0 S(/*some signature*/) : x(1) {} // error: y initiali=
zation missing<br>
&gt; &gt; };<br>
&gt; &gt;<br>
&gt; &gt;=C2=A0 =C2=A0 Solution 2: prefix the attribute declaration with so=
me keyword<br>
&gt; &gt; (such as &quot;explicit&quot;).<br>
&gt; &gt;<br>
&gt; &gt; struct S<br>
&gt; &gt; {<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0explicit int x;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0explicit int y;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0S(/*some signature*/) : x(1) {} // error: y is=
 uninitialized<br>
&gt; &gt; };<br>
&gt; &gt;<br>
&gt; &gt;=C2=A0 - Discussion: what happens with inheritance?<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 As mentioned above, this problem gets relevan=
t with PODs so<br>
&gt; &gt; inheritance wouldn&#39;t apply in that case (unless we propose th=
e ability<br>
&gt; &gt; to extend from PODs some day ;-) ).<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 Nevertheless, both solutions could be applica=
ble to inheritance:<br>
&gt; &gt;<br>
&gt; &gt; Sol1:=C2=A0 =C2=A0struct S : initialization_required&lt;T&gt; { .=
... };<br>
&gt; &gt; Sol2:=C2=A0 =C2=A0struct S : explicit T { ... };<br>
&gt; &gt;<br>
&gt; &gt; Ideas? Is this worth to write a formal proposal?<br>
&gt;<br>
&gt;<br>
&gt; Any particular reason why you&#39;re not using non-static data member =
initializers?</p>
<p dir=3D"ltr">Yes: because that solves a different problem, which is &quot=
;release the programmer to initialize the attribute always with the same va=
lue unless specified&quot; whereas the problem I want to address is &quot;r=
equire to ALWAYS initialize the attribute, no matter of the value (either a=
lways the same or some different)&quot;. Moreover, non-static member initia=
lization goes in the opposite direction of the intention of this issue.<br>=
</p>
<p dir=3D"ltr">&gt; That is,<br>
&gt; struct S<br>
&gt; =C2=A0{<br>
&gt; =C2=A0 =C2=A0 =C2=A0int x=3D42;<br>
&gt; =C2=A0 =C2=A0 =C2=A0int y=3D666;<br>
&gt; =C2=A0 =C2=A0 =C2=A0S(/*some signature*/) : x(1) {} // y is 666 since =
nothing else was provided<br>
&gt; };<br>
&gt;<br>
&gt; You can make the NSDMI throw or even terminate if explicit<br>
&gt; initialization is not provided<br>
&gt; in a ctor-initializer.<br>
&gt;<br>
&gt; --<br>
&gt;<br>
&gt; ---<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-propos=
als/</a>.<br>
</p>

<p></p>

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

--001a11334f14b0de730514e1f599--

.

On 29 April 2015 at 22:26, dgutson . <danielgutson@gmail.com> wrote:
>> Any particular reason why you're not using non-static data member
>> initializers?
> Yes: because that solves a different problem, which is "release the
> programmer to initialize the attribute always with the same value unless
> specified" whereas the problem I want to address is "require to ALWAYS
> initialize the attribute, no matter of the value (either always the same or
> some different)". Moreover, non-static member initialization goes in the
> opposite direction of the intention of this issue.


Right. In that case, a library type like non_default_constructible<T>
seems much saner
than a core language addition. However, that alone would be a
microscopic addition,
perhaps it would be better to add other utility types along it, like
explicit_constructible<T>.
The motivation for that is that you can't write things like
void f(explicit ClassType x); // no implicit conversions
and it's sometimes suggested that this could/should be done with
void f(explicit_constructible<ClassType> x); // no implicit
conversions, explicit_constructible doesn't
have them
In other words, such types form a general category, let's
strawman-call it "vocabulary utility
wrappers for controlling initialization", it would be better to
provide a more comprehensive
set than just one single utility type.

--

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

.

On Wed, Apr 29, 2015 at 4:39 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 29 April 2015 at 22:26, dgutson . <danielgutson@gmail.com> wrote:
>>> Any particular reason why you're not using non-static data member
>>> initializers?
>> Yes: because that solves a different problem, which is "release the
>> programmer to initialize the attribute always with the same value unless
>> specified" whereas the problem I want to address is "require to ALWAYS
>> initialize the attribute, no matter of the value (either always the same or
>> some different)". Moreover, non-static member initialization goes in the
>> opposite direction of the intention of this issue.
>
>
> Right. In that case, a library type like non_default_constructible<T>
> seems much saner
> than a core language addition. However, that alone would be a
> microscopic addition,
> perhaps it would be better to add other utility types along it, like
> explicit_constructible<T>.
> The motivation for that is that you can't write things like
> void f(explicit ClassType x); // no implicit conversions
> and it's sometimes suggested that this could/should be done with
> void f(explicit_constructible<ClassType> x); // no implicit
> conversions, explicit_constructible doesn't
> have them
> In other words, such types form a general category, let's
> strawman-call it "vocabulary utility
> wrappers for controlling initialization", it would be better to
> provide a more comprehensive
> set than just one single utility type.

So IIU you C, you are suggesting to provide a toolset to override the
constructors of an object from its instance declaration side,
so my example is a particular case where the default ctor is =deleted,
and in your example conversion ctors are =deleted.
Correct?

If such is the case, then I call for help for co-authors :) It's
rather a good amount of work both to survey the cases, and then the
reference library implementation, and finally the proposal writing.

Do you volunteer yourself? :)

  Daniel.

--

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

.

On 29 April 2015 at 22:58, dgutson . <danielgutson@gmail.com> wrote:
> So IIU you C, you are suggesting to provide a toolset to override the
> constructors of an object from its instance declaration side,
> so my example is a particular case where the default ctor is =deleted,
> and in your example conversion ctors are =deleted.
> Correct?

Perhaps not quite. I was envisioning roughly, simplified

template <class T>
struct non_default_constructible
{
    T t;
    non_default_constructible(const T& t); // this already turns off
the default constructor
};

template <class T>
struct explicit_constructible
{
    T t;
    explicit explicit_constructible(const T& t);
};

> If such is the case, then I call for help for co-authors :) It's
> rather a good amount of work both to survey the cases, and then the
> reference library implementation, and finally the proposal writing.
> Do you volunteer yourself? :)

I can provide some help, probably. In the case survey, in a reference
library implementation,
at least.

--

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

.

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

Can't this be done with C++11 attributes? It could just be a datamember
attribute that requires that member to be explicitly constructed. It would
be something like [[explicit_construction]] and would suggest that the
compiler emits a diagnostic if the member is not explicitly initialized.

I'm not a fan of the template approach because it changes the type of the
datamember and requires indirect access through the new datamember type
(i.e. via a get() accessor), all simply because we want the member to be
explicitly initialized. If this is really a desired feature, I think it
makes more sense as an in-language specifier/attribute.

On Wed, Apr 29, 2015 at 11:57 AM, dgutson . <danielgutson@gmail.com> wrote:

> I think I've seen this.
>
> Problem:
>   - when adding a new ctor, a programmer may inadvertently leave
> uninitialized attributes (specially PODs). Similarly, when adding a
> new attribute, a programmer may forget to call its ctor (or initialize
> it) in all the ctors of the class (again, specially when the new
> attribute is a POD).
>
> Problem Example1:
>
> //before the change:
> struct S
> {
>     int x;
>     S(/*some signature*/) : x(1) {}
> };
>
> //after the change:
> struct S
> {
>     int x;
>     S(/*some signature*/) : x(1) {}
>     S(/*some OTHER signature*/) {} // x is uninitialized
> };
>
> Problem Example 2:
> //before the change:
> struct S
> {
>     int x;
>     S(/*some signature*/) : x(1) {}
> };
>
> //after the change:
> struct S
> {
>     int x;
>     int y; // new attribute
>     S(/*some signature*/) : x(1) {} // y is uninitialized
> };
>
> - Why this problem is important?
>     The more attributes / ctors the class has, the problem gets worse
> (though that might be caused by a bad design of poor modularization).
>     The problem is relevant when writing maintainable code, since
> future maintainers may incur in the errors mentioned above.
>
> - How people is working around this issue nowadays?
>     There are both static checkers and dynamic checkers (such as
> valgrind) that may detect use of uninitialized data.
>     People can =3Ddelete the default ctor of the contained objects.
>
> - Alternative proposed solutions
>    Solution 1: library approach. Provide a type wrapper without a
> default ctor (such as initialization_required<T>). Such wrapper could
> be implemented extending the template type (inheriting from it) and
> removing the default ctor, and should be template-specialized for PODs
> with all the operations of each POD.
>
> struct S
> {
>     initialization_required<int> x;
>     initialization_required<int> y;
>    S(/*some signature*/) : x(1) {} // error: y initialization missing
> };
>
>    Solution 2: prefix the attribute declaration with some keyword
> (such as "explicit").
>
> struct S
> {
>     explicit int x;
>     explicit int y;
>     S(/*some signature*/) : x(1) {} // error: y is uninitialized
> };
>
>  - Discussion: what happens with inheritance?
>      As mentioned above, this problem gets relevant with PODs so
> inheritance wouldn't apply in that case (unless we propose the ability
> to extend from PODs some day ;-) ).
>      Nevertheless, both solutions could be applicable to inheritance:
>
> Sol1:   struct S : initialization_required<T> { ... };
> Sol2:   struct S : explicit T { ... };
>
> Ideas? Is this worth to write a formal proposal?
>
> Thanks,
>
>     Daniel.
>
>
>
> --
> Who=E2=80=99s got the sweetest disposition?
> One guess, that=E2=80=99s who?
> Who=E2=80=99d never, ever start an argument?
> Who never shows a bit of temperament?
> Who's never wrong but always right?
> Who'd never dream of starting a fight?
> Who get stuck with all the bad luck?
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

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

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

<div dir=3D"ltr">Can&#39;t this be done with C++11 attributes? It could jus=
t be a datamember attribute that requires that member to be explicitly cons=
tructed. It would be something like [[explicit_construction]] and would sug=
gest that the compiler emits a diagnostic if the member is not explicitly i=
nitialized.<div><br></div><div>I&#39;m not a fan of the template approach b=
ecause it changes the type of the datamember and requires indirect access t=
hrough the new datamember type (i.e. via a get() accessor), all simply beca=
use we want the member to be explicitly initialized. If this is really a de=
sired feature, I think it makes more sense as an in-language specifier/attr=
ibute.</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"=
>On Wed, Apr 29, 2015 at 11:57 AM, dgutson . <span dir=3D"ltr">&lt;<a href=
=3D"mailto:danielgutson@gmail.com" target=3D"_blank">danielgutson@gmail.com=
</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think I&#39;ve s=
een this.<br>
<br>
Problem:<br>
=C2=A0 - when adding a new ctor, a programmer may inadvertently leave<br>
uninitialized attributes (specially PODs). Similarly, when adding a<br>
new attribute, a programmer may forget to call its ctor (or initialize<br>
it) in all the ctors of the class (again, specially when the new<br>
attribute is a POD).<br>
<br>
Problem Example1:<br>
<br>
//before the change:<br>
struct S<br>
{<br>
=C2=A0 =C2=A0 int x;<br>
=C2=A0 =C2=A0 S(/*some signature*/) : x(1) {}<br>
};<br>
<br>
//after the change:<br>
struct S<br>
{<br>
=C2=A0 =C2=A0 int x;<br>
=C2=A0 =C2=A0 S(/*some signature*/) : x(1) {}<br>
=C2=A0 =C2=A0 S(/*some OTHER signature*/) {} // x is uninitialized<br>
};<br>
<br>
Problem Example 2:<br>
//before the change:<br>
struct S<br>
{<br>
=C2=A0 =C2=A0 int x;<br>
=C2=A0 =C2=A0 S(/*some signature*/) : x(1) {}<br>
};<br>
<br>
//after the change:<br>
struct S<br>
{<br>
=C2=A0 =C2=A0 int x;<br>
=C2=A0 =C2=A0 int y; // new attribute<br>
=C2=A0 =C2=A0 S(/*some signature*/) : x(1) {} // y is uninitialized<br>
};<br>
<br>
- Why this problem is important?<br>
=C2=A0 =C2=A0 The more attributes / ctors the class has, the problem gets w=
orse<br>
(though that might be caused by a bad design of poor modularization).<br>
=C2=A0 =C2=A0 The problem is relevant when writing maintainable code, since=
<br>
future maintainers may incur in the errors mentioned above.<br>
<br>
- How people is working around this issue nowadays?<br>
=C2=A0 =C2=A0 There are both static checkers and dynamic checkers (such as<=
br>
valgrind) that may detect use of uninitialized data.<br>
=C2=A0 =C2=A0 People can =3Ddelete the default ctor of the contained object=
s.<br>
<br>
- Alternative proposed solutions<br>
=C2=A0 =C2=A0Solution 1: library approach. Provide a type wrapper without a=
<br>
default ctor (such as initialization_required&lt;T&gt;). Such wrapper could=
<br>
be implemented extending the template type (inheriting from it) and<br>
removing the default ctor, and should be template-specialized for PODs<br>
with all the operations of each POD.<br>
<br>
struct S<br>
{<br>
=C2=A0 =C2=A0 initialization_required&lt;int&gt; x;<br>
=C2=A0 =C2=A0 initialization_required&lt;int&gt; y;<br>
=C2=A0 =C2=A0S(/*some signature*/) : x(1) {} // error: y initialization mis=
sing<br>
};<br>
<br>
=C2=A0 =C2=A0Solution 2: prefix the attribute declaration with some keyword=
<br>
(such as &quot;explicit&quot;).<br>
<br>
struct S<br>
{<br>
=C2=A0 =C2=A0 explicit int x;<br>
=C2=A0 =C2=A0 explicit int y;<br>
=C2=A0 =C2=A0 S(/*some signature*/) : x(1) {} // error: y is uninitialized<=
br>
};<br>
<br>
=C2=A0- Discussion: what happens with inheritance?<br>
=C2=A0 =C2=A0 =C2=A0As mentioned above, this problem gets relevant with POD=
s so<br>
inheritance wouldn&#39;t apply in that case (unless we propose the ability<=
br>
to extend from PODs some day ;-) ).<br>
=C2=A0 =C2=A0 =C2=A0Nevertheless, both solutions could be applicable to inh=
eritance:<br>
<br>
Sol1:=C2=A0 =C2=A0struct S : initialization_required&lt;T&gt; { ... };<br>
Sol2:=C2=A0 =C2=A0struct S : explicit T { ... };<br>
<br>
Ideas? Is this worth to write a formal proposal?<br>
<br>
Thanks,<br>
<br>
=C2=A0 =C2=A0 Daniel.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
<br>
--<br>
Who=E2=80=99s got the sweetest disposition?<br>
One guess, that=E2=80=99s who?<br>
Who=E2=80=99d never, ever start an argument?<br>
Who never shows a bit of temperament?<br>
Who&#39;s never wrong but always right?<br>
Who&#39;d never dream of starting a fight?<br>
Who get stuck with all the bad luck?<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

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

--001a113df4141ca8890514e28f54--

.

On 29 April 2015 at 23:09, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> Can't this be done with C++11 attributes? It could just be a datamember

No. This is semantic enforcement, and attributes are not meant for that.

> I'm not a fan of the template approach because it changes the type of the
> datamember and requires indirect access through the new datamember type
> (i.e. via a get() accessor), all simply because we want the member to be
> explicitly initialized. If this is really a desired feature, I think it
> makes more sense as an in-language specifier/attribute.

I don't think these problems we're solving are common and widespread enough for
a language specifier. Fair amounts of audiences won't use it, and they shouldn't
pay for it in implementation effort of the compiler vendors. The
library approach
is trivial to implement in comparison, and any half-competent
programmer can contribute
a library implementation.

--

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

.

On Wed, Apr 29, 2015 at 5:09 PM, 'Matt Calabrese' via ISO C++ Standard
- Future Proposals <std-proposals@isocpp.org> wrote:
> Can't this be done with C++11 attributes? It could just be a datamember

I don't back the attributes-solution because those are ignorable, and
I'm looking for a tool for the programmer to make a program
ill-formed if the data member wasn't initialized (or in Ville's,
example, the function argument comes from a conversion).

> attribute that requires that member to be explicitly constructed. It woul=
d
> be something like [[explicit_construction]] and would suggest that the
> compiler emits a diagnostic if the member is not explicitly initialized.
>
> I'm not a fan of the template approach because it changes the type of the
> datamember and requires indirect access through the new datamember type
> (i.e. via a get() accessor), all simply because we want the member to be

Well, a getter wouldn't be necessary in a good library design.

> explicitly initialized. If this is really a desired feature, I think it
> makes more sense as an in-language specifier/attribute.
>
> On Wed, Apr 29, 2015 at 11:57 AM, dgutson . <danielgutson@gmail.com> wrot=
e:
>>
>> I think I've seen this.
>>
>> Problem:
>>   - when adding a new ctor, a programmer may inadvertently leave
>> uninitialized attributes (specially PODs). Similarly, when adding a
>> new attribute, a programmer may forget to call its ctor (or initialize
>> it) in all the ctors of the class (again, specially when the new
>> attribute is a POD).
>>
>> Problem Example1:
>>
>> //before the change:
>> struct S
>> {
>>     int x;
>>     S(/*some signature*/) : x(1) {}
>> };
>>
>> //after the change:
>> struct S
>> {
>>     int x;
>>     S(/*some signature*/) : x(1) {}
>>     S(/*some OTHER signature*/) {} // x is uninitialized
>> };
>>
>> Problem Example 2:
>> //before the change:
>> struct S
>> {
>>     int x;
>>     S(/*some signature*/) : x(1) {}
>> };
>>
>> //after the change:
>> struct S
>> {
>>     int x;
>>     int y; // new attribute
>>     S(/*some signature*/) : x(1) {} // y is uninitialized
>> };
>>
>> - Why this problem is important?
>>     The more attributes / ctors the class has, the problem gets worse
>> (though that might be caused by a bad design of poor modularization).
>>     The problem is relevant when writing maintainable code, since
>> future maintainers may incur in the errors mentioned above.
>>
>> - How people is working around this issue nowadays?
>>     There are both static checkers and dynamic checkers (such as
>> valgrind) that may detect use of uninitialized data.
>>     People can =3Ddelete the default ctor of the contained objects.
>>
>> - Alternative proposed solutions
>>    Solution 1: library approach. Provide a type wrapper without a
>> default ctor (such as initialization_required<T>). Such wrapper could
>> be implemented extending the template type (inheriting from it) and
>> removing the default ctor, and should be template-specialized for PODs
>> with all the operations of each POD.
>>
>> struct S
>> {
>>     initialization_required<int> x;
>>     initialization_required<int> y;
>>    S(/*some signature*/) : x(1) {} // error: y initialization missing
>> };
>>
>>    Solution 2: prefix the attribute declaration with some keyword
>> (such as "explicit").
>>
>> struct S
>> {
>>     explicit int x;
>>     explicit int y;
>>     S(/*some signature*/) : x(1) {} // error: y is uninitialized
>> };
>>
>>  - Discussion: what happens with inheritance?
>>      As mentioned above, this problem gets relevant with PODs so
>> inheritance wouldn't apply in that case (unless we propose the ability
>> to extend from PODs some day ;-) ).
>>      Nevertheless, both solutions could be applicable to inheritance:
>>
>> Sol1:   struct S : initialization_required<T> { ... };
>> Sol2:   struct S : explicit T { ... };
>>
>> Ideas? Is this worth to write a formal proposal?
>>
>> Thanks,
>>
>>     Daniel.
>>
>>
>>
>> --
>> Who=E2=80=99s got the sweetest disposition?
>> One guess, that=E2=80=99s who?
>> Who=E2=80=99d never, ever start an argument?
>> Who never shows a bit of temperament?
>> Who's never wrong but always right?
>> Who'd never dream of starting a fight?
>> Who get stuck with all the bad luck?
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.



--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=20

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

.

On 29 April 2015 at 23:09, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> I'm not a fan of the template approach because it changes the type of the
> datamember and requires indirect access through the new datamember type
> (i.e. via a get() accessor), all simply because we want the member to be

Thus far I see no reason not to make the wrappers implicitly
convertible to their
underlying types. You would need an explicit conversion expression if
you need to deal
with type deduction, though.

--

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

.

--047d7bd7648e6cde860514e2a253
Content-Type: text/plain; charset=UTF-8

On Wed, Apr 29, 2015 at 1:02 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 29 April 2015 at 22:58, dgutson . <danielgutson@gmail.com> wrote:
> > So IIU you C, you are suggesting to provide a toolset to override the
> > constructors of an object from its instance declaration side,
> > so my example is a particular case where the default ctor is =deleted,
> > and in your example conversion ctors are =deleted.
> > Correct?
>
> Perhaps not quite. I was envisioning roughly, simplified
>
> template <class T>
> struct non_default_constructible
> {
>     T t;
>     non_default_constructible(const T& t); // this already turns off
> the default constructor
> };
>

That would inhibit the default move, etc. What you'd really want is
something that forwards all of the arguments. Probably it would have a
single variadic constructor that takes std::in_place_t (ala proposed
std::optional), and forwards the remaining arguments. This would
effectively disable the default constructor, allow forwarding, and not
inhibit or change existing move/copy operations if they exist.

Anyway, I still think this template might be an inadvisable solution.

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Apr 29, 2015 at 1:02 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span c=
lass=3D"">On 29 April 2015 at 22:58, dgutson . &lt;<a href=3D"mailto:daniel=
gutson@gmail.com">danielgutson@gmail.com</a>&gt; wrote:<br>
&gt; So IIU you C, you are suggesting to provide a toolset to override the<=
br>
&gt; constructors of an object from its instance declaration side,<br>
&gt; so my example is a particular case where the default ctor is =3Ddelete=
d,<br>
&gt; and in your example conversion ctors are =3Ddeleted.<br>
&gt; Correct?<br>
<br>
</span>Perhaps not quite. I was envisioning roughly, simplified<br>
<br>
template &lt;class T&gt;<br>
struct non_default_constructible<br>
{<br>
=C2=A0 =C2=A0 T t;<br>
=C2=A0 =C2=A0 non_default_constructible(const T&amp; t); // this already tu=
rns off<br>
the default constructor<br>
};<span class=3D""><br></span></blockquote><div><br></div><div>That would i=
nhibit the default move, etc. What you&#39;d really want is something that =
forwards all of the arguments. Probably it would have a single variadic con=
structor that takes std::in_place_t (ala proposed std::optional), and forwa=
rds the remaining arguments. This would effectively disable the default con=
structor, allow forwarding, and not inhibit or change existing move/copy op=
erations if they exist.</div><div><br></div><div>Anyway, I still think this=
 template might be an inadvisable solution.</div></div></div></div>

<p></p>

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

--047d7bd7648e6cde860514e2a253--

.

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

On Wed, Apr 29, 2015 at 1:14 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 29 April 2015 at 23:09, 'Matt Calabrese' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
> > I'm not a fan of the template approach because it changes the type of the
> > datamember and requires indirect access through the new datamember type
> > (i.e. via a get() accessor), all simply because we want the member to be
>
> Thus far I see no reason not to make the wrappers implicitly
> convertible to their
> underlying types. You would need an explicit conversion expression if
> you need to deal
> with type deduction, though.


Please let's not do this. It also doesn't really solve the problem since
that won't allow you to directly access the type's datamembers or
functions. For that you'd at least need something like an overloaded
operator->, or you'd have to go through .get() or the public datamember.

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Apr 29, 2015 at 1:14 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 29 A=
pril 2015 at 23:09, &#39;Matt Calabrese&#39; via ISO C++ Standard -<br>
<span class=3D"">Future Proposals &lt;<a href=3D"mailto:std-proposals@isocp=
p.org">std-proposals@isocpp.org</a>&gt; wrote:<br>
&gt; I&#39;m not a fan of the template approach because it changes the type=
 of the<br>
&gt; datamember and requires indirect access through the new datamember typ=
e<br>
&gt; (i.e. via a get() accessor), all simply because we want the member to =
be<br>
<br>
</span>Thus far I see no reason not to make the wrappers implicitly<br>
convertible to their<br>
underlying types. You would need an explicit conversion expression if<br>
you need to deal<br>
with type deduction, though.</blockquote><div><br></div><div>Please let&#39=
;s not do this. It also doesn&#39;t really solve the problem since that won=
&#39;t allow you to directly access the type&#39;s datamembers or functions=
.. For that you&#39;d at least need something like an overloaded operator-&g=
t;, or you&#39;d have to go through .get() or the public datamember.=C2=A0<=
/div></div></div></div>

<p></p>

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

--001a113cb374c12c1f0514e2a86f--

.

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

On Wed, Apr 29, 2015 at 1:13 PM, dgutson . <danielgutson@gmail.com> wrote:

> Well, a getter wouldn't be necessary in a good library design.
>

I disagree. A good library design for something like this requires either a
getter or a public datamember.

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Apr 29, 2015 at 1:13 PM, dgutson . <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:danielgutson@gmail.com" target=3D"_blank">danielgutson@gmail.com</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex">Well, a getter wouldn&#39=
;t be necessary in a good library design.<br></blockquote><div><br></div><d=
iv>I disagree. A good library design for something like this requires eithe=
r a getter or a public datamember.</div></div></div></div>

<p></p>

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

--e89a8fb1f324a7219f0514e2ad8d--

.

On 29 April 2015 at 23:15, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
>> Perhaps not quite. I was envisioning roughly, simplified
>>
>> template <class T>
>> struct non_default_constructible
>> {
>>     T t;
>>     non_default_constructible(const T& t); // this already turns off
>> the default constructor
>> };
> That would inhibit the default move, etc. What you'd really want is

That struct has implicitly generated copy/move operations, so I don't
quite follow
what inhibits what.

> something that forwards all of the arguments. Probably it would have a

Probably, but as I said, that was a simplified example, not a complete API.

> Anyway, I still think this template might be an inadvisable solution.

Well, explicit function parameters, for example, have been suggested
before. The committee
answers "use a wrapper type that is not implicitly convertible, you'll
have to change the function
declaration anyway". So, it's unlikely that you'll get the core
language specifiers you want.

--

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

.

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

On Wed, Apr 29, 2015 at 1:12 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 29 April 2015 at 23:09, 'Matt Calabrese' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
> > Can't this be done with C++11 attributes? It could just be a datamember
>
> No. This is semantic enforcement, and attributes are not meant for that.


No it isn't. This is fine for an attribute. There is no functional change
if the attribute were to be ignored -- it's existence is just a suggestion
to emit a diagnostic if the member isn't explicitly initialized.

Anyway, since the attribute can obviously be ignored, I think it probably
makes more sense for it to just be a direct language feature, but I really
strongly feel that making a template wrapper here solely for constructor
behavior is straying down the wrong path.

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Apr 29, 2015 at 1:12 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 29 A=
pril 2015 at 23:09, &#39;Matt Calabrese&#39; via ISO C++ Standard -<br>
<span class=3D"">Future Proposals &lt;<a href=3D"mailto:std-proposals@isocp=
p.org">std-proposals@isocpp.org</a>&gt; wrote:<br>
&gt; Can&#39;t this be done with C++11 attributes? It could just be a datam=
ember<br>
<br>
</span>No. This is semantic enforcement, and attributes are not meant for t=
hat.</blockquote><div><br></div><div>No it isn&#39;t. This is fine for an a=
ttribute. There is no functional change if the attribute were to be ignored=
 -- it&#39;s existence is just a suggestion to emit a diagnostic if the mem=
ber isn&#39;t explicitly initialized.</div><div><br></div><div>Anyway, sinc=
e the attribute can obviously be ignored, I think it probably makes more se=
nse for it to just be a direct language feature, but I really strongly feel=
 that making a template wrapper here solely for constructor behavior is str=
aying down the wrong path.=C2=A0</div></div></div></div>

<p></p>

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

--001a11c1ccc8b14f970514e2b7de--

.

On 29 April 2015 at 23:21, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> On Wed, Apr 29, 2015 at 1:12 PM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
>>
>> On 29 April 2015 at 23:09, 'Matt Calabrese' via ISO C++ Standard -
>> Future Proposals <std-proposals@isocpp.org> wrote:
>> > Can't this be done with C++11 attributes? It could just be a datamember
>>
>> No. This is semantic enforcement, and attributes are not meant for that.
>
>
> No it isn't. This is fine for an attribute. There is no functional change if
> the attribute were to be ignored -- it's existence is just a suggestion to
> emit a diagnostic if the member isn't explicitly initialized.

No functional change? We want to enforce non-default initialization, ignoring
the attribute will allow such initialization. If that's not a
functional change, I want
to hear the definition of a "functional change".

> Anyway, since the attribute can obviously be ignored, I think it probably
> makes more sense for it to just be a direct language feature, but I really
> strongly feel that making a template wrapper here solely for constructor
> behavior is straying down the wrong path.

We can certainly agree to disagree. If we disagree strongly enough,
we'll keep the
language as it is, status quo doesn't need consensus to prevail.

--

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

.

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

On Wed, Apr 29, 2015 at 1:20 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 29 April 2015 at 23:15, 'Matt Calabrese' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
> >> Perhaps not quite. I was envisioning roughly, simplified
> >>
> >> template <class T>
> >> struct non_default_constructible
> >> {
> >>     T t;
> >>     non_default_constructible(const T& t); // this already turns off
> >> the default constructor
> >> };
> > That would inhibit the default move, etc. What you'd really want is
>
> That struct has implicitly generated copy/move operations, so I don't
> quite follow
> what inhibits what.
>

Oh sorry, I misread. I thought you were declaring a copy constructor.

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Apr 29, 2015 at 1:20 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 29 A=
pril 2015 at 23:15, &#39;Matt Calabrese&#39; via ISO C++ Standard -<br>
<span class=3D"">Future Proposals &lt;<a href=3D"mailto:std-proposals@isocp=
p.org">std-proposals@isocpp.org</a>&gt; wrote:<br>
&gt;&gt; Perhaps not quite. I was envisioning roughly, simplified<br>
&gt;&gt;<br>
&gt;&gt; template &lt;class T&gt;<br>
&gt;&gt; struct non_default_constructible<br>
&gt;&gt; {<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0T t;<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0non_default_constructible(const T&amp; t); // t=
his already turns off<br>
&gt;&gt; the default constructor<br>
&gt;&gt; };<br>
&gt; That would inhibit the default move, etc. What you&#39;d really want i=
s<br>
<br>
</span>That struct has implicitly generated copy/move operations, so I don&=
#39;t<br>
quite follow<br>
what inhibits what.<br></blockquote><div><br></div><div>Oh sorry, I misread=
.. I thought you were declaring a copy constructor.<br></div></div></div></d=
iv>

<p></p>

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

--001a113ce7ac0aa3db0514e2bff7--

.

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

On Wed, Apr 29, 2015 at 1:22 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 29 April 2015 at 23:21, 'Matt Calabrese' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
> > On Wed, Apr 29, 2015 at 1:12 PM, Ville Voutilainen
> > <ville.voutilainen@gmail.com> wrote:
> >>
> >> On 29 April 2015 at 23:09, 'Matt Calabrese' via ISO C++ Standard -
> >> Future Proposals <std-proposals@isocpp.org> wrote:
> >> > Can't this be done with C++11 attributes? It could just be a
> datamember
> >>
> >> No. This is semantic enforcement, and attributes are not meant for that.
> >
> >
> > No it isn't. This is fine for an attribute. There is no functional
> change if
> > the attribute were to be ignored -- it's existence is just a suggestion
> to
> > emit a diagnostic if the member isn't explicitly initialized.
>
> No functional change? We want to enforce non-default initialization,
> ignoring
> the attribute will allow such initialization. If that's not a
> functional change, I want
> to hear the definition of a "functional change".
>

That's why I said the behavior of the attribute is only to suggest emitting
a diagnostic. Compilers that support the attribute could simply output a
warning that says "hey, this isn't explicitly initialized." It's also why I
think direct language support is better, but an attribute form is fine and
compilers are free to implement something like that already.

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Apr 29, 2015 at 1:22 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 29 A=
pril 2015 at 23:21, &#39;Matt Calabrese&#39; via ISO C++ Standard -<br>
<span class=3D"">Future Proposals &lt;<a href=3D"mailto:std-proposals@isocp=
p.org">std-proposals@isocpp.org</a>&gt; wrote:<br>
&gt; On Wed, Apr 29, 2015 at 1:12 PM, Ville Voutilainen<br>
&gt; &lt;<a href=3D"mailto:ville.voutilainen@gmail.com">ville.voutilainen@g=
mail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On 29 April 2015 at 23:09, &#39;Matt Calabrese&#39; via ISO C++ St=
andard -<br>
&gt;&gt; Future Proposals &lt;<a href=3D"mailto:std-proposals@isocpp.org">s=
td-proposals@isocpp.org</a>&gt; wrote:<br>
&gt;&gt; &gt; Can&#39;t this be done with C++11 attributes? It could just b=
e a datamember<br>
&gt;&gt;<br>
&gt;&gt; No. This is semantic enforcement, and attributes are not meant for=
 that.<br>
&gt;<br>
&gt;<br>
&gt; No it isn&#39;t. This is fine for an attribute. There is no functional=
 change if<br>
&gt; the attribute were to be ignored -- it&#39;s existence is just a sugge=
stion to<br>
&gt; emit a diagnostic if the member isn&#39;t explicitly initialized.<br>
<br>
</span>No functional change? We want to enforce non-default initialization,=
 ignoring<br>
the attribute will allow such initialization. If that&#39;s not a<br>
functional change, I want<br>
to hear the definition of a &quot;functional change&quot;.<br></blockquote>=
<div><br></div><div>That&#39;s why I said the behavior of the attribute is =
only to suggest emitting a diagnostic. Compilers that support the attribute=
 could simply output a warning that says &quot;hey, this isn&#39;t explicit=
ly initialized.&quot; It&#39;s also why I think direct language support is =
better, but an attribute form is fine and compilers are free to implement s=
omething like that already.</div></div></div></div>

<p></p>

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

--001a113cb3745abf2b0514e2ccf1--

.

On 29 April 2015 at 23:26, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> That's why I said the behavior of the attribute is only to suggest emitting
> a diagnostic. Compilers that support the attribute could simply output a
> warning that says "hey, this isn't explicitly initialized." It's also why I
> think direct language support is better, but an attribute form is fine and
> compilers are free to implement something like that already.

An attribute doesn't provide any portable guarantee, so it's a
half-assed solution.
We could just as well solve this with a doxygen or clang-tool
extension, if we thought that's
sufficient. I don't think it is. I also think a core language
specifier is overkill, as I said before.

--

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

.

On Wed, Apr 29, 2015 at 5:26 PM, 'Matt Calabrese' via ISO C++ Standard
- Future Proposals <std-proposals@isocpp.org> wrote:
> On Wed, Apr 29, 2015 at 1:22 PM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
>>
>> On 29 April 2015 at 23:21, 'Matt Calabrese' via ISO C++ Standard -
>> Future Proposals <std-proposals@isocpp.org> wrote:
>> > On Wed, Apr 29, 2015 at 1:12 PM, Ville Voutilainen
>> > <ville.voutilainen@gmail.com> wrote:
>> >>
>> >> On 29 April 2015 at 23:09, 'Matt Calabrese' via ISO C++ Standard -
>> >> Future Proposals <std-proposals@isocpp.org> wrote:
>> >> > Can't this be done with C++11 attributes? It could just be a
>> >> > datamember
>> >>
>> >> No. This is semantic enforcement, and attributes are not meant for
>> >> that.
>> >
>> >
>> > No it isn't. This is fine for an attribute. There is no functional
>> > change if
>> > the attribute were to be ignored -- it's existence is just a suggestio=
n
>> > to
>> > emit a diagnostic if the member isn't explicitly initialized.
>>
>> No functional change? We want to enforce non-default initialization,
>> ignoring
>> the attribute will allow such initialization. If that's not a
>> functional change, I want
>> to hear the definition of a "functional change".
>
>
> That's why I said the behavior of the attribute is only to suggest emitti=
ng
> a diagnostic. Compilers that support the attribute could simply output a
> warning that says "hey, this isn't explicitly initialized." It's also why=
 I
> think direct language support is better, but an attribute form is fine an=
d
> compilers are free to implement something like that already.

As I said before, setting aside the implementation discussion for a
moment: my goal
is to consistently, strongly, reject data members initializations omissions=
..
No matter the compiler's vendor mood about it.
As strong as a type system violation.

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



--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=20

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

.

On Wed, Apr 29, 2015 at 03:57:21PM -0300, dgutson . wrote:
> I think I've seen this.
>
> Problem:
>   - when adding a new ctor, a programmer may inadvertently leave
> uninitialized attributes (specially PODs). Similarly, when adding a
> new attribute, a programmer may forget to call its ctor (or initialize
> it) in all the ctors of the class (again, specially when the new
> attribute is a POD).
>
> Problem Example1:
>
> //before the change:
> struct S
> {
>     int x;
>     S(/*some signature*/) : x(1) {}
> };

My gut solution would be the following:

struct require_initializer {
 template <class T> operator T () const; // no implementation!
};

struct S {
 int i = require_initializer();
 S() : i(17) { }
};

struct S2 {
 int i = require_initializer();
 S() : i(17) { }
 S(int) { }
};

The problematic part here is that the problem isn't detected until link time.

Adding the gcc error attribute to require_initializer::operator T gives a nice
compile error at the right place, but that fails the no semantic attributes
rule.

/MF

--

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

.

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

On Wed, Apr 29, 2015 at 2:01 PM, Magnus Fromreide <magfr@lysator.liu.se>
wrote:
>
> My gut solution would be the following:
>
> struct require_initializer {
>         template <class T> operator T () const; // no implementation!
> };
>
> struct S {
>         int i = require_initializer();
>         S() : i(17) { }
> };
>
> struct S2 {
>         int i = require_initializer();
>         S() : i(17) { }
>         S(int) { }
> };
>
> The problematic part here is that the problem isn't detected until link
> time.


Clever!

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Apr 29, 2015 at 2:01 PM, Magnus Fromreide <span dir=3D"ltr">&lt;<a href=
=3D"mailto:magfr@lysator.liu.se" target=3D"_blank">magfr@lysator.liu.se</a>=
&gt;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">My gut solution would be t=
he following:<br>
<br>
struct require_initializer {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 template &lt;class T&gt; operator T () const; /=
/ no implementation!<br>
};<br>
<br>
struct S {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 int i =3D require_initializer();<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 S() : i(17) { }<br>
};<br>
<br>
struct S2 {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 int i =3D require_initializer();<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 S() : i(17) { }<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 S(int) { }<br>
};<br>
<br>
The problematic part here is that the problem isn&#39;t detected until link=
 time.</blockquote><div><br></div><div>Clever!=C2=A0</div></div></div></div=
>

<p></p>

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

--001a1137c8460a4f6f0514e3557e--

.

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

On Wed, Apr 29, 2015 at 1:49 PM, dgutson . <danielgutson@gmail.com> wrote:
>
> As I said before, setting aside the implementation discussion for a
> moment: my goal
> is to consistently, strongly, reject data members initializations
> omissions.
> No matter the compiler's vendor mood about it.
> As strong as a type system violation.


Then my person feelings are language feature and not library feature (as in
solution 2 your original post). The library feature adds an extra level of
encapsulation and changes use of the datamember simply because a certain
constructor is not desired to be used. This requires changing code that is
unrelated to the constructor to accomodate it (I.E. code that accesses the
datamember).

Trying to do inheritance here has a lot of issues and also doesn't
completely solve the problem. For one, it only works for things you can
inherit from (I.E. not built-in types, which is probably the most common
case that people want to account for). Further, implicit conversion still
requires change of how you access the object if you need to access an
internal datamember (I.E. .get() or -> or cast). It will also break in
subtle ways when passed to functions because it affects overload
resolution. Perhaps the most obvious case that will break is when the
wrapper object is deduced upon passing it to a template. Finally, the
wrapper object needs to forward arguments to be a complete facility,
meaning it likely needs something like an in_place facility, so even how
you invoke the constructor the object would need to be changed. All of this
just because we want a diagnositic in case we forget to initialize the
datamember. A direct language facility just seems better all around to me
if this is considered a problem that is worth solving in the standard.

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Apr 29, 2015 at 1:49 PM, dgutson . <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:danielgutson@gmail.com" target=3D"_blank">danielgutson@gmail.com</a>&gt=
;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex">As I said before, setting aside the impleme=
ntation discussion for a<br>
moment: my goal<br>
is to consistently, strongly, reject data members initializations omissions=
..<br>
No matter the compiler&#39;s vendor mood about it.<br>
As strong as a type system violation.</blockquote><div><br></div><div>Then =
my person feelings are language feature and not library feature (as in solu=
tion 2 your original post). The library feature adds an extra level of enca=
psulation and changes use of the datamember simply because a certain constr=
uctor is not desired to be used. This requires changing code that is unrela=
ted to the constructor to accomodate it (I.E. code that accesses the datame=
mber).</div><div><br></div><div>Trying to do inheritance here has a lot of =
issues and also doesn&#39;t completely solve the problem. For one, it only =
works for things you can inherit from (I.E. not built-in types, which is pr=
obably the most common case that people want to account for). Further, impl=
icit conversion still requires change of how you access the object if you n=
eed to access an internal datamember (I.E. .get() or -&gt; or cast). It wil=
l also break in subtle ways when passed to functions because it affects ove=
rload resolution. Perhaps the most obvious case that will break is when the=
 wrapper object is deduced upon passing it to a template. Finally, the wrap=
per object needs to forward arguments to be a complete facility, meaning it=
 likely needs something like an in_place facility, so even how you invoke t=
he constructor the object would need to be changed. All of this just becaus=
e we want a diagnositic in case we forget to initialize the datamember. A d=
irect language facility just seems better all around to me if this is consi=
dered a problem that is worth solving in the standard.</div></div></div></d=
iv>

<p></p>

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

--001a113cb374f196a50514e37559--

.

On Wed, Apr 29, 2015 at 6:01 PM, Magnus Fromreide <magfr@lysator.liu.se> wr=
ote:
> On Wed, Apr 29, 2015 at 03:57:21PM -0300, dgutson . wrote:
>> I think I've seen this.
>>
>> Problem:
>>   - when adding a new ctor, a programmer may inadvertently leave
>> uninitialized attributes (specially PODs). Similarly, when adding a
>> new attribute, a programmer may forget to call its ctor (or initialize
>> it) in all the ctors of the class (again, specially when the new
>> attribute is a POD).
>>
>> Problem Example1:
>>
>> //before the change:
>> struct S
>> {
>>     int x;
>>     S(/*some signature*/) : x(1) {}
>> };
>
> My gut solution would be the following:
>
> struct require_initializer {
>         template <class T> operator T () const; // no implementation!
> };
>
> struct S {
>         int i =3D require_initializer();
>         S() : i(17) { }
> };
>
> struct S2 {
>         int i =3D require_initializer();
>         S() : i(17) { }
>         S(int) { }
> };
>
> The problematic part here is that the problem isn't detected until link t=
ime.

I must admit I would have never come up with this idea. I agree that is not
a *compiler* solution and not what I'm looking for.
But it's brilliant anyway :)

>
> Adding the gcc error attribute to require_initializer::operator T gives a=
 nice
> compile error at the right place, but that fails the no semantic attribut=
es
> rule.
>
> /MF
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups=
 "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
 email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-propo=
sals/.



--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=20

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

.

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

On 29 April 2015 at 16:01, Magnus Fromreide <magfr@lysator.liu.se> wrote:

> My gut solution would be the following:
>
> struct require_initializer {
>         template <class T> operator T () const; // no implementation!
> };
>
> struct S {
>         int i = require_initializer();
>         S() : i(17) { }
> };
>
> struct S2 {
>         int i = require_initializer();
>         S() : i(17) { }
>         S(int) { }
> };
>
> The problematic part here is that the problem isn't detected until link
> time.
>

Very clever!

I was wondering if it would work with std::declval<T>().  Checking with
clang 3.6:

libc++: always compiles; link time error if the variable is not initialized
by a constructor
libstdc++: never compiles

I wonder which one is correct (if not both)...
 Nevin :-)
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2=
9 April 2015 at 16:01, Magnus Fromreide <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:magfr@lysator.liu.se" target=3D"_blank">magfr@lysator.liu.se</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">My gut solution would be the=
 following:<br>
<br>
struct require_initializer {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 template &lt;class T&gt; operator T () const; /=
/ no implementation!<br>
};<br>
<br>
struct S {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 int i =3D require_initializer();<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 S() : i(17) { }<br>
};<br>
<br>
struct S2 {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 int i =3D require_initializer();<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 S() : i(17) { }<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 S(int) { }<br>
};<br>
<br>
The problematic part here is that the problem isn&#39;t detected until link=
 time.<br></blockquote><div><br></div><div>Very clever!</div><div><br></div=
><div>I was wondering if it would work with std::declval&lt;T&gt;().=C2=A0 =
Checking with clang 3.6:</div><div><br></div><div>libc++: always compiles; =
link time error if the variable is not initialized by a constructor</div><d=
iv>libstdc++: never compiles</div><div><br></div><div>I wonder which one is=
 correct (if not both)...</div><div>=C2=A0Nevin :-)</div></div>-- <br><div =
class=3D"gmail_signature">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailt=
o:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evilove=
rlord.com</a>&gt;=C2=A0 (847) 691-1404</div>
</div></div>

<p></p>

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

--089e013d04ee9906a60514e39354--

.

On 30 April 2015 at 00:14, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals > Then my person feelings are language feature and
not library feature (as in
> solution 2 your original post). The library feature adds an extra level of
> encapsulation and changes use of the datamember simply because a certain
> constructor is not desired to be used. This requires changing code that is
> unrelated to the constructor to accomodate it (I.E. code that accesses the
> datamember).

Mostly for cases where the member is passed to a deduced context.

> Trying to do inheritance here has a lot of issues and also doesn't
> completely solve the problem. For one, it only works for things you can
> inherit from (I.E. not built-in types, which is probably the most common
> case that people want to account for). Further, implicit conversion still
> requires change of how you access the object if you need to access an
> internal datamember (I.E. .get() or -> or cast). It will also break in

Unless, of course, we get operator. in which case it can be made more
transparent.

> subtle ways when passed to functions because it affects overload resolution.
> Perhaps the most obvious case that will break is when the wrapper object is
> deduced upon passing it to a template. Finally, the wrapper object needs to

Yep.

> forward arguments to be a complete facility, meaning it likely needs
> something like an in_place facility, so even how you invoke the constructor
> the object would need to be changed. All of this just because we want a

It doesn't need an in_place. If we add a variadic constructor, we merely need
to constrain it so that it's not enabled if the pack is the size of
one and the type
provided is not the wrapper itself.

--

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

.

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

On Wed, Apr 29, 2015 at 2:22 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> It doesn't need an in_place. If we add a variadic constructor, we merely
> need
> to constrain it so that it's not enabled if the pack is the size of
> one and the type
> provided is not the wrapper itself.


True.

Anyway, I really think the above problems are legitimate and are a
reasonable rationale for a language rather than library solution. Getting
such a wrapper "right" would be non-trivial and requires a complete
specification in the standard, with the solution necessarily having those
unfortunate subtleties (unless other changes were made to the language).
Something like the language-level solution suggested in the OP on the other
hand would likely be fairly trivial to specify in the standard and would be
easy for compilers to implement. It would also not have any of the library
subtleties. While I always favor libary-level over language-level solutions
when reasonably equivalent, I think this really makes more sense as a
language feature if it's considered a worthwhile problem to solve.

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Apr 29, 2015 at 2:22 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It does=
n&#39;t need an in_place. If we add a variadic constructor, we merely need<=
br>
to constrain it so that it&#39;s not enabled if the pack is the size of<br>
one and the type<br>
provided is not the wrapper itself.</blockquote><div><br></div><div>True.</=
div><div><br></div><div>Anyway, I really think the above problems are legit=
imate and are a reasonable rationale for a language rather than library sol=
ution. Getting such a wrapper &quot;right&quot; would be non-trivial and re=
quires a complete specification in the standard, with the solution necessar=
ily having those unfortunate subtleties (unless other changes were made to =
the language). Something like the language-level solution suggested in the =
OP on the other hand would likely be fairly trivial to specify in the stand=
ard and would be easy for compilers to implement. It would also not have an=
y of the library subtleties. While I always favor libary-level over languag=
e-level solutions when reasonably equivalent, I think this really makes mor=
e sense as a language feature if it&#39;s considered a worthwhile problem t=
o solve.</div></div></div></div>

<p></p>

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

--001a113cd1a443f94a0514e3babd--

.

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

On 29 April 2015 at 16:18, dgutson . <danielgutson@gmail.com> wrote:

> I must admit I would have never come up with this idea. I agree that is not
> a *compiler* solution and not what I'm looking for.
>

Other than the link time vs. compile time catch (which we had lived with
for decades when we wanted to make classes non-copyable), why not?

You are perfectly willing to live with:

struct S
{
    initialization_required<int> x;
    initialization_required<int> y;
   S(/*some signature*/) : x(1) {} // error: y initialization missing
};

   Solution 2: prefix the attribute declaration with some keyword
(such as "explicit").

struct S
{
    explicit int x;
    explicit int y;
    S(/*some signature*/) : x(1) {} // error: y is uninitialized
};

so it seems like you are just hung up on how to spell it.

Sure, it isn't a *compiler* solution.  But so what, if it solves the
problem?

Given your claim that this is an important problem, why wouldn't you use
this right now to solve it?  That way, you'd get lots of user experience,
and if it doesn't quite work, you'd be able to articulate your needs in a
possible future proposal.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2=
9 April 2015 at 16:18, dgutson . <span dir=3D"ltr">&lt;<a href=3D"mailto:da=
nielgutson@gmail.com" target=3D"_blank">danielgutson@gmail.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex"><div id=3D":8xq" class=3D"" style=3D"overflow=
:hidden">I must admit I would have never come up with this idea. I agree th=
at is not<br>
a *compiler* solution and not what I&#39;m looking for.<br></div></blockquo=
te></div><br>Other than the link time vs. compile time catch (which we had =
lived with for decades when we wanted to make classes non-copyable), why no=
t?</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">You=
 are perfectly willing to live with:</div><div class=3D"gmail_extra"><br></=
div><div class=3D"gmail_extra"><font face=3D"monospace, monospace" size=3D"=
1">struct S<br>{<br>=C2=A0 =C2=A0 initialization_required&lt;int&gt; x;<br>=
=C2=A0 =C2=A0 initialization_required&lt;int&gt; y;<br>=C2=A0 =C2=A0S(/*som=
e signature*/) : x(1) {} // error: y initialization missing<br>};<br><br>=
=C2=A0 =C2=A0Solution 2: prefix the attribute declaration with some keyword=
<br>(such as &quot;explicit&quot;).<br><br>struct S<br>{<br>=C2=A0 =C2=A0 e=
xplicit int x;<br>=C2=A0 =C2=A0 explicit int y;<br>=C2=A0 =C2=A0 S(/*some s=
ignature*/) : x(1) {} // error: y is uninitialized<br>};<br></font></div><d=
iv class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">so it seems l=
ike you are just hung up on how to spell it.</div><div class=3D"gmail_extra=
"><br></div><div class=3D"gmail_extra">Sure, it isn&#39;t a *compiler* solu=
tion.=C2=A0 But so what, if it solves the problem?</div><div class=3D"gmail=
_extra"><br></div><div class=3D"gmail_extra">Given your claim that this is =
an important problem, why wouldn&#39;t you use this right now to solve it?=
=C2=A0 That way, you&#39;d get lots of user experience, and if it doesn&#39=
;t quite work, you&#39;d be able to articulate your needs in a possible fut=
ure proposal.</div><div class=3D"gmail_extra">--=C2=A0<br></div><div class=
=3D"gmail_extra"><div class=3D"gmail_signature">=C2=A0Nevin &quot;:-)&quot;=
 Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D=
"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 (847) 691-1404</div>
</div></div>

<p></p>

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

--001a113d37aeb2f63c0514e3e8cc--

.

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

El 29/4/2015 18:46, "Nevin Liber" <nevin@eviloverlord.com> escribi=C3=B3:
>
> On 29 April 2015 at 16:18, dgutson . <danielgutson@gmail.com> wrote:
>>
>> I must admit I would have never come up with this idea. I agree that is
not
>> a *compiler* solution and not what I'm looking for.
>
>
> Other than the link time vs. compile time catch (which we had lived with
for decades when we wanted to make classes non-copyable), why not?

Because I need this for dynamic loading as well what means that this would
be moved to runtime, something you don't want in a satellite's mission
operation center or a drone :)

>
> You are perfectly willing to live with:
>
> struct S
> {
>     initialization_required<int> x;
>     initialization_required<int> y;
>    S(/*some signature*/) : x(1) {} // error: y initialization missing
> };
>
>    Solution 2: prefix the attribute declaration with some keyword
> (such as "explicit").
>
> struct S
> {
>     explicit int x;
>     explicit int y;
>     S(/*some signature*/) : x(1) {} // error: y is uninitialized
> };
>
> so it seems like you are just hung up on how to spell it.
>
> Sure, it isn't a *compiler* solution.  But so what, if it solves the
problem?
>
> Given your claim that this is an important problem, why wouldn't you use
this right now to solve it?  That way, you'd get lots of user experience,
and if it doesn't quite work, you'd be able to articulate your needs in a
possible future proposal.
> --
>  Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
http://groups.google.com/a/isocpp.org/group/std-proposals/.

--=20

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

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

<p dir=3D"ltr"><br>
El 29/4/2015 18:46, &quot;Nevin Liber&quot; &lt;<a href=3D"mailto:nevin@evi=
loverlord.com">nevin@eviloverlord.com</a>&gt; escribi=C3=B3:<br>
&gt;<br>
&gt; On 29 April 2015 at 16:18, dgutson . &lt;<a href=3D"mailto:danielgutso=
n@gmail.com">danielgutson@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; I must admit I would have never come up with this idea. I agree th=
at is not<br>
&gt;&gt; a *compiler* solution and not what I&#39;m looking for.<br>
&gt;<br>
&gt;<br>
&gt; Other than the link time vs. compile time catch (which we had lived wi=
th for decades when we wanted to make classes non-copyable), why not?<br></=
p>
<p dir=3D"ltr">Because I need this for dynamic loading as well what means t=
hat this would be moved to runtime, something you don&#39;t want in a satel=
lite&#39;s mission operation center or a drone :)</p>
<p dir=3D"ltr">&gt;<br>
&gt; You are perfectly willing to live with:<br>
&gt;<br>
&gt; struct S<br>
&gt; {<br>
&gt; =C2=A0 =C2=A0 initialization_required&lt;int&gt; x;<br>
&gt; =C2=A0 =C2=A0 initialization_required&lt;int&gt; y;<br>
&gt; =C2=A0 =C2=A0S(/*some signature*/) : x(1) {} // error: y initializatio=
n missing<br>
&gt; };<br>
&gt;<br>
&gt; =C2=A0 =C2=A0Solution 2: prefix the attribute declaration with some ke=
yword<br>
&gt; (such as &quot;explicit&quot;).<br>
&gt;<br>
&gt; struct S<br>
&gt; {<br>
&gt; =C2=A0 =C2=A0 explicit int x;<br>
&gt; =C2=A0 =C2=A0 explicit int y;<br>
&gt; =C2=A0 =C2=A0 S(/*some signature*/) : x(1) {} // error: y is uninitial=
ized<br>
&gt; };<br>
&gt;<br>
&gt; so it seems like you are just hung up on how to spell it.<br>
&gt;<br>
&gt; Sure, it isn&#39;t a *compiler* solution.=C2=A0 But so what, if it sol=
ves the problem?<br>
&gt;<br>
&gt; Given your claim that this is an important problem, why wouldn&#39;t y=
ou use this right now to solve it?=C2=A0 That way, you&#39;d get lots of us=
er experience, and if it doesn&#39;t quite work, you&#39;d be able to artic=
ulate your needs in a possible future proposal.<br>
&gt; --=C2=A0<br>
&gt; =C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:n=
evin@eviloverlord.com">nevin@eviloverlord.com</a>&gt;=C2=A0 (847) 691-1404<=
br>
&gt;<br>
&gt; -- <br>
&gt;<br>
&gt; --- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-propos=
als/</a>.<br>
</p>

<p></p>

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

--001a113f903640212a0514e41207--

.

On Wed, Apr 29, 2015 at 06:18:31PM -0300, dgutson . wrote:
> On Wed, Apr 29, 2015 at 6:01 PM, Magnus Fromreide <magfr@lysator.liu.se> wrote:
> > On Wed, Apr 29, 2015 at 03:57:21PM -0300, dgutson . wrote:
> >> I think I've seen this.
> >>
> >> Problem:
> >>   - when adding a new ctor, a programmer may inadvertently leave
> >> uninitialized attributes (specially PODs). Similarly, when adding a
> >> new attribute, a programmer may forget to call its ctor (or initialize
> >> it) in all the ctors of the class (again, specially when the new
> >> attribute is a POD).
> >>
> >> Problem Example1:
> >>
> >> //before the change:
> >> struct S
> >> {
> >>     int x;
> >>     S(/*some signature*/) : x(1) {}
> >> };
> >
> > My gut solution would be the following:
> >
> > struct require_initializer {
> >         template <class T> operator T () const; // no implementation!
> > };
> >
> > struct S {
> >         int i = require_initializer();
> >         S() : i(17) { }
> > };
> >
> > struct S2 {
> >         int i = require_initializer();
> >         S() : i(17) { }
> >         S(int) { }
> > };
> >
> > The problematic part here is that the problem isn't detected until link time.
>
> I must admit I would have never come up with this idea. I agree that is not
> a *compiler* solution and not what I'm looking for.
> But it's brilliant anyway :)
>
> >
> > Adding the gcc error attribute to require_initializer::operator T gives a nice
> > compile error at the right place, but that fails the no semantic attributes
> > rule.

I suppose I should add the gcc version as well:

struct require_initializer {
        template <class T> operator T () const
                __attribute__((error("Missing initialization")));
};

This one do fail during compilation but it depends on the GCC error attribute
so from that point of view it is bad, but for your code it might be helpful.

/MF

--

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

.

On Wednesday 29 April 2015 23:01:06 Magnus Fromreide wrote:
> On Wed, Apr 29, 2015 at 03:57:21PM -0300, dgutson . wrote:
> > I think I've seen this.
> >
> > Problem:
> >   - when adding a new ctor, a programmer may inadvertently leave
> >
> > uninitialized attributes (specially PODs). Similarly, when adding a
> > new attribute, a programmer may forget to call its ctor (or initialize
> > it) in all the ctors of the class (again, specially when the new
> > attribute is a POD).
> >
> > Problem Example1:
> >
> > //before the change:
> > struct S
> > {
> >
> >     int x;
> >     S(/*some signature*/) : x(1) {}
> >
> > };
>
> My gut solution would be the following:
>
> struct require_initializer {
>  template <class T> operator T () const; // no implementation!
> };
>
> struct S {
>  int i = require_initializer();
>  S() : i(17) { }
> };
>
> struct S2 {
>  int i = require_initializer();
>  S() : i(17) { }
>  S(int) { }
> };
>
> The problematic part here is that the problem isn't detected until link
> time.

Nice! I attempted to improve the solution a little:

  struct require_initializer_t {
    template <class T> operator T () const {
      static_assert(sizeof(T) != sizeof(T), "Variable not initialized");
      return T();
    }
  };
  const require_initializer_t require_initializer = {};

  struct S {
    int i = require_initializer;
    S() : i(17) { }
  };

  struct S2 {
    int i = require_initializer;
    S2() : i(17) { }
    S2(int) { }
  };

It fails in the static assert but the error also contains the point where the
error is originated from. Unfortunately, it fails for S, where
require_initializer is supposed to be ignored. Apparently, the compiler (gcc
4.9, clang 3.5) still instantiates the conversion operator template, even
though there's no need for that. I wonder if that can be considered as a
compiler bug?

The other drawback is that the compiler error does not point to the offending
constructor(s). I think this can only be achieved with support from the
compiler and requires an attribute or language feature.

--

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

.

--Apple-Mail=_5DC83BF4-463D-40CC-AAB4-948229176143
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9304=E2=80=9330, at 5:55 PM, Andrey Semashev <andrey.semash=
ev@gmail.com> wrote:
>=20
>      static_assert(sizeof(T) !=3D sizeof(T), "Variable not initialized");

This is a template with no well-formed specialization. The implementation i=
s free to simplify the expression to false and complain about the template,=
 not the use.

Also, I=E2=80=99m not sure that it=E2=80=99s better than defining the conve=
rsion function as deleted. The NSDM initializer needs to be equally well-fo=
rmed whether it=E2=80=99s ever used or not.

--=20

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

--Apple-Mail=_5DC83BF4-463D-40CC-AAB4-948229176143
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9304=
=E2=80=9330, at 5:55 PM, Andrey Semashev &lt;<a href=3D"mailto:andrey.semas=
hev@gmail.com" class=3D"">andrey.semashev@gmail.com</a>&gt; wrote:</div><br=
 class=3D"Apple-interchange-newline"><div class=3D""><span style=3D"font-fa=
mily: Helvetica; font-size: 12px; font-style: normal; font-variant: normal;=
 font-weight: normal; letter-spacing: normal; line-height: normal; orphans:=
 auto; text-align: start; text-indent: 0px; text-transform: none; white-spa=
ce: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px=
; float: none; display: inline !important;" class=3D"">&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;static_assert(sizeof(T) !=3D sizeof(T), "Variable not initialized=
");</span><br style=3D"font-family: Helvetica; font-size: 12px; font-style:=
 normal; font-variant: normal; font-weight: normal; letter-spacing: normal;=
 line-height: normal; orphans: auto; text-align: start; text-indent: 0px; t=
ext-transform: none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px;" class=3D""></div></blockquote></div><br cl=
ass=3D""><div class=3D"">This is a template with no well-formed specializat=
ion. The implementation is free to simplify the expression to false and com=
plain about the template, not the use.</div><div class=3D""><br class=3D"">=
</div><div class=3D"">Also, I=E2=80=99m not sure that it=E2=80=99s better t=
han defining the conversion function as deleted. The NSDM initializer needs=
 to be equally well-formed whether it=E2=80=99s ever used or not.</div></bo=
dy></html>

<p></p>

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

--Apple-Mail=_5DC83BF4-463D-40CC-AAB4-948229176143--

.

On Thursday 30 April 2015 22:44:11 David Krauss wrote:
> > On 2015=E2=80=9304=E2=80=9330, at 5:55 PM, Andrey Semashev <andrey.sema=
shev@gmail.com>=20
wrote:
> >      static_assert(sizeof(T) !=3D sizeof(T), "Variable not initialized"=
);
>=20
> This is a template with no well-formed specialization. The implementation=
 is
> free to simplify the expression to false and complain about the template,
> not the use.

The expression result formally depends on the template parameter. I also tr=
ied=20
more complicated conditions, with templates, it doesn't matter - the compil=
er=20
instantiates the operator template, which is unexpected (for me, at least).

> Also, I=E2=80=99m not sure that it=E2=80=99s better than defining the con=
version function as
> deleted. The NSDM initializer needs to be equally well-formed whether it=
=E2=80=99s
> ever used or not.

Whether it is well formed or not is decided on the template instantiation,=
=20
that's the point.

--=20

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

.

> On 2015=E2=80=9304=E2=80=9330, at 11:00 PM, Andrey Semashev <andrey.semas=
hev@gmail.com> wrote:
>=20
> The expression result formally depends on the template parameter.

Doesn=E2=80=99t matter, the compiler is allowed infinite wisdom in finding =
templates with no valid specialization. And it=E2=80=99s not required to co=
mplain when it finds one, so it=E2=80=99s effectively UB.

> I also tried=20
> more complicated conditions, with templates, it doesn't matter - the comp=
iler=20
> instantiates the operator template, which is unexpected (for me, at least=
).

So, it=E2=80=99s no better than =3D delete, and it doesn=E2=80=99t work.

Your earlier message was unclear and gave the impression that it was workin=
g.

It=E2=80=99s not a bug, the template is instantiated because the function i=
s used. An NSDMI is not an unevaluated operand, so [basic.def.odr] =C2=A73.=
2/2-3 and [temp.inst] =C2=A714.7.1/3 demand the instantiation.

> Whether it is well formed or not is decided on the template instantiation=
,=20
> that's the point.

The point is not to complain if the NSDMI is always overridden by a constru=
ctor or aggregate initializer.

--=20

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

.

(Intentionally top-posting)

Thanks everyone for giving feedback and participating in the discussion.

I think there's information enough to start the work now :)

  Daniel.

--

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

.

On 2015-04-29 17:14, 'Matt Calabrese' via ISO C++ Standard - Future
Proposals wrote:
> Then my person feelings are language feature and not library feature (as in
> solution 2 your original post). The library feature adds an extra level of
> encapsulation and changes use of the datamember simply because a certain
> constructor is not desired to be used. This requires changing code that is
> unrelated to the constructor to accomodate it (I.E. code that accesses the
> datamember).
>
> Trying to do inheritance here has a lot of issues and also doesn't
> completely solve the problem. For one, it only works for things you can
> inherit from (I.E. not built-in types, which is probably the most common
> case that people want to account for). Further, implicit conversion still
> requires change of how you access the object if you need to access an
> internal datamember (I.E. .get() or -> or cast). It will also break in
> subtle ways when passed to functions because it affects overload
> resolution. Perhaps the most obvious case that will break is when the
> wrapper object is deduced upon passing it to a template. Finally, the
> wrapper object needs to forward arguments to be a complete facility,
> meaning it likely needs something like an in_place facility, so even how
> you invoke the constructor the object would need to be changed. All of this
> just because we want a diagnositic in case we forget to initialize the
> datamember. A direct language facility just seems better all around to me
> if this is considered a problem that is worth solving in the standard.

It sounds like what you want is a type that can choose what constructors
to implement but, except in instances where it is being constructed, is
treated by the compiler as if it is actually some other type 'T'.
(Naturally, the compiler would in some way enforce that it exactly
contains a 'T' and nothing else.)

If the compiler provided a way to write such a class, this would not
only solve your problem, but could also be used to "fix" types (POD's
especially) that are not initialized by default construction, by
implementing such an object that provides a "correct" default ctor.

So, for example:

  explicit_init<int> a; // error: default ctor is deleted
  explicit_init<int> b{0}; // okay

  default_init<int> c; // c is initialized to int{}, i.e. 0

Note that typeof(b) == typeof(c) == int. Also note that I might
specialize default_init<T> for some class T that does not initialize
itself in its default ctor (e.g. Eigen matrices)... or if I am Evil, to
some POD type to give it a non-standard "default" value.

Such a class could not be used as a function argument, since it decays
to it's wrapped type as soon as it has been constructed. This means,
however, that you avoid the issues with overload resolution and the
like, and also that there is zero overhead to the class (except
*perhaps* a trivial overhead in the ctor, though more likely that is
inlined away).

Is it a good idea? I don't know. I can think of plenty of problems. On
the other hand, it would potentially solve multiple problems, which
might make it more attractive.

--
Matthew

--

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

.