------=_Part_1082_22253755.1363990816229
Content-Type: text/plain; charset=ISO-8859-1

C++ has always distinguished between initialization and assignment. I think
this is a good thing, but there needs to be more of a syntactic difference.
Not only does the proposed operator := ollow syntactic distinction, it has
additional advantages which I'm going to present.

Basically, within a function body := can only be used at the point of
definition of a variable. Example:
void foo()
{
    int x := 42;
    auto y := x;
}
For variable definitions, := allows one to omit 'auto'. This means that the
second definition is equivalent to:
y := x;

:= can also be used to initialize members instead of an initializer list.
void f(int);

struct foo
{
    foo(int n)
    {
        x := 42;
        int tmp = f(x);
        y := x / tmp;
        ++x;
        z := 1/n;
    }

    int x, y;
    double z;
};
This has the following advantages:

   - Code can be put before initialization (rarely needed, but when needed
   it currectly hurts)
   - Members do not need to be initialized in order of definition
   - Uninitialized members cannot be read before initialization and can't
   be used to initialize other variables (diagnostic required)

Also, := allows definitions to be searchable in code and might also help
tools.

What do you think? Is the committee willing to add a feature to the
language, that makes such fundamental changes to C++ style?

--

---
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/?hl=en.



------=_Part_1082_22253755.1363990816229
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

C++ has always distinguished between initialization and assignment. I think=
 this is a good thing, but there needs to be more of a syntactic difference=
.. Not only does the proposed operator :=3D ollow syntactic distinction, it =
has additional advantages which I'm going to present.<br><br>Basically, wit=
hin a function body :=3D can only be used at the point of definition of a v=
ariable. Example:<br><div class=3D"prettyprint" style=3D"background-color: =
rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; =
border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div=
 class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">void</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> foo</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> x </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">:=3D</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" c=
lass=3D"styled-by-prettify">42</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> y </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">:=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br></span></div></code></div>Fo=
r variable definitions, :=3D allows one to omit 'auto'. This means that the=
 second definition is equivalent to:<br><div class=3D"prettyprint" style=3D=
"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bo=
rder-style: solid; border-width: 1px; word-wrap: break-word;"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">y </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">:=3D</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> x</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br></span></div></code></div><br>:=3D can also be used to initialize memb=
ers instead of an initializer list.<br><div class=3D"prettyprint" style=3D"=
background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bor=
der-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D=
"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> f</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">int</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">struct</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> foo<br></span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; foo</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> n</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; x </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">:=3D</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #06=
6;" class=3D"styled-by-prettify">42</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> tmp </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> f</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbs=
p; &nbsp; &nbsp; y </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">:=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> x </span><span style=3D"color: #660;" class=3D"styled-by-prettify">/</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> tmp</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nb=
sp; </span><span style=3D"color: #660;" class=3D"styled-by-prettify">++</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">x</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; =
z </span><span style=3D"color: #660;" class=3D"styled-by-prettify">:=3D</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #066;" class=3D"styled-by-prettify">1</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">/</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">n</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br><br>&nbsp; &nbsp; </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> x</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> y</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nb=
sp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">double=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> z</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span></div></code></div>This has th=
e following advantages:<br><ul><li>Code can be put before initialization (r=
arely needed, but when needed it currectly hurts)</li><li>Members do not ne=
ed to be initialized in order of definition<br></li><li>Uninitialized membe=
rs cannot be read before initialization and can't be used to initialize oth=
er variables (diagnostic required)</li></ul><p>Also, :=3D allows definition=
s to be searchable in code and might also help tools.</p><p>What do you thi=
nk? Is the committee willing to add a feature to the language, that makes s=
uch fundamental changes to C++ style?<br></p>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1082_22253755.1363990816229--

.

On 23 March 2013 00:20,  <stackmachine@hotmail.com> wrote:
> C++ has always distinguished between initialization and assignment. I think
> this is a good thing, but there needs to be more of a syntactic difference.
> Not only does the proposed operator := ollow syntactic distinction, it has
> additional advantages which I'm going to present.

I seriously recommend dropping those alleged additional advantages, or
separating
them out.

> This has the following advantages:
> Code can be put before initialization (rarely needed, but when needed it
> currectly hurts)

If it hurts so much, you can already do it with a lambda as an initializer.

> What do you think? Is the committee willing to add a feature to the
> language, that makes such fundamental changes to C++ style?

The syntactic change would be at least worth considering. The other
stuff is likely to
suffer an ill fate.

--

---
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/?hl=en.



.

------=_Part_980_22641078.1363992174590
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Am Freitag, 22. M=E4rz 2013 23:26:29 UTC+1 schrieb Ville Voutilainen:
>
> On 23 March 2013 00:20,  <stackm...@hotmail.com <javascript:>> wrote:=20
> > C++ has always distinguished between initialization and assignment. I=
=20
> think=20
> > this is a good thing, but there needs to be more of a syntactic=20
> difference.=20
> > Not only does the proposed operator :=3D ollow syntactic distinction, i=
t=20
> has=20
> > additional advantages which I'm going to present.=20
>
> I seriously recommend dropping those alleged additional advantages, or=20
> separating=20
> them out.=20
>
I can see that the 'omit auto' thingy is not really related to :=3D or=20
important. It's just a convenience thing that would be possible because y =
=3D=20
x and y :=3D x are clearly different things.
=20

> > This has the following advantages:=20
> > Code can be put before initialization (rarely needed, but when needed i=
t=20
> > currectly hurts)=20
>
> If it hurts so much, you can already do it with a lambda as an=20
> initializer.=20
>
What if I want to have a local variable and use it in more than one=20
initialization? I can't think of any way that would allow this right now.=
=20
Also, a lambda is not really a solution, it's rather an ugly workaround.
=20

> > What do you think? Is the committee willing to add a feature to the=20
> > language, that makes such fundamental changes to C++ style?=20
>
> The syntactic change would be at least worth considering. The other=20
> stuff is likely to=20
> suffer an ill fate.=20
>
While I do understand, that omitting auto is just a minor convenionce=20
feature, I think the member initialization is very important. Initializer=
=20
lists are a good step towards the right direction, but they put unnecessary=
=20
restrictions on code.

--=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/?hl=3Den.



------=_Part_980_22641078.1363992174590
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>Am Freitag, 22. M=E4rz 2013 23:26:29 UTC+1 schrieb Ville Voutilaine=
n:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">On 23 March 2013 00:20, &nbs=
p;&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Ze=
LlWcVYGR0J">stackm...@hotmail.com</a>&gt; wrote: <br>&gt; C++ has always di=
stinguished between initialization and assignment. I think <br>&gt; this is=
 a good thing, but there needs to be more of a syntactic difference. <br>&g=
t; Not only does the proposed operator :=3D ollow syntactic distinction, it=
 has <br>&gt; additional advantages which I'm going to present. <br> <br>I =
seriously recommend dropping those alleged additional advantages, or <br>se=
parating <br>them out. <br></blockquote><div>I can see that the 'omit auto'=
 thingy is not really related to :=3D or important. It's just a convenience=
 thing that would be possible because y =3D x and y :=3D x are clearly diff=
erent things.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&=
gt; This has the following advantages: <br>&gt; Code can be put before init=
ialization (rarely needed, but when needed it <br>&gt; currectly hurts) <br=
> <br>If it hurts so much, you can already do it with a lambda as an initia=
lizer. <br></blockquote><div>What if I want to have a local variable and us=
e it in more than one initialization? I can't think of any way that would a=
llow this right now. Also, a lambda is not really a solution, it's rather a=
n ugly workaround.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">&gt; What do you think? Is the committee willing to add a feature to =
the <br>&gt; language, that makes such fundamental changes to C++ style? <b=
r> <br>The syntactic change would be at least worth considering. The other =
<br>stuff is likely to <br>suffer an ill fate. <br></blockquote><div>While =
I do understand, that omitting auto is just a minor convenionce feature, I =
think the member initialization is very important. Initializer lists are a =
good step towards the right direction, but they put unnecessary restriction=
s on code.<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_980_22641078.1363992174590--

.

On 23 March 2013 00:42,  <stackmachine@hotmail.com> wrote:
>> The syntactic change would be at least worth considering. The other
>> stuff is likely to
>> suffer an ill fate.
> While I do understand, that omitting auto is just a minor convenionce
> feature, I think the member initialization is very important. Initializer
> lists are a good step towards the right direction, but they put unnecessary
> restrictions on code.

The problem with such a delayed member initialization is that
currently a throwing
member initialization will exit the constructor with an exception, and
the object's
lifetime never begins. That's a feature, not a bug. I don't quite
grasp how you'd maintain
that guarantee when initializations happen inside the constructor body.

--

---
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/?hl=en.



.

------=_Part_1252_8941923.1363993372876
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Am Freitag, 22. M=E4rz 2013 23:46:36 UTC+1 schrieb Ville Voutilainen:
>
> On 23 March 2013 00:42,  <stackm...@hotmail.com <javascript:>> wrote:=20
> >> The syntactic change would be at least worth considering. The other=20
> >> stuff is likely to=20
> >> suffer an ill fate.=20
> > While I do understand, that omitting auto is just a minor convenionce=
=20
> > feature, I think the member initialization is very important.=20
> Initializer=20
> > lists are a good step towards the right direction, but they put=20
> unnecessary=20
> > restrictions on code.=20
>
> The problem with such a delayed member initialization is that=20
> currently a throwing=20
> member initialization will exit the constructor with an exception, and=20
> the object's=20
> lifetime never begins. That's a feature, not a bug. I don't quite=20
> grasp how you'd maintain=20
> that guarantee when initializations happen inside the constructor body.=
=20
>

I don't quite understand what the problem would be? If you want to, you can=
=20
think of it as like a nice syntax for your lambdas...=20

--=20

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



------=_Part_1252_8941923.1363993372876
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>Am Freitag, 22. M=E4rz 2013 23:46:36 UTC+1 schrieb Ville Voutilaine=
n:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">On 23 March 2013 00:42, &nbs=
p;&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"FL=
YT3-fuSSsJ">stackm...@hotmail.com</a>&gt; wrote: <br>&gt;&gt; The syntactic=
 change would be at least worth considering. The other <br>&gt;&gt; stuff i=
s likely to <br>&gt;&gt; suffer an ill fate. <br>&gt; While I do understand=
, that omitting auto is just a minor convenionce <br>&gt; feature, I think =
the member initialization is very important. Initializer <br>&gt; lists are=
 a good step towards the right direction, but they put unnecessary <br>&gt;=
 restrictions on code. <br> <br>The problem with such a delayed member init=
ialization is that <br>currently a throwing <br>member initialization will =
exit the constructor with an exception, and <br>the object's <br>lifetime n=
ever begins. That's a feature, not a bug. I don't quite <br>grasp how you'd=
 maintain <br>that guarantee when initializations happen inside the constru=
ctor body. <br></blockquote><div><br>I don't quite understand what the prob=
lem would be? If you want to, you can think of it as like a nice syntax for=
 your lambdas... <br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1252_8941923.1363993372876--

.

On 23 March 2013 01:02,  <stackmachine@hotmail.com> wrote:
>> The problem with such a delayed member initialization is that
>> currently a throwing
>> member initialization will exit the constructor with an exception, and
>> the object's
>> lifetime never begins. That's a feature, not a bug. I don't quite
>> grasp how you'd maintain
>> that guarantee when initializations happen inside the constructor body.
> I don't quite understand what the problem would be? If you want to, you c=
an
> think of it as like a nice syntax for your lambdas...

Do explain how in

X::X()
{
    try {
        x :=3D whatever;
   }=A0catch(...) {}
}

you ensure that an exception raised in 'whatever' is not stopped by
the catch clause. Also,
you mentioned diagnosing the uses of uninitialized members, I don't
see how you could
possibly require such a diagnostic when such uses may be beneath
arbitrary layers
of code the compiler might not see.

--=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/?hl=3Den.



.

------=_Part_1229_32437026.1363995202324
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Am Samstag, 23. M=E4rz 2013 00:06:13 UTC+1 schrieb Ville Voutilainen:
>
> On 23 March 2013 01:02,  <stackm...@hotmail.com <javascript:>> wrote:=20
> >> The problem with such a delayed member initialization is that=20
> >> currently a throwing=20
> >> member initialization will exit the constructor with an exception, and=
=20
> >> the object's=20
> >> lifetime never begins. That's a feature, not a bug. I don't quite=20
> >> grasp how you'd maintain=20
> >> that guarantee when initializations happen inside the constructor body=
..=20
> > I don't quite understand what the problem would be? If you want to, you=
=20
> can=20
> > think of it as like a nice syntax for your lambdas...=20
>
> Do explain how in=20
>
> X::X()=20
> {=20
>     try {=20
>         x :=3D whatever;=20
>    } catch(...) {}=20
> }=20
>
> you ensure that an exception raised in 'whatever' is not stopped by=20
> the catch clause. Also,=20
> you mentioned diagnosing the uses of uninitialized members, I don't=20
> see how you could=20
> possibly require such a diagnostic when such uses may be beneath=20
> arbitrary layers=20
> of code the compiler might not see.=20
>
Oh, I see. These are all things I have not yet thought about, as this is a=
=20
spontaneous idea. I just want some initial feedback before I start working=
=20
out the details.
=20

--=20

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



------=_Part_1229_32437026.1363995202324
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>Am Samstag, 23. M=E4rz 2013 00:06:13 UTC+1 schrieb Ville Voutilaine=
n:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">On 23 March 2013 01:02, &nbs=
p;&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"-Y=
Y9_FUY89QJ">stackm...@hotmail.com</a>&gt; wrote: <br>&gt;&gt; The problem w=
ith such a delayed member initialization is that <br>&gt;&gt; currently a t=
hrowing <br>&gt;&gt; member initialization will exit the constructor with a=
n exception, and <br>&gt;&gt; the object's <br>&gt;&gt; lifetime never begi=
ns. That's a feature, not a bug. I don't quite <br>&gt;&gt; grasp how you'd=
 maintain <br>&gt;&gt; that guarantee when initializations happen inside th=
e constructor body. <br>&gt; I don't quite understand what the problem woul=
d be? If you want to, you can <br>&gt; think of it as like a nice syntax fo=
r your lambdas... <br> <br>Do explain how in <br> <br>X::X() <br>{ <br>&nbs=
p; &nbsp; try { <br>&nbsp; &nbsp; &nbsp; &nbsp; x :=3D whatever; <br>&nbsp;=
 &nbsp;}&nbsp;catch(...) {} <br>} <br> <br>you ensure that an exception rai=
sed in 'whatever' is not stopped by <br>the catch clause. Also, <br>you men=
tioned diagnosing the uses of uninitialized members, I don't <br>see how yo=
u could <br>possibly require such a diagnostic when such uses may be beneat=
h <br>arbitrary layers <br>of code the compiler might not see. <br></blockq=
uote><div>Oh, I see. These are all things I have not yet thought about, as =
this is a spontaneous idea. I just want some initial feedback before I star=
t working out the details.<br>&nbsp;</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1229_32437026.1363995202324--

.

------=_Part_1205_6910233.1363996807688
Content-Type: text/plain; charset=ISO-8859-1

The analysis complexities can be solved by simply placing additional
restrictions on where member initialization can occur. Right now, I think
that a simple "Must be top-level constructor body" would suffice, as that
removes all conditionals and, indeed, try/catch.

Secondly, the new syntax can be used as a nice syntax for calling a
function with named arguments, something that C++ sorely needs.

--

---
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/?hl=en.



------=_Part_1205_6910233.1363996807688
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The analysis complexities can be solved by simply placing additional restri=
ctions on where member initialization can occur. Right now, I think that a =
simple "Must be top-level constructor body" would suffice, as that removes =
all conditionals and, indeed, try/catch.<div><br></div><div>Secondly, the n=
ew syntax can be used as a nice syntax for calling a function with named ar=
guments, something that C++ sorely needs.</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1205_6910233.1363996807688--

.

On 3/22/13, stackmachine@hotmail.com <stackmachine@hotmail.com> wrote:
> Am Samstag, 23. M=E4rz 2013 00:06:13 UTC+1 schrieb Ville Voutilainen:
> > On 23 March 2013 01:02,  <stackm...@hotmail.com <javascript:> > wrote:
> > > > The problem with such a delayed member initialization is
> > > > that currently a throwing member initialization will exit
> > > > the constructor with an exception, and the object's lifetime
> > > > never begins. That's a feature, not a bug. I don't quite
> > > > grasp how you'd maintain that guarantee when initializations
> > > > happen inside the constructor body.
> > >
> > > I don't quite understand what the problem would be? If you
> > > want to, you can think of it as like a nice syntax for your
> > > lambdas...
> >
> > Do explain how in
> >
> > X::X()
> > {
> >   try {
> >      x :=3D whatever;
> >   } catch(...) {}
> > }
> >
> > you ensure that an exception raised in 'whatever' is not stopped
> > by the catch clause. Also, you mentioned diagnosing the uses
> > of uninitialized members, I don't see how you could possibly
> > require such a diagnostic when such uses may be beneath arbitrary
> > layers of code the compiler might not see.
>
> Oh, I see. These are all things I have not yet thought about,
> as this is a spontaneous idea. I just want some initial feedback
> before I start working out the details.

Syntax changes like this always cost something in the wording of
the standard, the implementation of compilers, the training of
programmers, etc.

A small change, like being able to write

   sometype x :=3D 3;

instead of

   sometype x(3);

has relatively low cost, but it also has relatively low benefit.

Non-local changes, as you suggest with putting data member
initialization in constructor bodies, can have surprisingly deep
consequences and therefore large costs.

The fact that another language has a nicer syntax for something
does not necessarily imply that adding it to C++ is worth the cost.
Sometimes, we will need to settle for the existing syntax in order
to keep the language more managable.

With that context, you need to make the case that the benefit
exceeds the cost.  (I don't know whether it will or not.)

--=20
Lawrence Crowl

--=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/?hl=3Den.



.

------=_Part_2026_18069981.1364081911862
Content-Type: text/plain; charset=ISO-8859-1



> A small change, like being able to write
>
>    sometype x := 3;
>
> instead of
>
>    sometype x(3);
>
> has relatively low cost, but it also has relatively low benefit.
>
>
I'm not even sure about the low cost, as implementers have to change the
parser, and adding a new operator is worse than adding just a new keyword,
so the benefit should be high to justify it.. writing one simple line
instead of another, almost equally simple line justifies nothing in my
opinion.

Regards, Robert

--

---
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/?hl=en.



------=_Part_2026_18069981.1364081911862
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">A small change, like being=
 able to write <br> <br>&nbsp; &nbsp;sometype x :=3D 3; <br> <br>instead of=
 <br> <br>&nbsp; &nbsp;sometype x(3); <br> <br>has relatively low cost, but=
 it also has relatively low benefit. <br> <br></blockquote><div><br>I'm not=
 even sure about the low cost, as implementers have to change the parser, a=
nd adding a new operator is worse than adding just a new keyword, so the be=
nefit should be high to justify it.. writing one simple line instead of ano=
ther, almost equally simple line justifies nothing in my opinion.<br><br>Re=
gards, Robert<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2026_18069981.1364081911862--

.

------=_Part_170_21648561.1364226184005
Content-Type: text/plain; charset=ISO-8859-1



On Friday, March 22, 2013 10:42:54 PM UTC, stackm...@hotmail.com wrote:
>
>
> > This has the following advantages:
>
>> > Code can be put before initialization (rarely needed, but when needed
>> it
>> > currectly hurts)
>>
>> If it hurts so much, you can already do it with a lambda as an
>> initializer.
>>
> What if I want to have a local variable and use it in more than one
> initialization? I can't think of any way that would allow this right now.
>

A number of ways to do it are presented in Cassio Neri's article in
http://accu.org/var/uploads/journals/Overload112.pdf and as I point out on
the last page of http://accu.org/var/uploads/journals/Overload113.pdf
delegating constructors make it very easy to do.


--

---
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/?hl=en.



------=_Part_170_21648561.1364226184005
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Friday, March 22, 2013 10:42:54 PM UTC, stackm...@hotmail.com wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><br>&gt; This has the foll=
owing advantages: <br><blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; Code can=
 be put before initialization (rarely needed, but when needed it <br>&gt; c=
urrectly hurts) <br> <br>If it hurts so much, you can already do it with a =
lambda as an initializer. <br></blockquote><div>What if I want to have a lo=
cal variable and use it in more than one initialization? I can't think of a=
ny way that would allow this right now. <br></div></blockquote><div><br></d=
iv>A number of ways to do it are presented in Cassio Neri's article in http=
://accu.org/var/uploads/journals/Overload112.pdf and as I point out on the =
last page of http://accu.org/var/uploads/journals/Overload113.pdf delegatin=
g constructors make it very easy to do.<br><br><br>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_170_21648561.1364226184005--

.

------=_Part_1477_3094450.1364239993676
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Am Montag, 25. M=E4rz 2013 16:43:03 UTC+1 schrieb Jonathan Wakely:
>
>
>
> On Friday, March 22, 2013 10:42:54 PM UTC, stackm...@hotmail.com wrote:
>>
>>
>> > This has the following advantages:=20
>>
>>> > Code can be put before initialization (rarely needed, but when needed=
=20
>>> it=20
>>> > currectly hurts)=20
>>>
>>> If it hurts so much, you can already do it with a lambda as an=20
>>> initializer.=20
>>>
>> What if I want to have a local variable and use it in more than one=20
>> initialization? I can't think of any way that would allow this right now=
..=20
>>
>
> A number of ways to do it are presented in Cassio Neri's article in=20
> http://accu.org/var/uploads/journals/Overload112.pdf and as I point out=
=20
> on the last page of http://accu.org/var/uploads/journals/Overload113.pdfd=
elegating constructors make it very easy to do.
>
Looks more like a workaround than a solution. You define a private struct=
=20
and split the code up into more constructors. That's a lot of extra code,=
=20
just to make it work.

--=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/?hl=3Den.



------=_Part_1477_3094450.1364239993676
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>Am Montag, 25. M=E4rz 2013 16:43:03 UTC+1 schrieb Jonathan Wakely:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><br><br>On Friday, March 22, 20=
13 10:42:54 PM UTC, <a>stackm...@hotmail.com</a> wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><br>&gt; This has the following advantages: <br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex">&gt; Code can be put before initialization=
 (rarely needed, but when needed it <br>&gt; currectly hurts) <br> <br>If i=
t hurts so much, you can already do it with a lambda as an initializer. <br=
></blockquote><div>What if I want to have a local variable and use it in mo=
re than one initialization? I can't think of any way that would allow this =
right now. <br></div></blockquote><div><br></div>A number of ways to do it =
are presented in Cassio Neri's article in <a href=3D"http://accu.org/var/up=
loads/journals/Overload112.pdf" target=3D"_blank">http://accu.org/var/uploa=
ds/<wbr>journals/Overload112.pdf</a> and as I point out on the last page of=
 <a href=3D"http://accu.org/var/uploads/journals/Overload113.pdf" target=3D=
"_blank">http://accu.org/var/uploads/<wbr>journals/Overload113.pdf</a> dele=
gating constructors make it very easy to do.<br></blockquote><div>Looks mor=
e like a workaround than a solution. You define a private struct and split =
the code up into more constructors. That's a lot of extra code, just to mak=
e it work.<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1477_3094450.1364239993676--

.