------=_Part_1231_1084392551.1491230712839
Content-Type: multipart/alternative;
 boundary="----=_Part_1232_1182156914.1491230712839"

------=_Part_1232_1182156914.1491230712839
Content-Type: text/plain; charset=UTF-8

Hi,


I took part in so many syntax debates over the years on preferred variable
declaration syntax.

One of the neuralgic point of variable declaration syntax is the pointer
and reference alignment style.

The root problem is the following:

int* a, b;

This declares a pointer and an int which is confusing. So a common coding
style to avoid this error is aligning pointer to variables:

int *a, b;

Which is also confusing sometimes as some type parts are separated from the
"main" type.

What I suggest is a new variable declaration syntax:

// <type>:= <identifier1>, <identifier2>, ...;
// so I can write

int*:= a, b;

// or

int*:= a = nullptr, b = &a;

// the following won't compile:
int*:= *a, b;

To avoid the type syntax confusion I also propose to deprecate old style
variable declaration syntax as we can write tools to mechanically transform
the code bases to this new syntax.


I get this syntax from a previous thread:

A more consistent variable declaration syntax by Andy Prowl
https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/variable$20declaration/std-proposals/ITDME5hYiPw/l4HFz3jjik4J



Peter

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

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

<div dir=3D"ltr">Hi,<div><br></div><div><br></div><div>I took part in so ma=
ny syntax debates over the years on preferred variable declaration syntax.<=
/div><div><br></div><div>One of the neuralgic point of variable declaration=
 syntax is the pointer and reference alignment style.</div><div><br></div><=
div>The root problem is the following:<br></div><div><br></div><div><div cl=
ass=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-c=
olor: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap=
: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> a</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> b</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">;</span></div></code></div><br></div><div>This declares a p=
ointer and an int which is confusing. So a common coding style to avoid thi=
s error is aligning pointer to variables:</div><div><br></div><div><div cla=
ss=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-co=
lor: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap:=
 break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">a</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> b</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">;</span></div></code></div><br></div><div>Which is also confusing somet=
imes as some type parts are separated from the &quot;main&quot; type.</div>=
<div><br></div><div>What I suggest is a new variable declaration syntax:</d=
iv><div><br></div><div><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"><d=
iv class=3D"subprettyprint"><span style=3D"color: #800;" class=3D"styled-by=
-prettify">// &lt;type&gt;:=3D &lt;identifier1&gt;, &lt;identifier2&gt;, ..=
..;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></sp=
an><span style=3D"color: #800;" class=3D"styled-by-prettify">// so I can wr=
ite</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br=
></span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">*:=3D</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> a</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> b</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br><br></span><span style=3D"color: #800;" class=3D"s=
tyled-by-prettify">// or</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br><br></span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">int</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">*:=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 a </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: #008;" class=3D"styled-by-prettify">nullptr</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> b </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">a</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><b=
r></span><span style=3D"color: #800;" class=3D"styled-by-prettify">// the f=
ollowing won&#39;t compile:</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">int</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">*:=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">a</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> b</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">;</span></div></code></div><br></div><div>To =
avoid the type syntax confusion I also propose to deprecate old style varia=
ble declaration syntax as we can write tools to mechanically transform the =
code bases to this new syntax.</div><div><br></div><div><br></div><div>I ge=
t this syntax from a previous thread:=C2=A0<br></div><div><br></div>A more =
consistent variable declaration syntax by Andy Prowl <div><a href=3D"https:=
//groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/variable$20=
declaration/std-proposals/ITDME5hYiPw/l4HFz3jjik4J">https://groups.google.c=
om/a/isocpp.org/forum/#!searchin/std-proposals/variable$20declaration/std-p=
roposals/ITDME5hYiPw/l4HFz3jjik4J</a><br></div><div><br></div><div><br></di=
v><div><br></div><div>Peter</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/62e66de4-7c7a-4e1c-8343-b173b49cb594%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/62e66de4-7c7a-4e1c-8343-b173b49cb594=
%40isocpp.org</a>.<br />

------=_Part_1232_1182156914.1491230712839--

------=_Part_1231_1084392551.1491230712839--

.

On 3 April 2017 at 17:45,  <hun.nemethpeter@gmail.com> wrote:
> Hi,
>
>
> I took part in so many syntax debates over the years on preferred variable
> declaration syntax.
>
> One of the neuralgic point of variable declaration syntax is the pointer and
> reference alignment style.
>
> The root problem is the following:
>
> int* a, b;
>
> This declares a pointer and an int which is confusing. So a common coding
> style to avoid this error is aligning pointer to variables:
>
> int *a, b;
>
> Which is also confusing sometimes as some type parts are separated from the
> "main" type.

If either of those is confusing, then separate the declarations with a
semicolon and if you prefer, with a linefeed.

> What I suggest is a new variable declaration syntax:


That's a completely over-the-top solution to a non-issue that you have
other solutions for.

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

.

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

Hi Peter,

The problem can be solved with simple

  #include <functional>
  std::add_pointer_t<int> a,b;

Now both a and b are pointers.

Cheers,
Maxim

On Mon, Apr 3, 2017 at 10:45 PM, <hun.nemethpeter@gmail.com> wrote:

> Hi,
>
>
> I took part in so many syntax debates over the years on preferred variable
> declaration syntax.
>
> One of the neuralgic point of variable declaration syntax is the pointer
> and reference alignment style.
>
> The root problem is the following:
>
> int* a, b;
>
> This declares a pointer and an int which is confusing. So a common coding
> style to avoid this error is aligning pointer to variables:
>
> int *a, b;
>
> Which is also confusing sometimes as some type parts are separated from
> the "main" type.
>
> What I suggest is a new variable declaration syntax:
>
> // <type>:= <identifier1>, <identifier2>, ...;
> // so I can write
>
> int*:= a, b;
>
> // or
>
> int*:= a = nullptr, b = &a;
>
> // the following won't compile:
> int*:= *a, b;
>
> To avoid the type syntax confusion I also propose to deprecate old style
> variable declaration syntax as we can write tools to mechanically transform
> the code bases to this new syntax.
>
>
> I get this syntax from a previous thread:
>
> A more consistent variable declaration syntax by Andy Prowl
> https://groups.google.com/a/isocpp.org/forum/#!searchin/
> std-proposals/variable$20declaration/std-proposals/
> ITDME5hYiPw/l4HFz3jjik4J
>
>
>
> Peter
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/62e66de4-7c7a-4e1c-
> 8343-b173b49cb594%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/62e66de4-7c7a-4e1c-8343-b173b49cb594%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

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

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

<div dir=3D"ltr"><div><div><div><div>Hi Peter,<br><br></div>The problem can=
 be solved with simple<br><br><span style=3D"font-family:monospace,monospac=
e">=C2=A0 #include &lt;functional&gt;<br>=C2=A0 std::add_pointer_t&lt;int&g=
t; a,b;</span><br></div><br>Now both a and b are pointers.<br><br></div>Che=
ers,<br></div>Maxim<br></div><div class=3D"gmail_extra"><br><div class=3D"g=
mail_quote">On Mon, Apr 3, 2017 at 10:45 PM,  <span dir=3D"ltr">&lt;<a href=
=3D"mailto:hun.nemethpeter@gmail.com" target=3D"_blank">hun.nemethpeter@gma=
il.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr">Hi,<div><br></div><div><br></div><div>I took part in so many syntax de=
bates over the years on preferred variable declaration syntax.</div><div><b=
r></div><div>One of the neuralgic point of variable declaration syntax is t=
he pointer and reference alignment style.</div><div><br></div><div>The root=
 problem is the following:<br></div><div><br></div><div><div class=3D"m_-18=
93709385812725985prettyprint" style=3D"background-color:rgb(250,250,250);bo=
rder-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:b=
reak-word"><code class=3D"m_-1893709385812725985prettyprint"><div class=3D"=
m_-1893709385812725985subprettyprint"><span style=3D"color:#008" class=3D"m=
_-1893709385812725985styled-by-prettify">int</span><span style=3D"color:#66=
0" class=3D"m_-1893709385812725985styled-by-prettify">*</span><span style=
=3D"color:#000" class=3D"m_-1893709385812725985styled-by-prettify"> a</span=
><span style=3D"color:#660" class=3D"m_-1893709385812725985styled-by-pretti=
fy">,</span><span style=3D"color:#000" class=3D"m_-1893709385812725985style=
d-by-prettify"> b</span><span style=3D"color:#660" class=3D"m_-189370938581=
2725985styled-by-prettify">;</span></div></code></div><br></div><div>This d=
eclares a pointer and an int which is confusing. So a common coding style t=
o avoid this error is aligning pointer to variables:</div><div><br></div><d=
iv><div class=3D"m_-1893709385812725985prettyprint" style=3D"background-col=
or:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border=
-width:1px;word-wrap:break-word"><code class=3D"m_-1893709385812725985prett=
yprint"><div class=3D"m_-1893709385812725985subprettyprint"><span style=3D"=
color:#008" class=3D"m_-1893709385812725985styled-by-prettify">int</span><s=
pan style=3D"color:#000" class=3D"m_-1893709385812725985styled-by-prettify"=
> </span><span style=3D"color:#660" class=3D"m_-1893709385812725985styled-b=
y-prettify">*</span><span style=3D"color:#000" class=3D"m_-1893709385812725=
985styled-by-prettify">a</span><span style=3D"color:#660" class=3D"m_-18937=
09385812725985styled-by-prettify">,</span><span style=3D"color:#000" class=
=3D"m_-1893709385812725985styled-by-prettify"> b</span><span style=3D"color=
:#660" class=3D"m_-1893709385812725985styled-by-prettify">;</span></div></c=
ode></div><br></div><div>Which is also confusing sometimes as some type par=
ts are separated from the &quot;main&quot; type.</div><div><br></div><div>W=
hat I suggest is a new variable declaration syntax:</div><div><br></div><di=
v><div class=3D"m_-1893709385812725985prettyprint" style=3D"background-colo=
r:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-=
width:1px;word-wrap:break-word"><code class=3D"m_-1893709385812725985pretty=
print"><div class=3D"m_-1893709385812725985subprettyprint"><span style=3D"c=
olor:#800" class=3D"m_-1893709385812725985styled-by-prettify">// &lt;type&g=
t;:=3D &lt;identifier1&gt;, &lt;identifier2&gt;, ...;</span><span style=3D"=
color:#000" class=3D"m_-1893709385812725985styled-by-prettify"><br></span><=
span style=3D"color:#800" class=3D"m_-1893709385812725985styled-by-prettify=
">// so I can write</span><span style=3D"color:#000" class=3D"m_-1893709385=
812725985styled-by-prettify"><br><br></span><span style=3D"color:#008" clas=
s=3D"m_-1893709385812725985styled-by-prettify">int</span><span style=3D"col=
or:#660" class=3D"m_-1893709385812725985styled-by-prettify">*:=3D</span><sp=
an style=3D"color:#000" class=3D"m_-1893709385812725985styled-by-prettify">=
 a</span><span style=3D"color:#660" class=3D"m_-1893709385812725985styled-b=
y-prettify">,</span><span style=3D"color:#000" class=3D"m_-1893709385812725=
985styled-by-prettify"> b</span><span style=3D"color:#660" class=3D"m_-1893=
709385812725985styled-by-prettify">;</span><span style=3D"color:#000" class=
=3D"m_-1893709385812725985styled-by-prettify"><br><br></span><span style=3D=
"color:#800" class=3D"m_-1893709385812725985styled-by-prettify">// or</span=
><span style=3D"color:#000" class=3D"m_-1893709385812725985styled-by-pretti=
fy"><br><br></span><span style=3D"color:#008" class=3D"m_-18937093858127259=
85styled-by-prettify">int</span><span style=3D"color:#660" class=3D"m_-1893=
709385812725985styled-by-prettify">*:=3D</span><span style=3D"color:#000" c=
lass=3D"m_-1893709385812725985styled-by-prettify"> a </span><span style=3D"=
color:#660" class=3D"m_-1893709385812725985styled-by-prettify">=3D</span><s=
pan style=3D"color:#000" class=3D"m_-1893709385812725985styled-by-prettify"=
> </span><span style=3D"color:#008" class=3D"m_-1893709385812725985styled-b=
y-prettify">nullptr</span><span style=3D"color:#660" class=3D"m_-1893709385=
812725985styled-by-prettify">,</span><span style=3D"color:#000" class=3D"m_=
-1893709385812725985styled-by-prettify"> b </span><span style=3D"color:#660=
" class=3D"m_-1893709385812725985styled-by-prettify">=3D</span><span style=
=3D"color:#000" class=3D"m_-1893709385812725985styled-by-prettify"> </span>=
<span style=3D"color:#660" class=3D"m_-1893709385812725985styled-by-prettif=
y">&amp;</span><span style=3D"color:#000" class=3D"m_-1893709385812725985st=
yled-by-prettify">a</span><span style=3D"color:#660" class=3D"m_-1893709385=
812725985styled-by-prettify">;</span><span style=3D"color:#000" class=3D"m_=
-1893709385812725985styled-by-prettify"><br><br></span><span style=3D"color=
:#800" class=3D"m_-1893709385812725985styled-by-prettify">// the following =
won&#39;t compile:</span><span style=3D"color:#000" class=3D"m_-18937093858=
12725985styled-by-prettify"><br></span><span style=3D"color:#008" class=3D"=
m_-1893709385812725985styled-by-prettify">int</span><span style=3D"color:#6=
60" class=3D"m_-1893709385812725985styled-by-prettify">*:=3D</span><span st=
yle=3D"color:#000" class=3D"m_-1893709385812725985styled-by-prettify"> </sp=
an><span style=3D"color:#660" class=3D"m_-1893709385812725985styled-by-pret=
tify">*</span><span style=3D"color:#000" class=3D"m_-1893709385812725985sty=
led-by-prettify">a</span><span style=3D"color:#660" class=3D"m_-18937093858=
12725985styled-by-prettify">,</span><span style=3D"color:#000" class=3D"m_-=
1893709385812725985styled-by-prettify"> b</span><span style=3D"color:#660" =
class=3D"m_-1893709385812725985styled-by-prettify">;</span></div></code></d=
iv><br></div><div>To avoid the type syntax confusion I also propose to depr=
ecate old style variable declaration syntax as we can write tools to mechan=
ically transform the code bases to this new syntax.</div><div><br></div><di=
v><br></div><div>I get this syntax from a previous thread:=C2=A0<br></div><=
div><br></div>A more consistent variable declaration syntax by Andy Prowl <=
div><a href=3D"https://groups.google.com/a/isocpp.org/forum/#!searchin/std-=
proposals/variable$20declaration/std-proposals/ITDME5hYiPw/l4HFz3jjik4J" ta=
rget=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/forum/#!searchi=
n/<wbr>std-proposals/variable$<wbr>20declaration/std-proposals/<wbr>ITDME5h=
YiPw/l4HFz3jjik4J</a><br></div><div><br></div><div><br></div><div><br></div=
><div>Peter</div></div><span class=3D"HOEnZb"><font color=3D"#888888">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/62e66de4-7c7a-4e1c-8343-b173b49cb594%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/62e6=
6de4-7c7a-4e1c-<wbr>8343-b173b49cb594%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2B6mTDfKsuP60LCGfgY9B5WfoQhFRXyy_m=
6TgacGqPngcHtY4g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2B6mTDfKsuP6=
0LCGfgY9B5WfoQhFRXyy_m6TgacGqPngcHtY4g%40mail.gmail.com</a>.<br />

--001a11409312d4e383054c4460a0--

.

------=_Part_1243_663084136.1491231698698
Content-Type: multipart/alternative;
 boundary="----=_Part_1244_1331494453.1491231698698"

------=_Part_1244_1331494453.1491231698698
Content-Type: text/plain; charset=UTF-8



On Monday, April 3, 2017 at 4:50:24 PM UTC+2, Ville Voutilainen wrote:
>
> On 3 April 2017 at 17:45,  <hun.nem...@gmail.com <javascript:>> wrote:
> > Hi,
> >
> >
> > I took part in so many syntax debates over the years on preferred
> variable
> > declaration syntax.
> >
> > One of the neuralgic point of variable declaration syntax is the pointer
> and
> > reference alignment style.
> >
> > The root problem is the following:
> >
> > int* a, b;
> >
> > This declares a pointer and an int which is confusing. So a common
> coding
> > style to avoid this error is aligning pointer to variables:
> >
> > int *a, b;
> >
> > Which is also confusing sometimes as some type parts are separated from
> the
> > "main" type.
>
> If either of those is confusing, then separate the declarations with a
> semicolon and if you prefer, with a linefeed.
>

The real problem is the "int *a" vs. "int* a" style mixing in the code
bases. With this proposal we can get rid of the "int *a" style coding as it
will pointless.
Hard to pick one style now as "writing every declaration to a new line"
rule sometimes results in very unreadable code.

Peter


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

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

<div dir=3D"ltr"><br><br>On Monday, April 3, 2017 at 4:50:24 PM UTC+2, Vill=
e Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 3 April=
 2017 at 17:45, =C2=A0&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"M60ZW7OUCQAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">hun.nem...@gmail.com</a>&gt; wrote:
<br>&gt; Hi,
<br>&gt;
<br>&gt;
<br>&gt; I took part in so many syntax debates over the years on preferred =
variable
<br>&gt; declaration syntax.
<br>&gt;
<br>&gt; One of the neuralgic point of variable declaration syntax is the p=
ointer and
<br>&gt; reference alignment style.
<br>&gt;
<br>&gt; The root problem is the following:
<br>&gt;
<br>&gt; int* a, b;
<br>&gt;
<br>&gt; This declares a pointer and an int which is confusing. So a common=
 coding
<br>&gt; style to avoid this error is aligning pointer to variables:
<br>&gt;
<br>&gt; int *a, b;
<br>&gt;
<br>&gt; Which is also confusing sometimes as some type parts are separated=
 from the
<br>&gt; &quot;main&quot; type.
<br>
<br>If either of those is confusing, then separate the declarations with a
<br>semicolon and if you prefer, with a linefeed.
<br></blockquote><div><br></div><div>The real problem is the &quot;int *a&q=
uot; vs. &quot;int* a&quot; style mixing in the code bases. With this propo=
sal we can get rid of the &quot;int *a&quot; style coding as it will pointl=
ess.</div><div>Hard to pick one style now as &quot;writing every declaratio=
n to a new line&quot; rule sometimes results in very unreadable code.</div>=
<div><br></div><div>Peter</div><div>=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d2823c58-f983-49fc-963a-c7d00064e5dd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d2823c58-f983-49fc-963a-c7d00064e5dd=
%40isocpp.org</a>.<br />

------=_Part_1244_1331494453.1491231698698--

------=_Part_1243_663084136.1491231698698--

.

On 3 April 2017 at 18:01,  <hun.nemethpeter@gmail.com> wrote:
> The real problem is the "int *a" vs. "int* a" style mixing in the code
> bases. With this proposal we can get rid of the "int *a" style coding as it
> will pointless.


No we can't, since none of the large codebases using "int *a" would be
able to move for many years,
would probably not move even after many years, and we would spend
pointless energy implementing
this change in every C++ parser when we have much better things 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbZoaYFvcRT2joafBNGchz9mR%3DsX2n%2BZUdHW5QD5%3D%3DBXg%40mail.gmail.com.

.

------=_Part_1272_1955067346.1491232824649
Content-Type: multipart/alternative;
 boundary="----=_Part_1273_732342754.1491232824649"

------=_Part_1273_732342754.1491232824649
Content-Type: text/plain; charset=UTF-8

This is technically correct but in practice require a lot of typing as you
have to force the std::add_lvalue_reference and others also.

Peter

On Monday, April 3, 2017 at 4:57:31 PM UTC+2, Maxim Yanchenko wrote:
>
> Hi Peter,
>
> The problem can be solved with simple
>
>   #include <functional>
>   std::add_pointer_t<int> a,b;
>
> Now both a and b are pointers.
>
> Cheers,
> Maxim
>
> On Mon, Apr 3, 2017 at 10:45 PM, <hun.nem...@gmail.com <javascript:>>
> wrote:
>
>> Hi,
>>
>>
>> I took part in so many syntax debates over the years on preferred
>> variable declaration syntax.
>>
>> One of the neuralgic point of variable declaration syntax is the pointer
>> and reference alignment style.
>>
>> The root problem is the following:
>>
>> int* a, b;
>>
>> This declares a pointer and an int which is confusing. So a common coding
>> style to avoid this error is aligning pointer to variables:
>>
>> int *a, b;
>>
>> Which is also confusing sometimes as some type parts are separated from
>> the "main" type.
>>
>> What I suggest is a new variable declaration syntax:
>>
>> // <type>:= <identifier1>, <identifier2>, ...;
>> // so I can write
>>
>> int*:= a, b;
>>
>> // or
>>
>> int*:= a = nullptr, b = &a;
>>
>> // the following won't compile:
>> int*:= *a, b;
>>
>> To avoid the type syntax confusion I also propose to deprecate old style
>> variable declaration syntax as we can write tools to mechanically transform
>> the code bases to this new syntax.
>>
>>
>> I get this syntax from a previous thread:
>>
>> A more consistent variable declaration syntax by Andy Prowl
>>
>> https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/variable$20declaration/std-proposals/ITDME5hYiPw/l4HFz3jjik4J
>>
>>
>>
>> Peter
>>
>> --
>> 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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/62e66de4-7c7a-4e1c-8343-b173b49cb594%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/62e66de4-7c7a-4e1c-8343-b173b49cb594%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>
>

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

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

<div dir=3D"ltr">This is technically correct but in practice require a lot =
of typing as you have to force the std::add_lvalue_reference and others als=
o.<div><br></div><div>Peter<br><br>On Monday, April 3, 2017 at 4:57:31 PM U=
TC+2, Maxim Yanchenko wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><div><div><div><div>Hi Peter,<br><br></div>The problem can b=
e solved with simple<br><br><span style=3D"font-family:monospace,monospace"=
>=C2=A0 #include &lt;functional&gt;<br>=C2=A0 std::add_pointer_t&lt;int&gt;=
 a,b;</span><br></div><br>Now both a and b are pointers.<br><br></div>Cheer=
s,<br></div>Maxim<br></div><div><br><div class=3D"gmail_quote">On Mon, Apr =
3, 2017 at 10:45 PM,  <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"fH1OvBaVCQAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hre=
f=3D&#39;javascript:&#39;;return true;">hun.nem...@gmail.com</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi,<div><br></di=
v><div><br></div><div>I took part in so many syntax debates over the years =
on preferred variable declaration syntax.</div><div><br></div><div>One of t=
he neuralgic point of variable declaration syntax is the pointer and refere=
nce alignment style.</div><div><br></div><div>The root problem is the follo=
wing:<br></div><div><br></div><div><div style=3D"background-color:rgb(250,2=
50,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px;w=
ord-wrap:break-word"><code><div><span style=3D"color:#008">int</span><span =
style=3D"color:#660">*</span><span style=3D"color:#000"> a</span><span styl=
e=3D"color:#660">,</span><span style=3D"color:#000"> b</span><span style=3D=
"color:#660">;</span></div></code></div><br></div><div>This declares a poin=
ter and an int which is confusing. So a common coding style to avoid this e=
rror is aligning pointer to variables:</div><div><br></div><div><div 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><div><span style=
=3D"color:#008">int</span><span style=3D"color:#000"> </span><span style=3D=
"color:#660">*</span><span style=3D"color:#000">a</span><span style=3D"colo=
r:#660">,</span><span style=3D"color:#000"> b</span><span style=3D"color:#6=
60">;</span></div></code></div><br></div><div>Which is also confusing somet=
imes as some type parts are separated from the &quot;main&quot; type.</div>=
<div><br></div><div>What I suggest is a new variable declaration syntax:</d=
iv><div><br></div><div><div style=3D"background-color:rgb(250,250,250);bord=
er-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:bre=
ak-word"><code><div><span style=3D"color:#800">// &lt;type&gt;:=3D &lt;iden=
tifier1&gt;, &lt;identifier2&gt;, ...;</span><span style=3D"color:#000"><br=
></span><span style=3D"color:#800">// so I can write</span><span style=3D"c=
olor:#000"><br><br></span><span style=3D"color:#008">int</span><span style=
=3D"color:#660">*:=3D</span><span style=3D"color:#000"> a</span><span style=
=3D"color:#660">,</span><span style=3D"color:#000"> b</span><span style=3D"=
color:#660">;</span><span style=3D"color:#000"><br><br></span><span style=
=3D"color:#800">// or</span><span style=3D"color:#000"><br><br></span><span=
 style=3D"color:#008">int</span><span style=3D"color:#660">*:=3D</span><spa=
n style=3D"color:#000"> a </span><span style=3D"color:#660">=3D</span><span=
 style=3D"color:#000"> </span><span style=3D"color:#008">nullptr</span><spa=
n style=3D"color:#660">,</span><span style=3D"color:#000"> b </span><span s=
tyle=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#660">&amp;</span><span style=3D"color:#000">a</span><span style=
=3D"color:#660">;</span><span style=3D"color:#000"><br><br></span><span sty=
le=3D"color:#800">// the following won&#39;t compile:</span><span style=3D"=
color:#000"><br></span><span style=3D"color:#008">int</span><span style=3D"=
color:#660">*:=3D</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#660">*</span><span style=3D"color:#000">a</span><span style=3D"color:=
#660">,</span><span style=3D"color:#000"> b</span><span style=3D"color:#660=
">;</span></div></code></div><br></div><div>To avoid the type syntax confus=
ion I also propose to deprecate old style variable declaration syntax as we=
 can write tools to mechanically transform the code bases to this new synta=
x.</div><div><br></div><div><br></div><div>I get this syntax from a previou=
s thread:=C2=A0<br></div><div><br></div>A more consistent variable declarat=
ion syntax by Andy Prowl <div><a href=3D"https://groups.google.com/a/isocpp=
..org/forum/#!searchin/std-proposals/variable$20declaration/std-proposals/IT=
DME5hYiPw/l4HFz3jjik4J" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"t=
his.href=3D&#39;https://groups.google.com/a/isocpp.org/forum/#!searchin/std=
-proposals/variable$20declaration/std-proposals/ITDME5hYiPw/l4HFz3jjik4J&#3=
9;;return true;" onclick=3D"this.href=3D&#39;https://groups.google.com/a/is=
ocpp.org/forum/#!searchin/std-proposals/variable$20declaration/std-proposal=
s/ITDME5hYiPw/l4HFz3jjik4J&#39;;return true;">https://groups.google.com/a/<=
wbr>isocpp.org/forum/#!searchin/<wbr>std-proposals/variable$<wbr>20declarat=
ion/std-proposals/<wbr>ITDME5hYiPw/l4HFz3jjik4J</a><br></div><div><br></div=
><div><br></div><div><br></div><div>Peter</div></div><span><font color=3D"#=
888888">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
fH1OvBaVCQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"fH1OvBaVCQAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/62e66de4-7c7a-4e1c-8343-b173b49cb594%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/62e66de4-7c7a-4e1c-8343-b173b49cb594%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/62e66de4-7c7a-4e1c-8343-b173b49cb594%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/62e66de4-7c7a-4e1c-<wbr>8343-=
b173b49cb594%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br></div>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a0689bc8-4ccd-415a-a1fe-0cb4745e3471%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a0689bc8-4ccd-415a-a1fe-0cb4745e3471=
%40isocpp.org</a>.<br />

------=_Part_1273_732342754.1491232824649--

------=_Part_1272_1955067346.1491232824649--

.

------=_Part_650_52040739.1491233248510
Content-Type: multipart/alternative;
 boundary="----=_Part_651_1835758225.1491233248511"

------=_Part_651_1835758225.1491233248511
Content-Type: text/plain; charset=UTF-8

Deprecating a syntax doesn't mean they can't use their code base at all.
Nowadays we have tool like clang refactoring tool. With the help of a tool
you can mechanically transform your code base.
Implementing this new syntax in compilers isn't really a huge task.

Peter

On Monday, April 3, 2017 at 5:12:13 PM UTC+2, Ville Voutilainen wrote:
>
> On 3 April 2017 at 18:01,  <hun.nem...@gmail.com <javascript:>> wrote:
> > The real problem is the "int *a" vs. "int* a" style mixing in the code
> > bases. With this proposal we can get rid of the "int *a" style coding as
> it
> > will pointless.
>
>
> No we can't, since none of the large codebases using "int *a" would be
> able to move for many years,
> would probably not move even after many years, and we would spend
> pointless energy implementing
> this change in every C++ parser when we have much better things 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c61fc6d5-ceca-454c-9fe1-97091fca4b26%40isocpp.org.

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

<div dir=3D"ltr">Deprecating a syntax doesn&#39;t mean they can&#39;t use t=
heir code base at all. Nowadays we have tool like clang refactoring tool. W=
ith the help of a tool you can mechanically transform your code base.<div><=
div>Implementing this new syntax in compilers isn&#39;t really a huge task.=
</div><div><div><br></div><div>Peter<br><br>On Monday, April 3, 2017 at 5:1=
2:13 PM UTC+2, Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;">On 3 April 2017 at 18:01, =C2=A0&lt;<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"yF3E_eOVCQAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hre=
f=3D&#39;javascript:&#39;;return true;">hun.nem...@gmail.com</a>&gt; wrote:
<br>&gt; The real problem is the &quot;int *a&quot; vs. &quot;int* a&quot; =
style mixing in the code
<br>&gt; bases. With this proposal we can get rid of the &quot;int *a&quot;=
 style coding as it
<br>&gt; will pointless.
<br>
<br>
<br>No we can&#39;t, since none of the large codebases using &quot;int *a&q=
uot; would be
<br>able to move for many years,
<br>would probably not move even after many years, and we would spend
<br>pointless energy implementing
<br>this change in every C++ parser when we have much better things to do.
<br></blockquote></div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c61fc6d5-ceca-454c-9fe1-97091fca4b26%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c61fc6d5-ceca-454c-9fe1-97091fca4b26=
%40isocpp.org</a>.<br />

------=_Part_651_1835758225.1491233248511--

------=_Part_650_52040739.1491233248510--

.

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

Have you ever fought an endless battle for a tiny little change at any big
corporation that writes C++? It doesn't seem you have.

On Mon, Apr 3, 2017 at 5:27 PM <hun.nemethpeter@gmail.com> wrote:

> Deprecating a syntax doesn't mean they can't use their code base at all.
> Nowadays we have tool like clang refactoring tool. With the help of a tool
> you can mechanically transform your code base.
> Implementing this new syntax in compilers isn't really a huge task.
>
> Peter
>
> On Monday, April 3, 2017 at 5:12:13 PM UTC+2, Ville Voutilainen wrote:
>
> On 3 April 2017 at 18:01,  <hun.nem...@gmail.com> wrote:
> > The real problem is the "int *a" vs. "int* a" style mixing in the code
> > bases. With this proposal we can get rid of the "int *a" style coding as
> it
> > will pointless.
>
>
> No we can't, since none of the large codebases using "int *a" would be
> able to move for many years,
> would probably not move even after many years, and we would spend
> pointless energy implementing
> this change in every C++ parser when we have much better things 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c61fc6d5-ceca-454c-9fe1-97091fca4b26%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c61fc6d5-ceca-454c-9fe1-97091fca4b26%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

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

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

<div dir=3D"ltr">Have you ever fought an endless battle for a tiny little c=
hange at any big corporation that writes C++? It doesn&#39;t seem you have.=
</div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Apr 3, 2017 a=
t 5:27 PM &lt;<a href=3D"mailto:hun.nemethpeter@gmail.com">hun.nemethpeter@=
gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr" class=3D"gmail_msg">Deprecating a syntax doesn&#39;t mean they can=
&#39;t use their code base at all. Nowadays we have tool like clang refacto=
ring tool. With the help of a tool you can mechanically transform your code=
 base.<div class=3D"gmail_msg"><div class=3D"gmail_msg">Implementing this n=
ew syntax in compilers isn&#39;t really a huge task.</div><div class=3D"gma=
il_msg"><div class=3D"gmail_msg"><br class=3D"gmail_msg"></div><div class=
=3D"gmail_msg">Peter<br class=3D"gmail_msg"><br class=3D"gmail_msg">On Mond=
ay, April 3, 2017 at 5:12:13 PM UTC+2, Ville Voutilainen wrote:</div></div>=
</div></div><div dir=3D"ltr" class=3D"gmail_msg"><div class=3D"gmail_msg"><=
div class=3D"gmail_msg"><div class=3D"gmail_msg"><blockquote class=3D"gmail=
_quote gmail_msg" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex">On 3 April 2017 at 18:01, =C2=A0&lt;<a rel=3D"nofol=
low" class=3D"gmail_msg">hun.nem...@gmail.com</a>&gt; wrote:
<br class=3D"gmail_msg">&gt; The real problem is the &quot;int *a&quot; vs.=
 &quot;int* a&quot; style mixing in the code
<br class=3D"gmail_msg">&gt; bases. With this proposal we can get rid of th=
e &quot;int *a&quot; style coding as it
<br class=3D"gmail_msg">&gt; will pointless.
<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
<br class=3D"gmail_msg">No we can&#39;t, since none of the large codebases =
using &quot;int *a&quot; would be
<br class=3D"gmail_msg">able to move for many years,
<br class=3D"gmail_msg">would probably not move even after many years, and =
we would spend
<br class=3D"gmail_msg">pointless energy implementing
<br class=3D"gmail_msg">this change in every C++ parser when we have much b=
etter things to do.
<br class=3D"gmail_msg"></blockquote></div></div></div></div>

<p class=3D"gmail_msg"></p>

-- <br class=3D"gmail_msg">
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br class=3D"gmail_msg=
">
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" class=3D"gm=
ail_msg" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br cla=
ss=3D"gmail_msg">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"gmail_msg" target=3D"_blank">std-proposals@isocpp.org</a>.<b=
r class=3D"gmail_msg">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c61fc6d5-ceca-454c-9fe1-97091fca4b26%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" class=3D"gmail_msg=
" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-prop=
osals/c61fc6d5-ceca-454c-9fe1-97091fca4b26%40isocpp.org</a>.<br class=3D"gm=
ail_msg">
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdQ0kdM%2BELFFXe9ec9Thp8ous36iqm=
dF8ANFHB5cPk4NmQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdQ0kdM%2B=
ELFFXe9ec9Thp8ous36iqmdF8ANFHB5cPk4NmQ%40mail.gmail.com</a>.<br />

--94eb2c1cc4e69756ec054c44d3d8--

.

On 3 April 2017 at 18:27,  <hun.nemethpeter@gmail.com> wrote:
> Nowadays we have tool like clang refactoring tool. With the help of a tool
> you can mechanically transform your code base.

No I can't, since my code must work on older compilers, and I have no
time to spend on pointless
changes that add nothing to the code.

> Implementing this new syntax in compilers isn't really a huge task.


I'm sure you've done it for gcc, clang and msvc already, not to
mention every non-compiler tool
that parses C++. Where are your patches? Never mind, don't tell me, I
don't want them.

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

.

------=_Part_633_1907206772.1491234061237
Content-Type: multipart/alternative;
 boundary="----=_Part_634_1533745401.1491234061237"

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

I am working in a big company as a C++ expert. Starting a new project or=20
merging two project to one also quite stressful. But the real problem is=20
there is no good solution to this simple task now. Variable declaration is=
=20
quite weak now. You can select the "int* a" style but you can't declare=20
more then one variable in one line. Or you can use "int *a;" style which is=
=20
just simple confusing as you separated the type.=20

Peter

On Monday, April 3, 2017 at 5:29:37 PM UTC+2, Micha=C5=82 Dominiak wrote:
>
> Have you ever fought an endless battle for a tiny little change at any bi=
g=20
> corporation that writes C++? It doesn't seem you have.
>
>>
>>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/71d11c91-44c1-4662-a995-10735dbb735d%40isocpp.or=
g.

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

<div dir=3D"ltr">I am working in a big company as a C++ expert. Starting a =
new project or merging two project to one also quite stressful. But the rea=
l problem is there is no good solution to this simple task now. Variable de=
claration is quite weak now. You can select the &quot;int* a&quot; style bu=
t you can&#39;t declare more then one variable in one line. Or you can use =
&quot;int *a;&quot; style which is just simple confusing as you separated t=
he type.=C2=A0<div><br></div><div>Peter<br><br>On Monday, April 3, 2017 at =
5:29:37 PM UTC+2, Micha=C5=82 Dominiak wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr">Have you ever fought an endless battle for =
a tiny little change at any big corporation that writes C++? It doesn&#39;t=
 seem you have.</div><div class=3D"gmail_quote"><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><br>
</blockquote></div>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/71d11c91-44c1-4662-a995-10735dbb735d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/71d11c91-44c1-4662-a995-10735dbb735d=
%40isocpp.org</a>.<br />

------=_Part_634_1533745401.1491234061237--

------=_Part_633_1907206772.1491234061237--

.

------=_Part_1436_1919123055.1491234422578
Content-Type: multipart/alternative;
 boundary="----=_Part_1437_749992391.1491234422579"

------=_Part_1437_749992391.1491234422579
Content-Type: text/plain; charset=UTF-8



On Monday, April 3, 2017 at 5:37:04 PM UTC+2, Ville Voutilainen wrote:
>
> On 3 April 2017 at 18:27,  <hun.nem...@gmail.com <javascript:>> wrote:
> > Nowadays we have tool like clang refactoring tool. With the help of a
> tool
> > you can mechanically transform your code base.
>
> No I can't, since my code must work on older compilers, and I have no
> time to spend on pointless
> changes that add nothing to the code.
>
Adding new features will break compatibility. If you declare your code
needs the -std=c++20 flag then this kind of issue will happen.


>
> > Implementing this new syntax in compilers isn't really a huge task.
>
>
> I'm sure you've done it for gcc, clang and msvc already, not to
> mention every non-compiler tool
> that parses C++. Where are your patches? Never mind, don't tell me, I
> don't want them.
>
I wrote some compiler extension in clang. So I think it won't really be a
huge change in the parse. And I don't think that my task is to patch every
compiler.


Peter

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

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

<div dir=3D"ltr"><br><br>On Monday, April 3, 2017 at 5:37:04 PM UTC+2, Vill=
e Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 3 April=
 2017 at 18:27, =C2=A0&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"1as0Nj-XCQAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">hun.nem...@gmail.com</a>&gt; wrote:
<br>&gt; Nowadays we have tool like clang refactoring tool. With the help o=
f a tool
<br>&gt; you can mechanically transform your code base.
<br>
<br>No I can&#39;t, since my code must work on older compilers, and I have =
no
<br>time to spend on pointless
<br>changes that add nothing to the code.
<br></blockquote><div>Adding new features will break compatibility. If you =
declare your code needs the -std=3Dc++20 flag then this kind of issue will =
happen.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; Implementing this new syntax in compilers isn&#39;t really a huge =
task.
<br>
<br>
<br>I&#39;m sure you&#39;ve done it for gcc, clang and msvc already, not to
<br>mention every non-compiler tool
<br>that parses C++. Where are your patches? Never mind, don&#39;t tell me,=
 I
<br>don&#39;t want them.
<br></blockquote><div>I wrote some compiler extension in clang. So I think =
it won&#39;t really be a huge change in the parse. And I don&#39;t think th=
at my task is to patch every compiler.</div><div><br></div><div><br></div><=
div>Peter</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/59cae011-1553-417a-940a-a15e45e14b92%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/59cae011-1553-417a-940a-a15e45e14b92=
%40isocpp.org</a>.<br />

------=_Part_1437_749992391.1491234422579--

------=_Part_1436_1919123055.1491234422578--

.

On 3 April 2017 at 18:47,  <hun.nemethpeter@gmail.com> wrote:
> I wrote some compiler extension in clang. So I think it won't really be a
> huge change in the parse. And I don't think that my task is to patch every
> compiler.


It's also not my task to entertain every proposal that people come up with.

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

.

On segunda-feira, 3 de abril de 2017 08:47:02 PDT hun.nemethpeter@gmail.com
wrote:
> Adding new features will break compatibility.

No, it doesn't.

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

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

.

<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
 255, 255); line-height: initial;">                                        =
                                              <div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">1. Use</div><div style=3D"width: 100%; font-size: initial; font=
-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 1=
25); text-align: initial; background-color: rgb(255, 255, 255);"><br></div>=
<div style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate=
 Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial=
; background-color: rgb(255, 255, 255);">int * a;</div><div style=3D"width:=
 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, s=
ans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: =
rgb(255, 255, 255);"><br></div><div style=3D"width: 100%; font-size: initia=
l; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31=
, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">The=
 * is important - make it clearly visible. =E2=80=8EAs a bonus, both other =
'religions' seem to accept/tolerate it.&nbsp;</div><div style=3D"width: 100=
%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-=
serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(=
255, 255, 255);"><br></div><div style=3D"width: 100%; font-size: initial; f=
ont-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73=
, 125); text-align: initial; background-color: rgb(255, 255, 255);">2. Give=
 up on coding styles (within reason). I know this is heretical, but I've in=
stead just learned to be comfortable in various styles. </div><div style=3D=
"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-s=
erif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-=
color: rgb(255, 255, 255);"><br></div><div style=3D"width: 100%; font-size:=
 initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color:=
 rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255=
);">3. If you want this change, change it in C first. We don't need to be 1=
00% compatible, but we don't want needless incompatibility either. </div><d=
iv style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate P=
ro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; =
background-color: rgb(255, 255, 255);"><br></div><div style=3D"width: 100%;=
 font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-se=
rif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(25=
5, 255, 255);">4. Don't bother. It is not worth committee time. I'd rather =
have concepts, modules, coroutines, ranges, networking, ...</div><div style=
=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', san=
s-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backgrou=
nd-color: rgb(255, 255, 255);"><br></div><div style=3D"width: 100%; font-si=
ze: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; col=
or: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, =
255);"><br></div>                                                          =
                                                                           =
<div style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate=
 Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial=
; background-color: rgb(255, 255, 255);"><br style=3D"display:initial"></di=
v>                                                                         =
                                                                           =
                                               <div style=3D"font-size: ini=
tial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb=
(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">=
Sent&nbsp;from&nbsp;my&nbsp;BlackBerry&nbsp;portable&nbsp;Babbage&nbsp;Devi=
ce</div>                                                                   =
                                                                           =
                                    <table width=3D"100%" style=3D"backgrou=
nd-color:white;border-spacing:0px;"> <tbody><tr><td colspan=3D"2" style=3D"=
font-size: initial; text-align: initial; background-color: rgb(255, 255, 25=
5);">                           <div style=3D"border-style: solid none none=
; border-top-color: rgb(181, 196, 223); border-top-width: 1pt; padding: 3pt=
 0in 0in; font-family: Tahoma, 'BB Alpha Sans', 'Slate Pro'; font-size: 10p=
t;">  <div><b>From: </b>hun.nemethpeter@gmail.com</div><div><b>Sent: </b>Mo=
nday, April 3, 2017 11:41 AM</div><div><b>To: </b>ISO C++ Standard - Future=
 Proposals</div><div><b>Reply To: </b>std-proposals@isocpp.org</div><div><b=
>Subject: </b>Re: [std-proposals] Improved variable declaration syntax</div=
></div></td></tr></tbody></table><div style=3D"border-style: solid none non=
e; border-top-color: rgb(186, 188, 209); border-top-width: 1pt; font-size: =
initial; text-align: initial; background-color: rgb(255, 255, 255);"></div>=
<br><div id=3D"_originalContent" style=3D""><div dir=3D"ltr">I am working i=
n a big company as a C++ expert. Starting a new project or merging two proj=
ect to one also quite stressful. But the real problem is there is no good s=
olution to this simple task now. Variable declaration is quite weak now. Yo=
u can select the "int* a" style but you can't declare more then one variabl=
e in one line. Or you can use "int *a;" style which is just simple confusin=
g as you separated the type.&nbsp;<div><br></div><div>Peter<br><br>On Monda=
y, April 3, 2017 at 5:29:37 PM UTC+2, Micha=C5=82 Dominiak wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Have you ever fought an=
 endless battle for a tiny little change at any big corporation that writes=
 C++? It doesn't seem you have.</div><div class=3D"gmail_quote"><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><br>
</blockquote></div>
</blockquote></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/71d11c91-44c1-4662-a995-10735dbb735d%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/71d11c91-44c1-4662-a995-10735dbb=
735d%40isocpp.org</a>.<br>
<br><!--end of _originalContent --></div></body></html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/20170403160800.5132370.87957.28462%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/20170403160800.5132370.87957.28462%40gm=
ail.com</a>.<br />

.

------=_Part_1324_854066133.1491240729458
Content-Type: multipart/alternative;
 boundary="----=_Part_1325_1532840073.1491240729458"

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



On Monday, April 3, 2017 at 6:08:05 PM UTC+2, Tony V E wrote:
>
> 1. Use
>
> int * a;
>
> The * is important - make it clearly visible. =E2=80=8EAs a bonus, both o=
ther=20
> 'religions' seem to accept/tolerate it.=20
>
But this is not a solution, as I can't write:

int * a, b;

First, this looks like a multiply, second this will not do what I want here=
..

Writing

int* :=3D a, b;


is what I can't write now.
=20

>
> 2. Give up on coding styles (within reason). I know this is heretical, bu=
t=20
> I've instead just learned to be comfortable in various styles.
>
I know but I was in a situation where team A and team B wrote code in=20
different coding style. Later the two team was merged and you know... Ok.=
=20
we can pick one style but now there is no good choice here.


Peter

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/18cc499f-7442-4e8f-b9cf-31e254c331cf%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Monday, April 3, 2017 at 6:08:05 PM UTC+2, Tony=
 V E wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div lang=3D"en-US"=
 style=3D"background-color:rgb(255,255,255);line-height:initial">          =
                                                                           =
 <div style=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slate =
Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;back=
ground-color:rgb(255,255,255)">1. Use</div><div style=3D"width:100%;font-si=
ze:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;co=
lor:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)"><b=
r></div><div style=3D"width:100%;font-size:initial;font-family:Calibri,&#39=
;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initi=
al;background-color:rgb(255,255,255)">int * a;</div><div style=3D"width:100=
%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans=
-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255=
,255)"><br></div><div style=3D"width:100%;font-size:initial;font-family:Cal=
ibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-al=
ign:initial;background-color:rgb(255,255,255)">The * is important - make it=
 clearly visible. =E2=80=8EAs a bonus, both other &#39;religions&#39; seem =
to accept/tolerate it.=C2=A0</div></div></blockquote><div>But this is not a=
 solution, as I can&#39;t write:</div><div><br></div><div><div class=3D"pre=
ttyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(=
187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-wo=
rd;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> a</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> b</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;=
</span></div></code></div><br></div><div>First, this looks like a multiply,=
 second this will not do what I want here.<br></div><div><br></div><div>Wri=
ting</div><div><br></div><div><div class=3D"prettyprint" style=3D"backgroun=
d-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style=
: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettypr=
int"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">int</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">:=3D</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> a</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> b</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">;</span></div></code></div><br></div=
><div><br></div><div>is what I can&#39;t write now.</div><div>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div lang=3D"en-US" style=3D"ba=
ckground-color:rgb(255,255,255);line-height:initial"><div style=3D"width:10=
0%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,san=
s-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,25=
5,255)"><br></div><div style=3D"width:100%;font-size:initial;font-family:Ca=
libri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-a=
lign:initial;background-color:rgb(255,255,255)">2. Give up on coding styles=
 (within reason). I know this is heretical, but I&#39;ve instead just learn=
ed to be comfortable in various styles.</div></div></blockquote><div>I know=
 but I was in a situation where team A and team B wrote code in different c=
oding style. Later the two team was merged and you know... Ok. we can pick =
one style but now there is no good choice here.</div><div><br></div><div><b=
r></div><div>Peter</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/18cc499f-7442-4e8f-b9cf-31e254c331cf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/18cc499f-7442-4e8f-b9cf-31e254c331cf=
%40isocpp.org</a>.<br />

------=_Part_1325_1532840073.1491240729458--

------=_Part_1324_854066133.1491240729458--

.

On 2017-04-03 16:45, hun.nemethpeter@gmail.com wrote:
> Hi,
>
>
> I took part in so many syntax debates over the years on preferred
> variable declaration syntax.
>
> One of the neuralgic point of variable declaration syntax is the pointer
> and reference alignment style.
>
> The root problem is the following:
>
> |
> int*a,b;
> |
>
> This declares a pointer and an int which is confusing. So a common
> coding style to avoid this error is aligning pointer to variables:
>
> |
> int*a,b;
> |
>
> Which is also confusing sometimes as some type parts are separated from
> the "main" type.
>
> What I suggest is a new variable declaration syntax:
>
> |
> // <type>:= <identifier1>, <identifier2>, ...;
> // so I can write
>
> int*:=a,b;
>
> // or
>
> int*:=a =nullptr,b =&a;
>
> // the following won't compile:
> int*:=*a,b;
> |
>
> To avoid the type syntax confusion I also propose to deprecate old style
> variable declaration syntax as we can write tools to mechanically
> transform the code bases to this new syntax.
>

And without changing the language you can do:

int* a; int* b;

And not have any problems.




     Bo Persson



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

.

------=_Part_655_1279118503.1491241803006
Content-Type: multipart/alternative;
 boundary="----=_Part_656_932791736.1491241803006"

------=_Part_656_932791736.1491241803006
Content-Type: text/plain; charset=UTF-8


>
>
>
> And without changing the language you can do:
>
> int* a; int* b;
>
> And not have any problems.
>
>
In this case you have to copy paste the type part which is error prone.

Consider the following

long_namespace::big_special_matrix<SoBigNumber>* := x, y, z, a, b, c;


will be

long_namespace::big_special_matrix<SoBigNumber>* x; long_namespace::
big_special_matrix<SoBigNumber>* y; long_namespace::big_special_matrix<
SoBigNumber>* z; ...

Do you think that this is a good solution?


Peter


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

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>
<br>And without changing the language you can do:
<br>
<br>int* a; int* b;
<br>
<br>And not have any problems.
<br><br></blockquote><div><br></div><div>In this case you have to copy past=
e the type part which is error prone.</div><div><br></div><div>Consider the=
 following</div><div><br></div><div class=3D"prettyprint" style=3D"backgrou=
nd-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-styl=
e: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyp=
rint"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">long_namespace</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">big_special_matrix</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;</span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">SoBigNumber</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">&gt;*</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">:=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"> y</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> z</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> a</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> b</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> c</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></div></code></d=
iv><div><br><br></div><div>will be</div><div><br></div><div class=3D"pretty=
print" 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: #000;" class=3D"styled-by-prettify">long_namespace</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">big_special_matrix</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #606;" class=3D"styled-by-prettify">SoBigNumber</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">&gt;*</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"> long_namespace</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">big_special_matrix</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">&lt;</span><span style=3D"color: #606;" class=3D"s=
tyled-by-prettify">SoBigNumber</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">&gt;*</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> y</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> l=
ong_namespace</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">big_s=
pecial_matrix</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">&lt;</span><span style=3D"color: #606;" class=3D"styled-by-prettify">SoB=
igNumber</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&g=
t;*</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> z</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">...</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br></span></div></code></div><div><br>D=
o you think that this is a good solution?<br></div><div><br></div><div><br>=
</div><div>Peter</div><div><br></div><div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/48319a46-6060-4802-90d4-ba7d1e647655%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/48319a46-6060-4802-90d4-ba7d1e647655=
%40isocpp.org</a>.<br />

------=_Part_656_932791736.1491241803006--

------=_Part_655_1279118503.1491241803006--

.

On 2017-04-03 19:50, hun.nemethpeter@gmail.com wrote:
>
>
>     And without changing the language you can do:
>
>     int* a; int* b;
>
>     And not have any problems.
>
>
> In this case you have to copy paste the type part which is error prone.
>
> Consider the following
>
> |
> long_namespace::big_special_matrix<SoBigNumber>*:=x,y,z,a,b,c;
> |
>
>
> will be
>
> |
> long_namespace::big_special_matrix<SoBigNumber>*x;long_namespace::big_special_matrix<SoBigNumber>*y;long_namespace::big_special_matrix<SoBigNumber>*z;...
> |
>
> Do you think that this is a good solution?
>
>

Yes, you could do

using matrix = long_namespace::big_special_matrix<SoBigNumber>;

to make the declarations shorter.

matrix*   x;
matrix*   y;
matrix*   z;

will confuse no one.

     Bo Persson



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

.

------=_Part_1877_1611553384.1491242905455
Content-Type: multipart/alternative;
 boundary="----=_Part_1878_415915753.1491242905455"

------=_Part_1878_415915753.1491242905455
Content-Type: text/plain; charset=UTF-8


>
>
> Yes, you could do
>
> using matrix = long_namespace::big_special_matrix<SoBigNumber>;
>
> to make the declarations shorter.
>
> matrix*   x;
> matrix*   y;
> matrix*   z;
>
> will confuse no one.
>

In this case you have to force developers to to create an abbreviation for
every long typename during variable declaration.
And you have to declare what is long. And again you have to copy paste that
type again and again.

struct A {
    using matrix = long_namespace::big_special_matrix<SoBigNumber>;
    matrix*   x;
    matrix*   y;
    matrix*   z;
};

vs.

struct A {
    long_namespace::big_special_matrix<SoBigNumber>* := x, y, z;
 };



Peter

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

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>Yes, you =
could do
<br>
<br>using matrix =3D long_namespace::big_special_<wbr>matrix&lt;SoBigNumber=
&gt;;
<br>
<br>to make the declarations shorter.
<br>
<br>matrix* =C2=A0 x;
<br>matrix* =C2=A0 y;
<br>matrix* =C2=A0 z;
<br>
<br>will confuse no one.=C2=A0<br></blockquote><div><br></div><div>In this =
case you have to force developers to to create an abbreviation for every lo=
ng typename during variable declaration.</div><div>And you have to declare =
what is long. And again you have to copy paste that type again and again.</=
div><div><br></div><div class=3D"prettyprint" style=3D"background-color: rg=
b(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bo=
rder-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div c=
lass=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">struct</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> A </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">usi=
ng</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> matrix =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> long_namespace</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">big_special_matrix</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><=
span style=3D"color: #606;" class=3D"styled-by-prettify">SoBigNumber</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;;</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> <br>=C2=A0 =C2=A0 mat=
rix</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0 x</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> <br>=C2=A0 =C2=A0 matrix<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0 y</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> <br>=C2=A0 =C2=A0 matrix</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0 z</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><div><br>vs.<b=
r></div><div><br></div><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"><d=
iv class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by=
-prettify">struct</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> A </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 =C2=A0 long_namespace</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">big_special_matrix</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&lt;</span><span style=3D"color: #606;" class=3D"styled-by-p=
rettify">SoBigNumber</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">&gt;*</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">:=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 styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> y</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">,</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 style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> <br></span></div></code></div><div><br><br></div><div><br></div><di=
v>Peter</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/13ca3186-ff8c-4966-abff-5c8875e0541f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/13ca3186-ff8c-4966-abff-5c8875e0541f=
%40isocpp.org</a>.<br />

------=_Part_1878_415915753.1491242905455--

------=_Part_1877_1611553384.1491242905455--

.

------=_Part_3104_1127462804.1491242913859
Content-Type: multipart/alternative;
 boundary="----=_Part_3105_1441885493.1491242913859"

------=_Part_3105_1441885493.1491242913859
Content-Type: text/plain; charset=UTF-8



On Monday, April 3, 2017 at 1:50:03 PM UTC-4, hun.nem...@gmail.com wrote:
>
>
>>
>> And without changing the language you can do:
>>
>> int* a; int* b;
>>
>> And not have any problems.
>>
>>
> In this case you have to copy paste the type part which is error prone.
>
> Consider the following
>
> long_namespace::big_special_matrix<SoBigNumber>* := x, y, z, a, b, c;
>
>
> will be
>
> long_namespace::big_special_matrix<SoBigNumber>* x; long_namespace::
> big_special_matrix<SoBigNumber>* y; long_namespace::big_special_matrix<
> SoBigNumber>* z; ...
>
> Do you think that this is a good solution?
>

I don't believe that this comes up often enough for it to matter. I for one
have never had to declare variables like that.

You're asking for a change to the language. Language changes should offer
significant benefit. And thus far, the benefit just doesn't seem to come up
often enough to be worthy of such a change.

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

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

<div dir=3D"ltr"><br><br>On Monday, April 3, 2017 at 1:50:03 PM UTC-4, hun.=
nem...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>And without changing the language you can do:
<br>
<br>int* a; int* b;
<br>
<br>And not have any problems.
<br><br></blockquote><div><br></div><div>In this case you have to copy past=
e the type part which is error prone.</div><div><br></div><div>Consider the=
 following</div><div><br></div><div style=3D"background-color:rgb(250,250,2=
50);border-color:rgb(187,187,187);border-style:solid;border-width:1px;word-=
wrap:break-word"><code><div><span style=3D"color:#000">long_namespace</span=
><span style=3D"color:#660">::</span><span style=3D"color:#000">big_special=
_<wbr>matrix</span><span style=3D"color:#660">&lt;</span><span style=3D"col=
or:#606">SoBigNumber</span><span style=3D"color:#660">&gt;*</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#660">:=3D</span><span style=
=3D"color:#000"> x</span><span style=3D"color:#660">,</span><span style=3D"=
color:#000"> y</span><span style=3D"color:#660">,</span><span style=3D"colo=
r:#000"> z</span><span style=3D"color:#660">,</span><span style=3D"color:#0=
00"> a</span><span style=3D"color:#660">,</span><span style=3D"color:#000">=
 b</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> c</=
span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br></sp=
an></div></code></div><div><br><br></div><div>will be</div><div><br></div><=
div 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><div><spa=
n style=3D"color:#000">long_namespace</span><span style=3D"color:#660">::</=
span><span style=3D"color:#000">big_special_<wbr>matrix</span><span style=
=3D"color:#660">&lt;</span><span style=3D"color:#606">SoBigNumber</span><sp=
an style=3D"color:#660">&gt;*</span><span style=3D"color:#000"> x</span><sp=
an style=3D"color:#660">;</span><span style=3D"color:#000"> long_namespace<=
/span><span style=3D"color:#660">::</span><span style=3D"color:#000">big_sp=
ecial_<wbr>matrix</span><span style=3D"color:#660">&lt;</span><span style=
=3D"color:#606">SoBigNumber</span><span style=3D"color:#660">&gt;*</span><s=
pan style=3D"color:#000"> y</span><span style=3D"color:#660">;</span><span =
style=3D"color:#000"> long_namespace</span><span style=3D"color:#660">::</s=
pan><span style=3D"color:#000">big_special_<wbr>matrix</span><span style=3D=
"color:#660">&lt;</span><span style=3D"color:#606">SoBigNumber</span><span =
style=3D"color:#660">&gt;*</span><span style=3D"color:#000"> z</span><span =
style=3D"color:#660">;</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">...</span><span style=3D"color:#000"><br></span></div></cod=
e></div><div><br>Do you think that this is a good solution?</div></div></bl=
ockquote><div><br>I don&#39;t believe that this comes up often enough for i=
t to matter. I for one have never had to declare variables like that.<br><b=
r>You&#39;re asking for a change to the language. Language changes should o=
ffer significant benefit. And thus far, the benefit just doesn&#39;t seem t=
o come up often enough to be worthy of such a change.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/75eaccbd-6480-423d-b593-6f60d90d371c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/75eaccbd-6480-423d-b593-6f60d90d371c=
%40isocpp.org</a>.<br />

------=_Part_3105_1441885493.1491242913859--

------=_Part_3104_1127462804.1491242913859--

.

------=_Part_2001_1622546673.1491243392045
Content-Type: multipart/alternative;
 boundary="----=_Part_2002_1691152607.1491243392045"

------=_Part_2002_1691152607.1491243392045
Content-Type: text/plain; charset=UTF-8


>
>
> I don't believe that this comes up often enough for it to matter. I for
> one have never had to declare variables like that.
>
> You're asking for a change to the language. Language changes should offer
> significant benefit. And thus far, the benefit just doesn't seem to come up
> often enough to be worthy of such a change.
>

In a technical point this is not a problem at all but in practice it cause
headache. This is a proposal for syntax change that can be done
automatically.

The main benefit is that you can remove a very diverging coding style from
the language that simplify maintenance and teaching.

In real code bases the "int *a" and "int* a" style just competing every
single time. And you can't select a real winner now.


Peter

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

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><br>I don&#39;t believe that this comes up often enough for it to =
matter. I for one have never had to declare variables like that.<br><br>You=
&#39;re asking for a change to the language. Language changes should offer =
significant benefit. And thus far, the benefit just doesn&#39;t seem to com=
e up often enough to be worthy of such a change.<br></div></div></blockquot=
e><div><br></div><div>In a technical point this is not a problem at all but=
 in practice it cause headache. This is a proposal for syntax change that c=
an be done automatically.</div><div><br></div><div>The main benefit is that=
 you can remove a very diverging coding style from the language that simpli=
fy maintenance and teaching.</div><div><br></div><div>In real code bases th=
e &quot;int *a&quot; and &quot;int* a&quot; style just=C2=A0competing every=
 single time. And you can&#39;t select a real winner now.</div><div><br></d=
iv><div><br></div><div>Peter</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e7f3e7f9-c5cf-4963-8c9c-cbfd6224e6aa%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e7f3e7f9-c5cf-4963-8c9c-cbfd6224e6aa=
%40isocpp.org</a>.<br />

------=_Part_2002_1691152607.1491243392045--

------=_Part_2001_1622546673.1491243392045--

.

On 3 April 2017 at 21:16,  <hun.nemethpeter@gmail.com> wrote:
> The main benefit is that you can remove a very diverging coding style from
> the language that simplify maintenance and teaching.


This proposal will not remove anything from the language, it's adding
yet another form of declaration,
so I fail to see how that simplifies teaching.

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

.

------=_Part_1367_674295587.1491245292700
Content-Type: multipart/alternative;
 boundary="----=_Part_1368_499027985.1491245292701"

------=_Part_1368_499027985.1491245292701
Content-Type: text/plain; charset=UTF-8

I proposed to deprecate the "old" syntax. Now you can't pick up a winning
coding style.

int* a;
style can't declare more then one pointer or reference variable in a line.


int *a, *b;
style split the type in two half; following this pattern many declaration
looks like a multiply because they use this in function declaration also:

unknown_type * function();


because there is no winning style the two style always competing which
result in diverged coding styles and diverged code bases.
Deprecating that syntax will result in a unified syntax.
How it helps in teaching? Now we tell colleges: follow the coding style
whatever is in a file.
I want to tell them: variable declaration is the new style. Period.


Peter

On Monday, April 3, 2017 at 8:22:08 PM UTC+2, Ville Voutilainen wrote:
>
> On 3 April 2017 at 21:16,  <hun.nem...@gmail.com <javascript:>> wrote:
> > The main benefit is that you can remove a very diverging coding style
> from
> > the language that simplify maintenance and teaching.
>
>
> This proposal will not remove anything from the language, it's adding
> yet another form of declaration,
> so I fail to see how that simplifies teaching.
>

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

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

<div dir=3D"ltr">I proposed to deprecate the &quot;old&quot; syntax. Now yo=
u can&#39;t pick up a winning coding style.<div><br></div><div><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> a</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">;</span></div></code></div>style can&#39;t de=
clare more then one pointer or reference variable in a line.</div><div><br>=
</div><div><br></div><div><div class=3D"prettyprint" style=3D"background-co=
lor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: so=
lid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"=
><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled=
-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">*<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">a</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">b</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">;</span></div></code></div>style split the type in two =
half; following this pattern many declaration looks like a multiply because=
 they use this in function declaration also:</div><div><br></div><div><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-wr=
ap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint">=
<span style=3D"color: #000;" class=3D"styled-by-prettify">unknown_type </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">function</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">();</span></div></code></div><br><=
/div><div><br></div><div>because there is no winning style the two style al=
ways=C2=A0competing which result in diverged coding styles and diverged cod=
e bases.</div><div>Deprecating that syntax will result in a unified syntax.=
</div><div>How it helps in teaching? Now we tell colleges: follow the codin=
g style whatever is in a file.</div><div>I want to tell them: variable decl=
aration is the new style. Period.</div><div><br></div><div><br></div><div>P=
eter<br><br>On Monday, April 3, 2017 at 8:22:08 PM UTC+2, Ville Voutilainen=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 3 April 2017 at 21:1=
6, =C2=A0&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"nBKuFUGgCQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">hun.nem...@gmail.com</a>&gt; wrote:
<br>&gt; The main benefit is that you can remove a very diverging coding st=
yle from
<br>&gt; the language that simplify maintenance and teaching.
<br>
<br>
<br>This proposal will not remove anything from the language, it&#39;s addi=
ng
<br>yet another form of declaration,
<br>so I fail to see how that simplifies teaching.
<br></blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e5a9cde9-a5f7-4a88-8497-457b59d56eb4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e5a9cde9-a5f7-4a88-8497-457b59d56eb4=
%40isocpp.org</a>.<br />

------=_Part_1368_499027985.1491245292701--

------=_Part_1367_674295587.1491245292700--

.

On 3 April 2017 at 21:48,  <hun.nemethpeter@gmail.com> wrote:
> I proposed to deprecate the "old" syntax. Now you can't pick up a winning
> coding style.

That's not removing it from the language.

> Deprecating that syntax will result in a unified syntax.

No it won't. The attempt at deprecation will fail, for good reasons.

> I want to tell them: variable declaration is the new style. Period.

There's no way to get where you want to go in C++.

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

.

------=_Part_814_998200203.1491245839161
Content-Type: multipart/alternative;
 boundary="----=_Part_815_1624925402.1491245839161"

------=_Part_815_1624925402.1491245839161
Content-Type: text/plain; charset=UTF-8

On Monday, April 3, 2017 at 2:48:12 PM UTC-4, hun.nem...@gmail.com wrote:
>
> I proposed to deprecate the "old" syntax. Now you can't pick up a winning
> coding style.
>

Except that you can, because "deprecate" doesn't mean the same thing as
"remove". `std::auto_ptr` is still in C++11 and 14. It will only be
unavailable when C++17 hits which *removes* it.

So long as it is available, people will continue to use it. It will not
magically go away, nor will your conversion tool be widely used to make it
go away. So even if you deprecated standard variable declaration syntax,
you would never be able to remove it.

And of course, you have to get the C committee to accept it too; otherwise
you will have created an incompatibility between the two languages, for
little benefit.

How it helps in teaching? Now we tell colleges: follow the coding style
> whatever is in a file.
> I want to tell them: variable declaration is the new style. Period.
>

This is not a significant enough benefit to be worth the hassle of adding
another language feature, not to mention the many years of *both* being
available.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/961c2da4-5d75-4520-98b5-202e962e536c%40isocpp.org.

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

<div dir=3D"ltr">On Monday, April 3, 2017 at 2:48:12 PM UTC-4, hun.nem...@g=
mail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
">I proposed to deprecate the &quot;old&quot; syntax. Now you can&#39;t pic=
k up a winning coding style.</div></blockquote><div><br>Except that you can=
, because &quot;deprecate&quot; doesn&#39;t mean the same thing as &quot;re=
move&quot;. `std::auto_ptr` is still in C++11 and 14. It will only be unava=
ilable when C++17 hits which <i>removes</i> it.<br><br>So long as it is ava=
ilable, people will continue to use it. It will not magically go away, nor =
will your conversion tool be widely used to make it go away. So even if you=
 deprecated standard variable declaration syntax, you would never be able t=
o remove it.<br><br>And of course, you have to get the C committee to accep=
t it too; otherwise you will have created an incompatibility between the tw=
o languages, for little benefit.<br><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr"><div>How it helps in teaching? Now we tell=
 colleges: follow the coding style whatever is in a file.</div><div>I want =
to tell them: variable declaration is the new style. Period.</div></div></b=
lockquote><div><br></div>This is not a significant enough benefit to be wor=
th the hassle of adding another language feature, not to mention the many y=
ears of <i>both</i> being available.<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/961c2da4-5d75-4520-98b5-202e962e536c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/961c2da4-5d75-4520-98b5-202e962e536c=
%40isocpp.org</a>.<br />

------=_Part_815_1624925402.1491245839161--

------=_Part_814_998200203.1491245839161--

.

------=_Part_1907_430521662.1491246568370
Content-Type: multipart/alternative;
 boundary="----=_Part_1908_1663171868.1491246568370"

------=_Part_1908_1663171868.1491246568370
Content-Type: text/plain; charset=UTF-8



On Monday, April 3, 2017 at 8:52:22 PM UTC+2, Ville Voutilainen wrote:
>
> On 3 April 2017 at 21:48,  <hun.nem...@gmail.com <javascript:>> wrote:
> > I proposed to deprecate the "old" syntax. Now you can't pick up a
> winning
> > coding style.
>
> That's not removing it from the language.
>
> > Deprecating that syntax will result in a unified syntax.
>
> No it won't. The attempt at deprecation will fail, for good reasons.
>

I doubt. The only reason for the split type style is to able to declare
more then one variable in a line. Enabling a new syntax for this the "split
type style" (int *a) will be meaningless.
Deprecating old syntax will encourage the using of the new syntax and you
can create auto converter for you code base.



>
> > I want to tell them: variable declaration is the new style. Period.
>
> There's no way to get where you want to go in C++.
>
I see the problem.
If I have a large code base of *"int *a"* I don't want to change.
If I have a large code base of *"int* a"* I don't want to change.

What I see now is a constant merge conflict generator as I have many
library in both style.
The current status quo is not ideal either. I saw so many commits which
convert one style to another. And later the merge conflict resolving
patches for it. Then the backporting patch.


Peter

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4bf57ab0-7548-445b-9cb8-34b28ba32af9%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Monday, April 3, 2017 at 8:52:22 PM UTC+2, Vill=
e Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 3 April=
 2017 at 21:48, =C2=A0&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"blW6jOehCQAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">hun.nem...@gmail.com</a>&gt; wrote:
<br>&gt; I proposed to deprecate the &quot;old&quot; syntax. Now you can&#3=
9;t pick up a winning
<br>&gt; coding style.
<br>
<br>That&#39;s not removing it from the language.
<br>
<br>&gt; Deprecating that syntax will result in a unified syntax.
<br>
<br>No it won&#39;t. The attempt at deprecation will fail, for good reasons=
..
<br></blockquote><div><br></div><div>I doubt. The only reason for the split=
 type style is to able to declare more then one variable in a line. Enablin=
g a new syntax for this the &quot;split type style&quot; (int *a) will be m=
eaningless.</div><div>Deprecating old syntax will encourage the using of th=
e new syntax and you can create auto converter for you code base.</div><div=
><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; I want to tell them: variable declaration is the new style. Period=
..
<br>
<br>There&#39;s no way to get where you want to go in C++.
<br></blockquote><div>I see the problem.</div><div>If I have a large code b=
ase of <b>&quot;int *a&quot;</b> I don&#39;t want to change.</div><div>If I=
 have a large code base of <b>&quot;int* a&quot;</b> I don&#39;t want to ch=
ange.</div><div><br></div><div>What I see now is a constant merge conflict =
generator as I have many library in both style.</div><div>The current statu=
s quo is not ideal either. I saw so many commits which convert one style to=
 another. And later the merge conflict resolving patches for it. Then the b=
ackporting patch.</div><div><br></div><div><br></div><div>Peter=C2=A0</div>=
</div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4bf57ab0-7548-445b-9cb8-34b28ba32af9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4bf57ab0-7548-445b-9cb8-34b28ba32af9=
%40isocpp.org</a>.<br />

------=_Part_1908_1663171868.1491246568370--

------=_Part_1907_430521662.1491246568370--

.

------=_Part_1248_311513389.1491247091176
Content-Type: multipart/alternative;
 boundary="----=_Part_1249_1504937784.1491247091176"

------=_Part_1249_1504937784.1491247091176
Content-Type: text/plain; charset=UTF-8

On Monday, April 3, 2017 at 3:09:28 PM UTC-4, hun.nem...@gmail.com wrote:
>
> On Monday, April 3, 2017 at 8:52:22 PM UTC+2, Ville Voutilainen wrote:
>>
>> On 3 April 2017 at 21:48,  <hun.nem...@gmail.com> wrote:
>> > I proposed to deprecate the "old" syntax. Now you can't pick up a
>> winning
>> > coding style.
>>
>> That's not removing it from the language.
>>
>> > Deprecating that syntax will result in a unified syntax.
>>
>> No it won't. The attempt at deprecation will fail, for good reasons.
>>
>
> I doubt. The only reason for the split type style is to able to declare
> more then one variable in a line. Enabling a new syntax for this the "split
> type style" (int *a) will be meaningless.
> Deprecating old syntax will encourage the using of the new syntax
>

No, it will not.

Not everybody will use the new syntax. And so long as you cannot guarantee
that everyone will convert to the new syntax, you *cannot* remove the old
one. And if everybody *knows* that you will never remove the old syntax,
then they're going to keep using it. They may use the new syntax in
specific cases of multiple variable declarations, but they'll use the old
syntax for every-day, common variable declarations.

After all, multiple variable declarations where this matters are the
exception, not the norm.

The practical reality is that you can never remove the old syntax.

and you can create auto converter for you code base.
>

Which nobody will use. Seriously, why would you bother? It's *not that
important* to most people.

> I want to tell them: variable declaration is the new style. Period.
>>
>> There's no way to get where you want to go in C++.
>>
> I see the problem.
> If I have a large code base of *"int *a"* I don't want to change.
> If I have a large code base of *"int* a"* I don't want to change.
>

It's more "if I have a large code base of '*code that works*', I don't want
to change it for zero gain".

What I see now is a constant merge conflict generator as I have many
> library in both style.
> The current status quo is not ideal either.
>

Nobody claimed that it was. But the cure you propose is worse than the
disease, because it doesn't actually cure the disease.

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

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

<div dir=3D"ltr">On Monday, April 3, 2017 at 3:09:28 PM UTC-4, hun.nem...@g=
mail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
">On Monday, April 3, 2017 at 8:52:22 PM UTC+2, Ville Voutilainen wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">On 3 April 2017 at 21:48, =C2=A0&lt;<a=
 rel=3D"nofollow">hun.nem...@gmail.com</a>&gt; wrote:
<br>&gt; I proposed to deprecate the &quot;old&quot; syntax. Now you can&#3=
9;t pick up a winning
<br>&gt; coding style.
<br>
<br>That&#39;s not removing it from the language.
<br>
<br>&gt; Deprecating that syntax will result in a unified syntax.
<br>
<br>No it won&#39;t. The attempt at deprecation will fail, for good reasons=
..
<br></blockquote><div><br></div><div>I doubt. The only reason for the split=
 type style is to able to declare more then one variable in a line. Enablin=
g a new syntax for this the &quot;split type style&quot; (int *a) will be m=
eaningless.</div><div>Deprecating old syntax will encourage the using of th=
e new syntax</div></div></blockquote><div><br>No, it will not.<br><br>Not e=
verybody will use the new syntax. And so long as you cannot guarantee that =
everyone will convert to the new syntax, you <i>cannot</i> remove the old o=
ne. And if everybody <i>knows</i> that you will never remove the old syntax=
, then they&#39;re going to keep using it. They may use the new syntax in s=
pecific cases of multiple variable declarations, but they&#39;ll use the ol=
d syntax for every-day, common variable declarations.<br><br>After all, mul=
tiple variable declarations where this matters are the exception, not the n=
orm.<br><br>The practical reality is that you can never remove the old synt=
ax.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>and you can create auto converter for you code base.</div></div></=
blockquote><div><br>Which nobody will use. Seriously, why would you bother?=
 It&#39;s <i>not that important</i> to most people.<br><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex">
&gt; I want to tell them: variable declaration is the new style. Period.
<br>
<br>There&#39;s no way to get where you want to go in C++.
<br></blockquote><div>I see the problem.</div><div>If I have a large code b=
ase of <b>&quot;int *a&quot;</b> I don&#39;t want to change.</div><div>If I=
 have a large code base of <b>&quot;int* a&quot;</b> I don&#39;t want to ch=
ange.</div></div></blockquote><div><br>It&#39;s more &quot;if I have a larg=
e code base of &#39;<b>code that works</b>&#39;, I don&#39;t want to change=
 it for zero gain&quot;.<br><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr"><div></div><div>What I see now is a constant merge=
 conflict generator as I have many library in both style.</div><div>The cur=
rent status quo is not ideal either.</div></div></blockquote><div><br>Nobod=
y claimed that it was. But the cure you propose is worse than the disease, =
because it doesn&#39;t actually cure the disease.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/37448793-d22f-4fbd-9787-677c9fa8662a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/37448793-d22f-4fbd-9787-677c9fa8662a=
%40isocpp.org</a>.<br />

------=_Part_1249_1504937784.1491247091176--

------=_Part_1248_311513389.1491247091176--

.

------=_Part_93_2435326.1491247188084
Content-Type: multipart/alternative;
 boundary="----=_Part_94_2033680176.1491247188084"

------=_Part_94_2033680176.1491247188084
Content-Type: text/plain; charset=UTF-8



On Monday, April 3, 2017 at 8:57:19 PM UTC+2, Nicol Bolas wrote:
>
> On Monday, April 3, 2017 at 2:48:12 PM UTC-4, hun.nem...@gmail.com wrote:
>>
>> I proposed to deprecate the "old" syntax. Now you can't pick up a winning
>> coding style.
>>
>
> Except that you can, because "deprecate" doesn't mean the same thing as
> "remove". `std::auto_ptr` is still in C++11 and 14. It will only be
> unavailable when C++17 hits which *removes* it.
>
I accept that this is a huge change as it affect almost every single line.
So it needs at least a decade or two to considering removing that syntax.


>
> So long as it is available, people will continue to use it. It will not
> magically go away, nor will your conversion tool be widely used to make it
> go away. So even if you deprecated standard variable declaration syntax,
> you would never be able to remove it.
>
If you get deprecate warning it will encourage you to change.


>
> And of course, you have to get the C committee to accept it too; otherwise
> you will have created an incompatibility between the two languages, for
> little benefit.
>
Code in

extern "C" {}

block can use old syntax but variable declarations in header files are
rare, mostly extern ones.


>
> How it helps in teaching? Now we tell colleges: follow the coding style
>> whatever is in a file.
>> I want to tell them: variable declaration is the new style. Period.
>>
>
> This is not a significant enough benefit to be worth the hassle of adding
> another language feature, not to mention the many years of *both* being
> available.
>

I think we should consider it at least. Not the biggest problem but
definitely a real world problem. I think variable declaration needs an
improvement.


Peter

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

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

<div dir=3D"ltr"><br><br>On Monday, April 3, 2017 at 8:57:19 PM UTC+2, Nico=
l Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>On Monday, April 3, 2017 at 2:48:12 PM UTC-4, <a>hun.nem...@gmail.com</a> =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I proposed t=
o deprecate the &quot;old&quot; syntax. Now you can&#39;t pick up a winning=
 coding style.</div></blockquote><div><br>Except that you can, because &quo=
t;deprecate&quot; doesn&#39;t mean the same thing as &quot;remove&quot;. `s=
td::auto_ptr` is still in C++11 and 14. It will only be unavailable when C+=
+17 hits which <i>removes</i> it.<br></div></div></blockquote><div>I accept=
 that this is a huge change as it affect almost every single line. So it ne=
eds at least a decade or two to considering removing that syntax.</div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div><br>So long as it is available, people will continue to use it. It wil=
l not magically go away, nor will your conversion tool be widely used to ma=
ke it go away. So even if you deprecated standard variable declaration synt=
ax, you would never be able to remove it.<br></div></div></blockquote><div>=
If you get deprecate warning it will=C2=A0encourage you to change.=C2=A0</d=
iv><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><br>And of course, you have to get the C committee to accept =
it too; otherwise you will have created an incompatibility between the two =
languages, for little benefit.<br></div></div></blockquote><div>Code in=C2=
=A0</div><div><br></div><div><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"prettypri=
nt"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">extern</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-pretti=
fy">&quot;C&quot;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{}=
</span></div></code></div><br></div><div>block can use old syntax but varia=
ble declarations in header files are rare, mostly extern ones.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
>How it helps in teaching? Now we tell colleges: follow the coding style wh=
atever is in a file.</div><div>I want to tell them: variable declaration is=
 the new style. Period.</div></div></blockquote><div><br></div>This is not =
a significant enough benefit to be worth the hassle of adding another langu=
age feature, not to mention the many years of <i>both</i> being available.<=
br></div></blockquote><div><br></div><div>I think we should consider it at =
least. Not the biggest problem but definitely a real world problem. I think=
 variable declaration needs an improvement.</div><div><br></div><div><br></=
div><div>Peter=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b0bc844a-eed1-44a6-93c3-3a278161b813%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b0bc844a-eed1-44a6-93c3-3a278161b813=
%40isocpp.org</a>.<br />

------=_Part_94_2033680176.1491247188084--

------=_Part_93_2435326.1491247188084--

.

On 3 April 2017 at 22:19,  <hun.nemethpeter@gmail.com> wrote:
>> So long as it is available, people will continue to use it. It will not
>> magically go away, nor will your conversion tool be widely used to make it
>> go away. So even if you deprecated standard variable declaration syntax, you
>> would never be able to remove it.
> If you get deprecate warning it will encourage you to change.

If a valid variable or a function parameter declaration produces a
deprecation warning,
that will encourage users to tell their implementation vendors to
remove that deprecation
warning from their implementations and never bring it back.

> Code in
>
> extern "C" {}
>
> block can use old syntax but variable declarations in header files are rare,

extern "C" or lack of it is not a mechanism for changing language semantics.

>> This is not a significant enough benefit to be worth the hassle of adding
>> another language feature, not to mention the many years of both being
>> available.
> I think we should consider it at least. Not the biggest problem but

I think we have wasted far more time on this non-starter than we should have.

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

.

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

With your style, is it :

int* :=3D a;int*:=3Da;int* :=3Da;int*:=3D a;
I see an endless merge conflit generator, but even more powerful than befor=
e, because there are more places to put a space :)

If your developers have not learned to :
- Either use a tool as a pre-commit step to uniformize format
- Or just leave format as it is, it is not worth the cost of a commit

Then you are going to have issues whatever solution you propose. And once y=
ou have one of those solutions, you don't need your language change :)

---=20
Lo=C3=AFc



---- Message d'origine ----
De : hun.nemethpeter@gmail.com
=C3=80 : "ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Objet : Re: [std-proposals] Re: Improved variable declaration syntax
Date : 03/04/2017 21:09:28 CEST



On Monday, April 3, 2017 at 8:52:22 PM UTC+2, Ville Voutilainen wrote:On 3 =
April 2017 at 21:48, =C2=A0<hun.nem...@gmail.com> wrote:=20
> I proposed to deprecate the "old" syntax. Now you can't pick up a winning=
=20
> coding style.=20

That's not removing it from the language.=20

> Deprecating that syntax will result in a unified syntax.=20

No it won't. The attempt at deprecation will fail, for good reasons.=20



I doubt. The only reason for the split type style is to able to declare mor=
e then one variable in a line. Enabling a new syntax for this the "split ty=
pe style" (int *a) will be meaningless.

Deprecating old syntax will encourage the using of the new syntax and you c=
an create auto converter for you code base.



=C2=A0

> I want to tell them: variable declaration is the new style. Period.=20

There's no way to get where you want to go in C++.=20

I see the problem.

If I have a large code base of "int *a" I don't want to change.

If I have a large code base of "int* a" I don't want to change.



What I see now is a constant merge conflict generator as I have many librar=
y in both style.

The current status quo is not ideal either. I saw so many commits which con=
vert one style to another. And later the merge conflict resolving patches f=
or it. Then the backporting patch.





Peter=C2=A0


--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/4bf57ab0-7548-445b-9cb8-34b28ba32af9%40isocpp.or=
g.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/ea-mime-58e2a263-4500-1d1f9c%40webmail.numericab=
le.fr.

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transational//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3DUTF-8">
</HEAD>
<BODY>With your style, is it :<br><br><pre>int* :=3D a;</pre><pre>int*:=3Da=
;</pre><pre>int* :=3Da;</pre><pre>int*:=3D a;</pre><br>I see an endless mer=
ge conflit generator, but even more powerful than before, because there are=
 more places to put a space :)<br><br>If your developers have not learned t=
o :<br>- Either use a tool as a pre-commit step to uniformize format<br>- O=
r just leave format as it is, it is not worth the cost of a commit<br><br>T=
hen you are going to have issues whatever solution you propose. And once yo=
u have one of those solutions, you don't need your language change :)<br><b=
r>--- <br>Lo=C3=AFc<br><br><br><br>---- Message d'origine ----<br>
De : hun.nemethpeter@gmail.com<br>
=C3=80 : "ISO C++ Standard - Future Proposals" &lt;std-proposals@isocpp.org=
&gt;<br>
Objet : Re: [std-proposals] Re: Improved variable declaration syntax<br>
Date : 03/04/2017 21:09:28 CEST<br>
<br>
<div dir=3D"ltr"><br><br>On Monday, April 3, 2017 at 8:52:22 PM UTC+2, Vill=
e Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex;">On 3 April 201=
7 at 21:48, &nbsp;&lt;<a gdf-obfuscated-mailto=3D"blW6jOehCQAJ" rel=3D"nofo=
llow">hun.nem...@gmail.com</a>&gt; wrote:
<br>&gt; I proposed to deprecate the "old" syntax. Now you can't pick up a =
winning
<br>&gt; coding style.
<br>
<br>That's not removing it from the language.
<br>
<br>&gt; Deprecating that syntax will result in a unified syntax.
<br>
<br>No it won't. The attempt at deprecation will fail, for good reasons.
<br></blockquote><div><br></div><div>I doubt. The only reason for the split=
 type style is to able to declare more then one variable in a line. Enablin=
g a new syntax for this the "split type style" (int *a) will be meaningless=
..</div><div>Deprecating old syntax will encourage the using of the new synt=
ax and you can create auto converter for you code base.</div><div><br></div=
><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>&gt; I want to tell them: variable declaration is the new style. Period=
..
<br>
<br>There's no way to get where you want to go in C++.
<br></blockquote><div>I see the problem.</div><div>If I have a large code b=
ase of <b>"int *a"</b> I don't want to change.</div><div>If I have a large =
code base of <b>"int* a"</b> I don't want to change.</div><div><br></div><d=
iv>What I see now is a constant merge conflict generator as I have many lib=
rary in both style.</div><div>The current status quo is not ideal either. I=
 saw so many commits which convert one style to another. And later the merg=
e conflict resolving patches for it. Then the backporting patch.</div><div>=
<br></div><div><br></div><div>Peter&nbsp;</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4bf57ab0-7548-445b-9cb8-34b28ba32af9%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/4bf57ab0-7548-445b-9cb8-34b28ba3=
2af9%40isocpp.org</a>.<br></BODY></HTML>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ea-mime-58e2a263-4500-1d1f9c%40webmai=
l.numericable.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/ea-mime-58e2a263-4500-1d1f9c%40w=
ebmail.numericable.fr</a>.<br />

------=_NextPart_001_58e2a263_4500_753bc6c--


.

------=_Part_1822_1287151761.1491248312147
Content-Type: multipart/alternative;
 boundary="----=_Part_1823_83857331.1491248312147"

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



On Monday, April 3, 2017 at 9:28:38 PM UTC+2, Lo=C3=AFc Joly wrote:
>
> With your style, is it :
>
> int* :=3D a;
>
> int*:=3Da;
>
> int* :=3Da;
>
> int*:=3D a;
>
>
> I see an endless merge conflit generator, but even more powerful than=20
> before, because there are more places to put a space :)
>
> No, almost every tool handle white spaces. But they can't handle the=20
rewriting of

int* a;
int* b;

to=20

int *a, *b;



Peter

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/21619d57-cc94-49e5-b5eb-7f65d3d2ede0%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Monday, April 3, 2017 at 9:28:38 PM UTC+2, Lo=
=C3=AFc Joly wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">



<div>With your style, is it :<br><br><pre>int* :=3D a;</pre><pre>int*:=3Da;=
</pre><pre>int* :=3Da;</pre><pre>int*:=3D a;</pre><br>I see an endless merg=
e conflit generator, but even more powerful than before, because there are =
more places to put a space :)<br><br></div></blockquote><div>No, almost eve=
ry tool handle white spaces. But they can&#39;t handle the rewriting of</di=
v><div><br></div><div class=3D"prettyprint" style=3D"background-color: rgb(=
250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bord=
er-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div cla=
ss=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">int</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> a</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> b</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span></div></code></div><div><br>to=C2=A0<br></div><div><br><=
/div><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 25=
0); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1p=
x; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpre=
ttyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">int</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">a</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">b</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;<=
/span></div></code></div><div><br></div><div><br></div><div><br></div><div>=
Peter</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/21619d57-cc94-49e5-b5eb-7f65d3d2ede0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/21619d57-cc94-49e5-b5eb-7f65d3d2ede0=
%40isocpp.org</a>.<br />

------=_Part_1823_83857331.1491248312147--

------=_Part_1822_1287151761.1491248312147--

.

------=_Part_1998_377153371.1491248578575
Content-Type: multipart/alternative;
 boundary="----=_Part_1999_2005511219.1491248578575"

------=_Part_1999_2005511219.1491248578575
Content-Type: text/plain; charset=UTF-8


>
> >> This is not a significant enough benefit to be worth the hassle of
> adding
> >> another language feature, not to mention the many years of both being
> >> available.
> > I think we should consider it at least. Not the biggest problem but
>
> I think we have wasted far more time on this non-starter than we should
> have.
>

This is a real world problem not a theoretical one. I wasted so many time
debating on how should I declare a variable, what should we enforce.
The split coding style and code bases is a fact. This proposal can solve
this problem.


Peter

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

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt;&gt; This=
 is not a significant enough benefit to be worth the hassle of adding
<br>&gt;&gt; another language feature, not to mention the many years of bot=
h being
<br>&gt;&gt; available.
<br>&gt; I think we should consider it at least. Not the biggest problem bu=
t
<br>
<br>I think we have wasted far more time on this non-starter than we should=
 have.
<br></blockquote><div><br></div><div>This is a real world problem not a the=
oretical one. I wasted so many time debating on how should I declare a vari=
able, what should we enforce.</div><div>The split coding style and code bas=
es is a fact. This proposal can solve this problem.</div><div><br></div><di=
v><br></div><div>Peter=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/94ec7963-cf01-4bda-bb64-5d3ccd3d4109%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/94ec7963-cf01-4bda-bb64-5d3ccd3d4109=
%40isocpp.org</a>.<br />

------=_Part_1999_2005511219.1491248578575--

------=_Part_1998_377153371.1491248578575--

.

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

On Mon, Apr 3, 2017 at 9:38 PM <hun.nemethpeter@gmail.com> wrote:

>
>
> On Monday, April 3, 2017 at 9:28:38 PM UTC+2, Lo=C3=AFc Joly wrote:
>
> With your style, is it :
>
> int* :=3D a;
>
> int*:=3Da;
>
> int* :=3Da;
>
> int*:=3D a;
>
>
> I see an endless merge conflit generator, but even more powerful than
> before, because there are more places to put a space :)
>
> No, almost every tool handle white spaces. But they can't handle the
> rewriting of
>
> int* a;
> int* b;
>
> to
>
> int *a, *b;
>
>
>
[citation needed]


>
> Peter
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/21619d57-cc9=
4-49e5-b5eb-7f65d3d2ede0%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/21619d57-cc=
94-49e5-b5eb-7f65d3d2ede0%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

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

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

<div dir=3D"ltr"><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Ap=
r 3, 2017 at 9:38 PM &lt;<a href=3D"mailto:hun.nemethpeter@gmail.com">hun.n=
emethpeter@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr" class=3D"gmail_msg"><br class=3D"gmail_msg"><br class=3D"=
gmail_msg">On Monday, April 3, 2017 at 9:28:38 PM UTC+2, Lo=C3=AFc Joly wro=
te:<blockquote class=3D"gmail_quote gmail_msg" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex">



<div class=3D"gmail_msg">With your style, is it :<br class=3D"gmail_msg"><b=
r class=3D"gmail_msg"><pre class=3D"gmail_msg">int* :=3D a;</pre><pre class=
=3D"gmail_msg">int*:=3Da;</pre><pre class=3D"gmail_msg">int* :=3Da;</pre><p=
re class=3D"gmail_msg">int*:=3D a;</pre><br class=3D"gmail_msg">I see an en=
dless merge conflit generator, but even more powerful than before, because =
there are more places to put a space :)<br class=3D"gmail_msg"><br class=3D=
"gmail_msg"></div></blockquote></div><div dir=3D"ltr" class=3D"gmail_msg"><=
div class=3D"gmail_msg">No, almost every tool handle white spaces. But they=
 can&#39;t handle the rewriting of</div><div class=3D"gmail_msg"><br class=
=3D"gmail_msg"></div><div class=3D"m_4400990209648076168prettyprint gmail_m=
sg" 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"=
m_4400990209648076168prettyprint gmail_msg"><div class=3D"m_440099020964807=
6168subprettyprint gmail_msg"><span style=3D"color:#008" class=3D"m_4400990=
209648076168styled-by-prettify gmail_msg">int</span><span style=3D"color:#6=
60" class=3D"m_4400990209648076168styled-by-prettify gmail_msg">*</span><sp=
an style=3D"color:#000" class=3D"m_4400990209648076168styled-by-prettify gm=
ail_msg"> a</span><span style=3D"color:#660" class=3D"m_4400990209648076168=
styled-by-prettify gmail_msg">;</span><span style=3D"color:#000" class=3D"m=
_4400990209648076168styled-by-prettify gmail_msg"><br class=3D"gmail_msg"><=
/span><span style=3D"color:#008" class=3D"m_4400990209648076168styled-by-pr=
ettify gmail_msg">int</span><span style=3D"color:#660" class=3D"m_440099020=
9648076168styled-by-prettify gmail_msg">*</span><span style=3D"color:#000" =
class=3D"m_4400990209648076168styled-by-prettify gmail_msg"> b</span><span =
style=3D"color:#660" class=3D"m_4400990209648076168styled-by-prettify gmail=
_msg">;</span><span style=3D"color:#000" class=3D"m_4400990209648076168styl=
ed-by-prettify gmail_msg"><br class=3D"gmail_msg"></span></div></code></div=
><div class=3D"gmail_msg"><br class=3D"gmail_msg">to=C2=A0<br class=3D"gmai=
l_msg"></div><div class=3D"gmail_msg"><br class=3D"gmail_msg"></div><div cl=
ass=3D"m_4400990209648076168prettyprint gmail_msg" style=3D"background-colo=
r:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-=
width:1px;word-wrap:break-word"><code class=3D"m_4400990209648076168prettyp=
rint gmail_msg"><div class=3D"m_4400990209648076168subprettyprint gmail_msg=
"><span style=3D"color:#008" class=3D"m_4400990209648076168styled-by-pretti=
fy gmail_msg">int</span><span style=3D"color:#000" class=3D"m_4400990209648=
076168styled-by-prettify gmail_msg"> </span><span style=3D"color:#660" clas=
s=3D"m_4400990209648076168styled-by-prettify gmail_msg">*</span><span style=
=3D"color:#000" class=3D"m_4400990209648076168styled-by-prettify gmail_msg"=
>a</span><span style=3D"color:#660" class=3D"m_4400990209648076168styled-by=
-prettify gmail_msg">,</span><span style=3D"color:#000" class=3D"m_44009902=
09648076168styled-by-prettify gmail_msg"> </span><span style=3D"color:#660"=
 class=3D"m_4400990209648076168styled-by-prettify gmail_msg">*</span><span =
style=3D"color:#000" class=3D"m_4400990209648076168styled-by-prettify gmail=
_msg">b</span><span style=3D"color:#660" class=3D"m_4400990209648076168styl=
ed-by-prettify gmail_msg">;</span></div></code></div><div class=3D"gmail_ms=
g"><br class=3D"gmail_msg"></div><div class=3D"gmail_msg"><br class=3D"gmai=
l_msg"></div></div></blockquote><div><br></div><div>[citation needed]</div>=
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr" class=3D"g=
mail_msg"><div class=3D"gmail_msg"></div><div class=3D"gmail_msg"><br class=
=3D"gmail_msg"></div><div class=3D"gmail_msg">Peter</div></div>

<p class=3D"gmail_msg"></p>

-- <br class=3D"gmail_msg">
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br class=3D"gmail_msg=
">
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" class=3D"gm=
ail_msg" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br cla=
ss=3D"gmail_msg">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"gmail_msg" target=3D"_blank">std-proposals@isocpp.org</a>.<b=
r class=3D"gmail_msg">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/21619d57-cc94-49e5-b5eb-7f65d3d2ede0%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" class=3D"gmail_msg=
" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-prop=
osals/21619d57-cc94-49e5-b5eb-7f65d3d2ede0%40isocpp.org</a>.<br class=3D"gm=
ail_msg">
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdTgbxssPfT0X2uU1%2B0Ks-JQfX1y%2=
B5D6RXbXwoirtNJLcg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdTgbxss=
PfT0X2uU1%2B0Ks-JQfX1y%2B5D6RXbXwoirtNJLcg%40mail.gmail.com</a>.<br />

--001a114c226a7c3c27054c486a3e--

.

------=_Part_1743_1355099408.1491248914834
Content-Type: multipart/alternative;
 boundary="----=_Part_1744_340809105.1491248914835"

------=_Part_1744_340809105.1491248914835
Content-Type: text/plain; charset=UTF-8



On Monday, April 3, 2017 at 9:22:50 PM UTC+2, Ville Voutilainen wrote:
>
> On 3 April 2017 at 22:19,  <hun.nem...@gmail.com <javascript:>> wrote:
> >> So long as it is available, people will continue to use it. It will not
> >> magically go away, nor will your conversion tool be widely used to make
> it
> >> go away. So even if you deprecated standard variable declaration
> syntax, you
> >> would never be able to remove it.
> > If you get deprecate warning it will encourage you to change.
>
> If a valid variable or a function parameter declaration produces a
> deprecation warning,
> that will encourage users to tell their implementation vendors to
> remove that deprecation
> warning from their implementations and never bring it back.
>
>
You can turn off almost every compiler warning. But you have to explicitly
specify the language standard. So you have to issue a -std=c++20 or
something like that.
The compiler should inform the user that there is a new syntax for this
thing, It can tell what is the new syntax and how can the user convert it
automatically.
And it should inform the once per translation unit to avoid warning flood.
I think it can be done.


Peter

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

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

<div dir=3D"ltr"><br><br>On Monday, April 3, 2017 at 9:22:50 PM UTC+2, Vill=
e Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 3 April=
 2017 at 22:19, =C2=A0&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"C0NBFZGjCQAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">hun.nem...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; So long as it is available, people will continue to use it. It=
 will not
<br>&gt;&gt; magically go away, nor will your conversion tool be widely use=
d to make it
<br>&gt;&gt; go away. So even if you deprecated standard variable declarati=
on syntax, you
<br>&gt;&gt; would never be able to remove it.
<br>&gt; If you get deprecate warning it will encourage you to change.
<br>
<br>If a valid variable or a function parameter declaration produces a
<br>deprecation warning,
<br>that will encourage users to tell their implementation vendors to
<br>remove that deprecation
<br>warning from their implementations and never bring it back.
<br><br></blockquote><div><br></div><div>You can turn off almost every comp=
iler warning. But you have to explicitly specify the language standard. So =
you have to issue a -std=3Dc++20 or something like that.</div><div>The comp=
iler should inform the user that there is a new syntax for this thing, It c=
an tell what is the new syntax and how can the user convert it automaticall=
y.</div><div>And it should inform the once per translation unit to avoid wa=
rning flood. I think it can be done.</div><div><br></div><div><br></div><di=
v>Peter</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2d5b3a6a-050e-4bde-bbef-a60cc8111b3f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2d5b3a6a-050e-4bde-bbef-a60cc8111b3f=
%40isocpp.org</a>.<br />

------=_Part_1744_340809105.1491248914835--

------=_Part_1743_1355099408.1491248914834--

.

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

On Mon, Apr 3, 2017 at 9:42 PM <hun.nemethpeter@gmail.com> wrote:

> >> This is not a significant enough benefit to be worth the hassle of
> adding
> >> another language feature, not to mention the many years of both being
> >> available.
> > I think we should consider it at least. Not the biggest problem but
>
> I think we have wasted far more time on this non-starter than we should
> have.
>
>
> This is a real world problem not a theoretical one. I wasted so many time
> debating on how should I declare a variable, what should we enforce.
> The split coding style and code bases is a fact. This proposal can solve
> this problem.
>
>
The solution to "too many ways to declare a variable" is supposed to be
"add more ways to declare a variable"?


>
> Peter
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/94ec7963-cf01-4bda-bb64-5d3ccd3d4109%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/94ec7963-cf01-4bda-bb64-5d3ccd3d4109%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

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

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Apr 3,=
 2017 at 9:42 PM &lt;<a href=3D"mailto:hun.nemethpeter@gmail.com">hun.nemet=
hpeter@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr" class=3D"gmail_msg"><blockquote class=3D"gmail_quote gmail_ms=
g" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">&gt;&gt; This is not a significant enough benefit to be worth the =
hassle of adding
<br class=3D"gmail_msg">&gt;&gt; another language feature, not to mention t=
he many years of both being
<br class=3D"gmail_msg">&gt;&gt; available.
<br class=3D"gmail_msg">&gt; I think we should consider it at least. Not th=
e biggest problem but
<br class=3D"gmail_msg">
<br class=3D"gmail_msg">I think we have wasted far more time on this non-st=
arter than we should have.
<br class=3D"gmail_msg"></blockquote><div class=3D"gmail_msg"><br class=3D"=
gmail_msg"></div></div><div dir=3D"ltr" class=3D"gmail_msg"><div class=3D"g=
mail_msg">This is a real world problem not a theoretical one. I wasted so m=
any time debating on how should I declare a variable, what should we enforc=
e.</div><div class=3D"gmail_msg">The split coding style and code bases is a=
 fact. This proposal can solve this problem.</div><div class=3D"gmail_msg">=
<br class=3D"gmail_msg"></div></div></blockquote><div><br></div><div>The so=
lution to &quot;too many ways to declare a variable&quot; is supposed to be=
 &quot;add more ways to declare a variable&quot;?</div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr" class=3D"gmail_msg"><div class=
=3D"gmail_msg"></div><div class=3D"gmail_msg"><br class=3D"gmail_msg"></div=
><div class=3D"gmail_msg">Peter=C2=A0</div></div>

<p class=3D"gmail_msg"></p>

-- <br class=3D"gmail_msg">
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br class=3D"gmail_msg=
">
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" class=3D"gm=
ail_msg" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br cla=
ss=3D"gmail_msg">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"gmail_msg" target=3D"_blank">std-proposals@isocpp.org</a>.<b=
r class=3D"gmail_msg">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/94ec7963-cf01-4bda-bb64-5d3ccd3d4109%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" class=3D"gmail_msg=
" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-prop=
osals/94ec7963-cf01-4bda-bb64-5d3ccd3d4109%40isocpp.org</a>.<br class=3D"gm=
ail_msg">
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdSBWPk%3D_z7g7ycrr4cTa3B2y-yCiQ=
DQj_tsJMzY1t8BnA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdSBWPk%3D=
_z7g7ycrr4cTa3B2y-yCiQDQj_tsJMzY1t8BnA%40mail.gmail.com</a>.<br />

--001a1140331ecfbf62054c4873c2--

.

------=_Part_209_1182923879.1491249079144
Content-Type: multipart/alternative;
 boundary="----=_Part_210_2111933297.1491249079144"

------=_Part_210_2111933297.1491249079144
Content-Type: text/plain; charset=UTF-8

A current solution to "taming" awkward types that involve *, &, [], or ()
is to do something like

template <typename T>
using Type = T;

// Example usage
Type<int*> a, b, c, d;

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

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

<div dir=3D"ltr">A current solution to &quot;taming&quot; awkward types tha=
t involve *, &amp;, [], or () is to do something like<br><br><div style=3D"=
background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bor=
der-style: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"p=
rettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">template</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">typename</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">using</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">=
Type</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: =
#800;" class=3D"styled-by-prettify">// Example usage</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: =
#606;" class=3D"styled-by-prettify">Type</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">*&gt;</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> a</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> b</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> c</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> d</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">;</span></div></code></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ec24f045-a742-4d47-b33d-d5a9b87fe438%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ec24f045-a742-4d47-b33d-d5a9b87fe438=
%40isocpp.org</a>.<br />

------=_Part_210_2111933297.1491249079144--

------=_Part_209_1182923879.1491249079144--

.

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

On Mon, Apr 3, 2017 at 9:48 PM <hun.nemethpeter@gmail.com> wrote:

>
>
> On Monday, April 3, 2017 at 9:22:50 PM UTC+2, Ville Voutilainen wrote:
>
> On 3 April 2017 at 22:19,  <hun.nem...@gmail.com> wrote:
> >> So long as it is available, people will continue to use it. It will not
> >> magically go away, nor will your conversion tool be widely used to make
> it
> >> go away. So even if you deprecated standard variable declaration
> syntax, you
> >> would never be able to remove it.
> > If you get deprecate warning it will encourage you to change.
>
> If a valid variable or a function parameter declaration produces a
> deprecation warning,
> that will encourage users to tell their implementation vendors to
> remove that deprecation
> warning from their implementations and never bring it back.
>
>
> You can turn off almost every compiler warning. But you have to explicitly
> specify the language standard. So you have to issue a -std=c++20 or
> something like that.
> The compiler should inform the user that there is a new syntax for this
> thing, It can tell what is the new syntax and how can the user convert it
> automatically.
> And it should inform the once per translation unit to avoid warning flood.
> I think it can be done.
>
>
And just as a general note: there are industries where changing the code,
even (or maybe especially?) automatically is no-go, because, say, the code
needs to be certified and any change to it (including this one!) requires
recertification.

To put it simply: your plan to deprecate-and-remove the current widely used
syntax won't fly. It won't even be let to push back from the gate, much
less allowed on a taxiway or a runway.


>
> Peter
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2d5b3a6a-050e-4bde-bbef-a60cc8111b3f%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2d5b3a6a-050e-4bde-bbef-a60cc8111b3f%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

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

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Apr 3,=
 2017 at 9:48 PM &lt;<a href=3D"mailto:hun.nemethpeter@gmail.com">hun.nemet=
hpeter@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr" class=3D"gmail_msg"><br class=3D"gmail_msg"><br class=3D"gmai=
l_msg">On Monday, April 3, 2017 at 9:22:50 PM UTC+2, Ville Voutilainen wrot=
e:</div><div dir=3D"ltr" class=3D"gmail_msg"><blockquote class=3D"gmail_quo=
te gmail_msg" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex">On 3 April 2017 at 22:19, =C2=A0&lt;<a rel=3D"nofollow"=
 class=3D"gmail_msg">hun.nem...@gmail.com</a>&gt; wrote:
<br class=3D"gmail_msg">&gt;&gt; So long as it is available, people will co=
ntinue to use it. It will not
<br class=3D"gmail_msg">&gt;&gt; magically go away, nor will your conversio=
n tool be widely used to make it
<br class=3D"gmail_msg">&gt;&gt; go away. So even if you deprecated standar=
d variable declaration syntax, you
<br class=3D"gmail_msg">&gt;&gt; would never be able to remove it.
<br class=3D"gmail_msg">&gt; If you get deprecate warning it will encourage=
 you to change.
<br class=3D"gmail_msg">
<br class=3D"gmail_msg">If a valid variable or a function parameter declara=
tion produces a
<br class=3D"gmail_msg">deprecation warning,
<br class=3D"gmail_msg">that will encourage users to tell their implementat=
ion vendors to
<br class=3D"gmail_msg">remove that deprecation
<br class=3D"gmail_msg">warning from their implementations and never bring =
it back.
<br class=3D"gmail_msg"><br class=3D"gmail_msg"></blockquote><div class=3D"=
gmail_msg"><br class=3D"gmail_msg"></div></div><div dir=3D"ltr" class=3D"gm=
ail_msg"><div class=3D"gmail_msg">You can turn off almost every compiler wa=
rning. But you have to explicitly specify the language standard. So you hav=
e to issue a -std=3Dc++20 or something like that.</div><div class=3D"gmail_=
msg">The compiler should inform the user that there is a new syntax for thi=
s thing, It can tell what is the new syntax and how can the user convert it=
 automatically.</div><div class=3D"gmail_msg">And it should inform the once=
 per translation unit to avoid warning flood. I think it can be done.</div>=
<div class=3D"gmail_msg"><br class=3D"gmail_msg"></div></div></blockquote><=
div><br></div><div>And just as a general note: there are industries where c=
hanging the code, even (or maybe especially?) automatically is no-go, becau=
se, say, the code needs to be certified and any change to it (including thi=
s one!) requires recertification.</div><div><br></div><div>To put it simply=
: your plan to deprecate-and-remove the current widely used syntax won&#39;=
t fly. It won&#39;t even be let to push back from the gate, much less allow=
ed on a taxiway or a runway.</div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr" class=3D"gmail_msg"><div class=3D"gmail_msg"></div>=
<div class=3D"gmail_msg"><br class=3D"gmail_msg"></div><div class=3D"gmail_=
msg">Peter</div></div>

<p class=3D"gmail_msg"></p>

-- <br class=3D"gmail_msg">
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br class=3D"gmail_msg=
">
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" class=3D"gm=
ail_msg" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br cla=
ss=3D"gmail_msg">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"gmail_msg" target=3D"_blank">std-proposals@isocpp.org</a>.<b=
r class=3D"gmail_msg">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2d5b3a6a-050e-4bde-bbef-a60cc8111b3f%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" class=3D"gmail_msg=
" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-prop=
osals/2d5b3a6a-050e-4bde-bbef-a60cc8111b3f%40isocpp.org</a>.<br class=3D"gm=
ail_msg">
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdT2x0fHD4GytvtqbXYg667uNa2nrJso=
Rh_NiRMC%3DcziCA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdT2x0fHD4=
GytvtqbXYg667uNa2nrJsoRh_NiRMC%3DcziCA%40mail.gmail.com</a>.<br />

--001a1140331ead05d9054c48820c--

.

------=_Part_2059_191211538.1491249267190
Content-Type: multipart/alternative;
 boundary="----=_Part_2060_1236007986.1491249267190"

------=_Part_2060_1236007986.1491249267190
Content-Type: text/plain; charset=UTF-8


>
>
> The solution to "too many ways to declare a variable" is supposed to be
> "add more ways to declare a variable"?
>
No. I want to replace two defected way of declaring variable with a new one.


Peter

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

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div class=3D"gmail_quote"><div><br></div><div>The solution to &quot;to=
o many ways to declare a variable&quot; is supposed to be &quot;add more wa=
ys to declare a variable&quot;?</div><div></div></div></div></blockquote><d=
iv>No. I want to replace two defected way of declaring variable with a new =
one.</div><div>=C2=A0</div><div><br></div><div>Peter</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a738447e-bef1-4840-bdae-58d5496f12e6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a738447e-bef1-4840-bdae-58d5496f12e6=
%40isocpp.org</a>.<br />

------=_Part_2060_1236007986.1491249267190--

------=_Part_2059_191211538.1491249267190--

.

------=_Part_1679_504023786.1491249544542
Content-Type: multipart/alternative;
 boundary="----=_Part_1680_2107949252.1491249544542"

------=_Part_1680_2107949252.1491249544542
Content-Type: text/plain; charset=UTF-8

Wow.. Looks interesting.

Peter

On Monday, April 3, 2017 at 9:51:19 PM UTC+2, Chris Hallock wrote:
>
> A current solution to "taming" awkward types that involve *, &, [], or ()
> is to do something like
>
> template <typename T>
> using Type = T;
>
> // Example usage
> Type<int*> a, b, c, d;
>

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

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

<div dir=3D"ltr">Wow.. Looks interesting.<div><br></div><div>Peter<br><br>O=
n Monday, April 3, 2017 at 9:51:19 PM UTC+2, Chris Hallock wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">A current solution to &=
quot;taming&quot; awkward types that involve *, &amp;, [], or () is to do s=
omething like<br><br><div style=3D"background-color:rgb(250,250,250);border=
-color:rgb(187,187,187);border-style:solid;border-width:1px"><code><div><sp=
an style=3D"color:#008">template</span><span style=3D"color:#000"> </span><=
span style=3D"color:#660">&lt;</span><span style=3D"color:#008">typename</s=
pan><span style=3D"color:#000"> T</span><span style=3D"color:#660">&gt;</sp=
an><span style=3D"color:#000"><br></span><span style=3D"color:#008">using</=
span><span style=3D"color:#000"> </span><span style=3D"color:#606">Type</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#660">=3D</span>=
<span style=3D"color:#000"> T</span><span style=3D"color:#660">;</span><spa=
n style=3D"color:#000"><br><br></span><span style=3D"color:#800">// Example=
 usage</span><span style=3D"color:#000"><br></span><span style=3D"color:#60=
6">Type</span><span style=3D"color:#660">&lt;</span><span style=3D"color:#0=
08">int</span><span style=3D"color:#660">*&gt;</span><span style=3D"color:#=
000"> a</span><span style=3D"color:#660">,</span><span style=3D"color:#000"=
> b</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> c<=
/span><span style=3D"color:#660">,</span><span style=3D"color:#000"> d</spa=
n><span style=3D"color:#660">;</span></div></code></div></div></blockquote>=
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/38705744-b3dd-4c4e-b4f7-e710c4362060%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/38705744-b3dd-4c4e-b4f7-e710c4362060=
%40isocpp.org</a>.<br />

------=_Part_1680_2107949252.1491249544542--

------=_Part_1679_504023786.1491249544542--

.

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

On Mon, Apr 3, 2017 at 12:42 PM, <hun.nemethpeter@gmail.com> wrote:

> >> This is not a significant enough benefit to be worth the hassle of
>> adding
>> >> another language feature, not to mention the many years of both being
>> >> available.
>> > I think we should consider it at least. Not the biggest problem but
>>
>> I think we have wasted far more time on this non-starter than we should
>> have.
>>
>
> This is a real world problem not a theoretical one. I wasted so many time
> debating on how should I declare a variable, what should we enforce.
> The split coding style and code bases is a fact. This proposal can solve
> this problem.
>
>
You want to change the language because you and your co-workers are
obsessed with having a single coding style and you can't agree on which one?

Sorry, but I think your problem simply doesn't matter.


>
> Peter
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/94ec7963-cf01-4bda-
> bb64-5d3ccd3d4109%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/94ec7963-cf01-4bda-bb64-5d3ccd3d4109%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>



--
*Brian Bi*

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

--94eb2c091feee5653b054c489f62
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 M=
on, Apr 3, 2017 at 12:42 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:hun.n=
emethpeter@gmail.com" target=3D"_blank">hun.nemethpeter@gmail.com</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"><div dir=3D"ltr"><span class=
=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex">&gt;&gt; This is not a signif=
icant enough benefit to be worth the hassle of adding
<br>&gt;&gt; another language feature, not to mention the many years of bot=
h being
<br>&gt;&gt; available.
<br>&gt; I think we should consider it at least. Not the biggest problem bu=
t
<br>
<br>I think we have wasted far more time on this non-starter than we should=
 have.
<br></blockquote><div><br></div></span><div>This is a real world problem no=
t a theoretical one. I wasted so many time debating on how should I declare=
 a variable, what should we enforce.</div><div>The split coding style and c=
ode bases is a fact. This proposal can solve this problem.</div><div><br></=
div></div></blockquote><div><br></div><div>You want to change the language =
because you and your co-workers are obsessed with having a single coding st=
yle and you can&#39;t agree on which one?<br><br></div><div>Sorry, but I th=
ink your problem simply doesn&#39;t matter.<br></div><div>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div><br></div><div>P=
eter=C2=A0</div></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/94ec7963-cf01-4bda-bb64-5d3ccd3d4109%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/94ec=
7963-cf01-4bda-<wbr>bb64-5d3ccd3d4109%40isocpp.org</a><wbr>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=
=3D"ltr"><font color=3D"#c0c0c0"><i>Brian Bi</i></font><br><div></div><div>=
</div><div></div></div></div></div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAMmfjbPF%3DuqTxBravrsn8ZizZMG-G%2Bhy=
4VLq%3DXQ0k0nYUxGdGA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMmfjbPF%3=
DuqTxBravrsn8ZizZMG-G%2Bhy4VLq%3DXQ0k0nYUxGdGA%40mail.gmail.com</a>.<br />

--94eb2c091feee5653b054c489f62--

.

------=_Part_1857_1203124358.1491249721959
Content-Type: multipart/alternative;
 boundary="----=_Part_1858_787588717.1491249721959"

------=_Part_1858_787588717.1491249721959
Content-Type: text/plain; charset=UTF-8


>
>
>>
> And just as a general note: there are industries where changing the code,
> even (or maybe especially?) automatically is no-go, because, say, the code
> needs to be certified and any change to it (including this one!) requires
> recertification.
>
> To put it simply: your plan to deprecate-and-remove the current widely
> used syntax won't fly. It won't even be let to push back from the gate,
> much less allowed on a taxiway or a runway.
>
>

Ok, but changing c++ standard in compilers is allowed? They can stick to
-std=c++17 and that is all.

Peter

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/22aca542-e245-4f90-88e8-6ba0b80e6a88%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div><br></div></div></blockquote><div><br></div><div>And just as a gen=
eral note: there are industries where changing the code, even (or maybe esp=
ecially?) automatically is no-go, because, say, the code needs to be certif=
ied and any change to it (including this one!) requires recertification.</d=
iv><div><br></div><div>To put it simply: your plan to deprecate-and-remove =
the current widely used syntax won&#39;t fly. It won&#39;t even be let to p=
ush back from the gate, much less allowed on a taxiway or a runway.</div><d=
iv>=C2=A0</div></div></div></blockquote><div><br></div><div>Ok, but changin=
g c++ standard in compilers is allowed? They can stick to -std=3Dc++17 and =
that is all.</div><div><br></div><div>Peter=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/22aca542-e245-4f90-88e8-6ba0b80e6a88%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/22aca542-e245-4f90-88e8-6ba0b80e6a88=
%40isocpp.org</a>.<br />

------=_Part_1858_787588717.1491249721959--

------=_Part_1857_1203124358.1491249721959--

.

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

On Mon, Apr 3, 2017 at 10:02 PM <hun.nemethpeter@gmail.com> wrote:

>
>
> And just as a general note: there are industries where changing the code,
> even (or maybe especially?) automatically is no-go, because, say, the code
> needs to be certified and any change to it (including this one!) requires
> recertification.
>
> To put it simply: your plan to deprecate-and-remove the current widely
> used syntax won't fly. It won't even be let to push back from the gate,
> much less allowed on a taxiway or a runway.
>
>
>
> Ok, but changing c++ standard in compilers is allowed? They can stick to
> -std=c++17 and that is all.
>

They will not want to be stuck without features from C++20 and above.

As Brian put it, your problem doesn't matter in the grand scheme of things,
where it's impossible to implement your proposed solution.


>
> Peter
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/22aca542-e245-4f90-88e8-6ba0b80e6a88%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/22aca542-e245-4f90-88e8-6ba0b80e6a88%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

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

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Apr 3,=
 2017 at 10:02 PM &lt;<a href=3D"mailto:hun.nemethpeter@gmail.com">hun.neme=
thpeter@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr" class=3D"gmail_msg"><blockquote class=3D"gmail_quote gmail_m=
sg" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr" class=3D"gmail_msg"><div class=3D"gmail_quote gm=
ail_msg"><blockquote class=3D"gmail_quote gmail_msg" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr" class=3D=
"gmail_msg"><div class=3D"gmail_msg"><br class=3D"gmail_msg"></div></div></=
blockquote><div class=3D"gmail_msg"><br class=3D"gmail_msg"></div><div clas=
s=3D"gmail_msg">And just as a general note: there are industries where chan=
ging the code, even (or maybe especially?) automatically is no-go, because,=
 say, the code needs to be certified and any change to it (including this o=
ne!) requires recertification.</div><div class=3D"gmail_msg"><br class=3D"g=
mail_msg"></div><div class=3D"gmail_msg">To put it simply: your plan to dep=
recate-and-remove the current widely used syntax won&#39;t fly. It won&#39;=
t even be let to push back from the gate, much less allowed on a taxiway or=
 a runway.</div><div class=3D"gmail_msg">=C2=A0</div></div></div></blockquo=
te><div class=3D"gmail_msg"><br class=3D"gmail_msg"></div></div><div dir=3D=
"ltr" class=3D"gmail_msg"><div class=3D"gmail_msg">Ok, but changing c++ sta=
ndard in compilers is allowed? They can stick to -std=3Dc++17 and that is a=
ll.</div></div></blockquote><div><br></div><div>They will not want to be st=
uck without features from C++20 and above.</div><div><br></div><div>As Bria=
n put it, your problem doesn&#39;t matter in the grand scheme of things, wh=
ere it&#39;s impossible to implement your proposed solution.</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr" class=3D"gmail_msg=
"><div class=3D"gmail_msg"><br class=3D"gmail_msg"></div><div class=3D"gmai=
l_msg">Peter=C2=A0</div></div>

<p class=3D"gmail_msg"></p>

-- <br class=3D"gmail_msg">
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br class=3D"gmail_msg=
">
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" class=3D"gm=
ail_msg" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br cla=
ss=3D"gmail_msg">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"gmail_msg" target=3D"_blank">std-proposals@isocpp.org</a>.<b=
r class=3D"gmail_msg">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/22aca542-e245-4f90-88e8-6ba0b80e6a88%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" class=3D"gmail_msg=
" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-prop=
osals/22aca542-e245-4f90-88e8-6ba0b80e6a88%40isocpp.org</a>.<br class=3D"gm=
ail_msg">
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdSGxFkON7thAoKdfR0x7VgdC41ef6ps=
Thn6AF5Joy88DQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdSGxFkON7th=
AoKdfR0x7VgdC41ef6psThn6AF5Joy88DQ%40mail.gmail.com</a>.<br />

--001a11403c4c4b1c6d054c48a853--

.

------=_Part_1985_502755450.1491249976365
Content-Type: multipart/alternative;
 boundary="----=_Part_1986_680474463.1491249976365"

------=_Part_1986_680474463.1491249976365
Content-Type: text/plain; charset=UTF-8


>
>
>> You want to change the language because you and your co-workers are
> obsessed with having a single coding style and you can't agree on which one?
>
> Sorry, but I think your problem simply doesn't matter.
>
>

The problem is that I have more then 100 000+ co-workers as this is a big
company. Ok, not everybody is developer but you know...
And we have to use hundreds of third party libraries.


Peter

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

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div><br></div></div></blockquote><div>You want to change the lang=
uage because you and your co-workers are obsessed with having a single codi=
ng style and you can&#39;t agree on which one?<br><br></div><div>Sorry, but=
 I think your problem simply doesn&#39;t matter.<br></div><div>=C2=A0</div>=
</div></div></div></blockquote><div><br></div><div>The problem is that I ha=
ve more then 100 000+ co-workers as this is a big company. Ok, not everybod=
y is developer but you know...</div><div>And we have to use hundreds of thi=
rd party libraries.=C2=A0</div><div><br></div><div><br></div><div>Peter</di=
v></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/88702ee5-f391-499e-a639-00608f4997d9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/88702ee5-f391-499e-a639-00608f4997d9=
%40isocpp.org</a>.<br />

------=_Part_1986_680474463.1491249976365--

------=_Part_1985_502755450.1491249976365--

.

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

On Mon, Apr 3, 2017 at 10:06 PM <hun.nemethpeter@gmail.com> wrote:

>
> You want to change the language because you and your co-workers are
> obsessed with having a single coding style and you can't agree on which one?
>
> Sorry, but I think your problem simply doesn't matter.
>
>
>
> The problem is that I have more then 100 000+ co-workers as this is a big
> company. Ok, not everybody is developer but you know...
> And we have to use hundreds of third party libraries.
>
>
Wow, two separate strawmans in such a short mail!

The first "argument" isn't an argument, for *multiple* reasons:
1) It's a hyperbole. You tried to impress us with a number, hoped we will
be impressed by it, and hoped that we won't notice that you immediately
admitted it's nonsense. This is irritating.
2) *Even* *if* (1) wasn't true, you still aren't working with 100k other
people on the same piece of code. You're divided into groups into subgroups
into subgroups. And there'll always be someone in one of those subgroups
that are responsible for a project or a dozen of those who will be able to
make a decision everybody will have to honor. (By the way this is how you
work in an environment with multiple people - you can't satistfy everyone,
and democratically trying to do so is bound to waste gigantic amounts of
time - just like this thread).

And the second "argument" genuinely makes me angry, because multiple people
tried to stop a unification I was trying to conduct because "you can't
unify this in 3rd party libraries, why would you try it in our code?". This
non-argument is much, much worse than the first one, because it hinders any
attempts at making progress in your own code - "because 3rd party
libraries!".


> Peter
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/88702ee5-f391-499e-a639-00608f4997d9%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/88702ee5-f391-499e-a639-00608f4997d9%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

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

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Apr 3,=
 2017 at 10:06 PM &lt;<a href=3D"mailto:hun.nemethpeter@gmail.com">hun.neme=
thpeter@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr" class=3D"gmail_msg"><blockquote class=3D"gmail_quote gmail_m=
sg" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr" class=3D"gmail_msg"><div class=3D"gmail_msg"><di=
v class=3D"gmail_quote gmail_msg"><blockquote class=3D"gmail_quote gmail_ms=
g" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr" class=3D"gmail_msg"><div class=3D"gmail_msg"><br class=3D"=
gmail_msg"></div></div></blockquote><div class=3D"gmail_msg">You want to ch=
ange the language because you and your co-workers are obsessed with having =
a single coding style and you can&#39;t agree on which one?<br class=3D"gma=
il_msg"><br class=3D"gmail_msg"></div><div class=3D"gmail_msg">Sorry, but I=
 think your problem simply doesn&#39;t matter.<br class=3D"gmail_msg"></div=
><div class=3D"gmail_msg">=C2=A0</div></div></div></div></blockquote><div c=
lass=3D"gmail_msg"><br class=3D"gmail_msg"></div></div><div dir=3D"ltr" cla=
ss=3D"gmail_msg"><div class=3D"gmail_msg">The problem is that I have more t=
hen 100 000+ co-workers as this is a big company. Ok, not everybody is deve=
loper but you know...</div><div class=3D"gmail_msg">And we have to use hund=
reds of third party libraries.=C2=A0</div><div class=3D"gmail_msg"><br clas=
s=3D"gmail_msg"></div></div></blockquote><div><br></div><div>Wow, two separ=
ate strawmans in such a short mail!</div><div><br></div><div>The first &quo=
t;argument&quot; isn&#39;t an argument, for <i>multiple</i>=C2=A0reasons:</=
div><div>1) It&#39;s a hyperbole. You tried to impress us with a number, ho=
ped we will be impressed by it, and hoped that we won&#39;t notice that you=
 immediately admitted it&#39;s nonsense. This is irritating.</div><div>2) <=
i>Even</i>=C2=A0<i>if</i>=C2=A0(1) wasn&#39;t true, you still aren&#39;t wo=
rking with 100k other people on the same piece of code. You&#39;re divided =
into groups into subgroups into subgroups. And there&#39;ll always be someo=
ne in one of those subgroups that are responsible for a project or a dozen =
of those who will be able to make a decision everybody will have to honor. =
(By the way this is how you work in an environment with multiple people - y=
ou can&#39;t satistfy everyone, and democratically trying to do so is bound=
 to waste gigantic amounts of time - just like this thread).</div><div><br>=
</div><div>And the second &quot;argument&quot; genuinely makes me angry, be=
cause multiple people tried to stop a unification I was trying to conduct b=
ecause &quot;you can&#39;t unify this in 3rd party libraries, why would you=
 try it in our code?&quot;. This non-argument is much, much worse than the =
first one, because it hinders any attempts at making progress in your own c=
ode - &quot;because 3rd party libraries!&quot;.</div><div><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr" class=3D"gmail_msg"><div class=3D"=
gmail_msg"></div><div class=3D"gmail_msg"><br class=3D"gmail_msg"></div><di=
v class=3D"gmail_msg">Peter</div></div>

<p class=3D"gmail_msg"></p>

-- <br class=3D"gmail_msg">
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br class=3D"gmail_msg=
">
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" class=3D"gm=
ail_msg" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br cla=
ss=3D"gmail_msg">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"gmail_msg" target=3D"_blank">std-proposals@isocpp.org</a>.<b=
r class=3D"gmail_msg">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/88702ee5-f391-499e-a639-00608f4997d9%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" class=3D"gmail_msg=
" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-prop=
osals/88702ee5-f391-499e-a639-00608f4997d9%40isocpp.org</a>.<br class=3D"gm=
ail_msg">
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdQyykN_TGOn5uMw7-J0y%3DmfU2s8LA=
DYVQ7LokcEHPadpQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdQyykN_TG=
On5uMw7-J0y%3DmfU2s8LADYVQ7LokcEHPadpQ%40mail.gmail.com</a>.<br />

--001a1140193eb18cbe054c48e2cb--

.

------=_Part_860_1781023827.1491251528913
Content-Type: multipart/alternative;
 boundary="----=_Part_861_252232195.1491251528913"

------=_Part_861_252232195.1491251528913
Content-Type: text/plain; charset=UTF-8


>
> Wow, two separate strawmans in such a short mail!
>
> The first "argument" isn't an argument, for *multiple* reasons:
> 1) It's a hyperbole. You tried to impress us with a number, hoped we will
> be impressed by it, and hoped that we won't notice that you immediately
> admitted it's nonsense. This is irritating.
> 2) *Even* *if* (1) wasn't true, you still aren't working with 100k other
> people on the same piece of code. You're divided into groups into subgroups
> into subgroups. And there'll always be someone in one of those subgroups
> that are responsible for a project or a dozen of those who will be able to
> make a decision everybody will have to honor. (By the way this is how you
> work in an environment with multiple people - you can't satistfy everyone,
> and democratically trying to do so is bound to waste gigantic amounts of
> time - just like this thread).
>
> And the second "argument" genuinely makes me angry, because multiple
> people tried to stop a unification I was trying to conduct because "you
> can't unify this in 3rd party libraries, why would you try it in our
> code?". This non-argument is much, much worse than the first one, because
> it hinders any attempts at making progress in your own code - "because 3rd
> party libraries!".
>

What I want to describe is the environment where I work. This is not a
monolithic code base and there is more then one dedicated developer
group... and sometimes not even a single company.
And what I saw one of the biggest coding style fragmentation is the "int*
a", "int *a". When I ask developers why they choose one or other the answer
is that what I described in this thread.
They want to declare multiple variable in one line or they want a clear
look on what the type is. My conclusion is that the current type
declaration syntax is confusing enough to improve it.
The current status quo is this two-head monster. One head is the "int *a"
other is the "int* a". And I think both are weak and confusing.


Peter

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

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

<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div class=3D=
"gmail_quote"><div>Wow, two separate strawmans in such a short mail!</div><=
div><br></div><div>The first &quot;argument&quot; isn&#39;t an argument, fo=
r <i>multiple</i>=C2=A0reasons:</div><div>1) It&#39;s a hyperbole. You trie=
d to impress us with a number, hoped we will be impressed by it, and hoped =
that we won&#39;t notice that you immediately admitted it&#39;s nonsense. T=
his is irritating.</div><div>2) <i>Even</i>=C2=A0<i>if</i>=C2=A0(1) wasn&#3=
9;t true, you still aren&#39;t working with 100k other people on the same p=
iece of code. You&#39;re divided into groups into subgroups into subgroups.=
 And there&#39;ll always be someone in one of those subgroups that are resp=
onsible for a project or a dozen of those who will be able to make a decisi=
on everybody will have to honor. (By the way this is how you work in an env=
ironment with multiple people - you can&#39;t satistfy everyone, and democr=
atically trying to do so is bound to waste gigantic amounts of time - just =
like this thread).</div><div><br></div><div>And the second &quot;argument&q=
uot; genuinely makes me angry, because multiple people tried to stop a unif=
ication I was trying to conduct because &quot;you can&#39;t unify this in 3=
rd party libraries, why would you try it in our code?&quot;. This non-argum=
ent is much, much worse than the first one, because it hinders any attempts=
 at making progress in your own code - &quot;because 3rd party libraries!&q=
uot;.</div></div></div></blockquote><div><br></div><div>What I want to desc=
ribe is the environment where I work. This is not a monolithic code base an=
d there is more then one dedicated developer group... and sometimes not eve=
n a single company.</div><div>And what I saw one of the biggest coding styl=
e fragmentation is the &quot;int* a&quot;, &quot;int *a&quot;. When I ask d=
evelopers why they choose one or other the answer is that what I described =
in this thread.</div><div>They want to declare multiple variable in one lin=
e or they want a clear look on what the type is. My conclusion is that the =
current type declaration syntax is confusing enough to improve it.</div><di=
v>The current status quo is this two-head monster. One head is the &quot;in=
t *a&quot; other is the &quot;int* a&quot;. And I think both are weak and c=
onfusing.</div><div><br></div><div><br></div><div>Peter=C2=A0</div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e504a876-5791-4eec-a1b0-fb32475d20fc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e504a876-5791-4eec-a1b0-fb32475d20fc=
%40isocpp.org</a>.<br />

------=_Part_861_252232195.1491251528913--

------=_Part_860_1781023827.1491251528913--

.

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

On Mon, Apr 3, 2017 at 1:32 PM, <hun.nemethpeter@gmail.com> wrote:

> Wow, two separate strawmans in such a short mail!
>>
>> The first "argument" isn't an argument, for *multiple* reasons:
>> 1) It's a hyperbole. You tried to impress us with a number, hoped we will
>> be impressed by it, and hoped that we won't notice that you immediately
>> admitted it's nonsense. This is irritating.
>> 2) *Even* *if* (1) wasn't true, you still aren't working with 100k other
>> people on the same piece of code. You're divided into groups into subgroups
>> into subgroups. And there'll always be someone in one of those subgroups
>> that are responsible for a project or a dozen of those who will be able to
>> make a decision everybody will have to honor. (By the way this is how you
>> work in an environment with multiple people - you can't satistfy everyone,
>> and democratically trying to do so is bound to waste gigantic amounts of
>> time - just like this thread).
>>
>> And the second "argument" genuinely makes me angry, because multiple
>> people tried to stop a unification I was trying to conduct because "you
>> can't unify this in 3rd party libraries, why would you try it in our
>> code?". This non-argument is much, much worse than the first one, because
>> it hinders any attempts at making progress in your own code - "because 3rd
>> party libraries!".
>>
>
> What I want to describe is the environment where I work. This is not a
> monolithic code base and there is more then one dedicated developer
> group... and sometimes not even a single company.
> And what I saw one of the biggest coding style fragmentation is the "int*
> a", "int *a". When I ask developers why they choose one or other the answer
> is that what I described in this thread.
>

Why is "coding style fragmentation" such a big issue?

Since your company doesn't have a unified coding style, just follow the
existing style of whatever file you're editing. And pick your own preferred
style when adding a new source file. This is what everyone else does.


> They want to declare multiple variable in one line or they want a clear
> look on what the type is. My conclusion is that the current type
> declaration syntax is confusing enough to improve it.
> The current status quo is this two-head monster. One head is the "int *a"
> other is the "int* a". And I think both are weak and confusing.
>
>
> Peter
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/e504a876-5791-4eec-
> a1b0-fb32475d20fc%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e504a876-5791-4eec-a1b0-fb32475d20fc%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>



--
*Brian Bi*

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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Apr 3, 2017 at 1:32 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:hun.nemethpeter@gmail.com" target=3D"_blank">hun.nemethpeter@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"><span class=3D""><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_qu=
ote"><div>Wow, two separate strawmans in such a short mail!</div><div><br><=
/div><div>The first &quot;argument&quot; isn&#39;t an argument, for <i>mult=
iple</i>=C2=A0reasons:</div><div>1) It&#39;s a hyperbole. You tried to impr=
ess us with a number, hoped we will be impressed by it, and hoped that we w=
on&#39;t notice that you immediately admitted it&#39;s nonsense. This is ir=
ritating.</div><div>2) <i>Even</i>=C2=A0<i>if</i>=C2=A0(1) wasn&#39;t true,=
 you still aren&#39;t working with 100k other people on the same piece of c=
ode. You&#39;re divided into groups into subgroups into subgroups. And ther=
e&#39;ll always be someone in one of those subgroups that are responsible f=
or a project or a dozen of those who will be able to make a decision everyb=
ody will have to honor. (By the way this is how you work in an environment =
with multiple people - you can&#39;t satistfy everyone, and democratically =
trying to do so is bound to waste gigantic amounts of time - just like this=
 thread).</div><div><br></div><div>And the second &quot;argument&quot; genu=
inely makes me angry, because multiple people tried to stop a unification I=
 was trying to conduct because &quot;you can&#39;t unify this in 3rd party =
libraries, why would you try it in our code?&quot;. This non-argument is mu=
ch, much worse than the first one, because it hinders any attempts at makin=
g progress in your own code - &quot;because 3rd party libraries!&quot;.</di=
v></div></div></blockquote><div><br></div></span><div>What I want to descri=
be is the environment where I work. This is not a monolithic code base and =
there is more then one dedicated developer group... and sometimes not even =
a single company.</div><div>And what I saw one of the biggest coding style =
fragmentation is the &quot;int* a&quot;, &quot;int *a&quot;. When I ask dev=
elopers why they choose one or other the answer is that what I described in=
 this thread.</div></blockquote><div><br></div>Why is &quot;coding style fr=
agmentation&quot; such a big issue?<br><br></div><div class=3D"gmail_quote"=
>Since your company doesn&#39;t have a unified coding style, just follow th=
e existing style of whatever file you&#39;re editing. And pick your own pre=
ferred style when adding a new source file. This is what everyone else does=
..<br></div><div class=3D"gmail_quote"><div>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div>They want to declare multiple variable in one line or they =
want a clear look on what the type is. My conclusion is that the current ty=
pe declaration syntax is confusing enough to improve it.</div><div>The curr=
ent status quo is this two-head monster. One head is the &quot;int *a&quot;=
 other is the &quot;int* a&quot;. And I think both are weak and confusing.<=
/div><span class=3D""><div><br></div><div><br></div><div>Peter=C2=A0</div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e504a876-5791-4eec-a1b0-fb32475d20fc%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/e504=
a876-5791-4eec-<wbr>a1b0-fb32475d20fc%40isocpp.org</a><wbr>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=
=3D"ltr"><font color=3D"#c0c0c0"><i>Brian Bi</i></font><br><div></div><div>=
</div><div></div></div></div></div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAMmfjbMC3fgoJ6%3DbjygTJ-esaW_d2hnkXv=
DBROph999z6V%3DavQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMmfjbMC3fgo=
J6%3DbjygTJ-esaW_d2hnkXvDBROph999z6V%3DavQ%40mail.gmail.com</a>.<br />

--001a113507002ed2ec054c491cd8--

.

------=_Part_43_1162747821.1491252785210
Content-Type: multipart/alternative;
 boundary="----=_Part_44_638300856.1491252785210"

------=_Part_44_638300856.1491252785210
Content-Type: text/plain; charset=UTF-8


>
>
> Why is "coding style fragmentation" such a big issue?
>

I describe this thing as a merge conflict generator. And I saw so many
wasted hours where a developer rewrite a code part from one style to
another. And I took part in so many debate around coding styles.
What I found is that the main reason for the variable declaration coding
style fragmentation is the inherent weakness of the current syntax.
Developers wants clear view from a type and want to declare more then one
in a line. Separating type parts are confusing and writing every
declaration to a new line is an ugly solution.
Currently there is no good solution. Ok, I saw in this thread a template
trick that is interesting.
The result is two concurrent coding style and I think it worth eliminating
it by a new syntax.



>
> Since your company doesn't have a unified coding style, just follow the
> existing style of whatever file you're editing. And pick your own preferred
> style when adding a new source file. This is what everyone else does.
>
>
This is the current status quo.


Peter

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

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote"><div><br></div>Why is &quot;coding styl=
e fragmentation&quot; such a big issue?<br></div></div></div></blockquote><=
div><br></div><div>I describe this thing as a merge conflict generator. And=
 I saw so many wasted hours where a developer rewrite a code part from one =
style to another. And I took part in so many debate around coding styles.</=
div><div>What I found is that the main reason for the variable declaration =
coding style fragmentation is the inherent weakness of the current syntax.<=
/div><div>Developers wants clear view from a type and want to declare more =
then one in a line. Separating type parts are confusing and writing every d=
eclaration to a new line is an ugly solution.</div><div>Currently there is =
no good solution. Ok, I saw in this thread a template trick that is interes=
ting.</div><div>The result is two concurrent coding style and I think it wo=
rth eliminating it by a new syntax.</div><div><br></div><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Since your company do=
esn&#39;t have a unified coding style, just follow the existing style of wh=
atever file you&#39;re editing. And pick your own preferred style when addi=
ng a new source file. This is what everyone else does.<br></div><div class=
=3D"gmail_quote"><div>=C2=A0</div></div></div></div></blockquote><div>This =
is the current status quo.</div><div><br></div><div><br></div><div>Peter=C2=
=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/eb985b84-9bc9-4656-9dac-a6ac14303fc1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/eb985b84-9bc9-4656-9dac-a6ac14303fc1=
%40isocpp.org</a>.<br />

------=_Part_44_638300856.1491252785210--

------=_Part_43_1162747821.1491252785210--

.

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

> And I saw so many wasted hours where a developer rewrite a code part from
one style to another. And I took part in so many debate around coding
styles.

So the problem really is that in your company you don't have a style guide
that is mandatory to everyone?
With all respect, let's not try to fix the lack of leadership and the
weakness of management in your company with a major language change.

On Tue, Apr 4, 2017 at 4:53 AM, <hun.nemethpeter@gmail.com> wrote:

>
>> Why is "coding style fragmentation" such a big issue?
>>
>
> I describe this thing as a merge conflict generator. And I saw so many
> wasted hours where a developer rewrite a code part from one style to
> another. And I took part in so many debate around coding styles.
> What I found is that the main reason for the variable declaration coding
> style fragmentation is the inherent weakness of the current syntax.
> Developers wants clear view from a type and want to declare more then one
> in a line. Separating type parts are confusing and writing every
> declaration to a new line is an ugly solution.
> Currently there is no good solution. Ok, I saw in this thread a template
> trick that is interesting.
> The result is two concurrent coding style and I think it worth eliminating
> it by a new syntax.
>
>
>
>>
>> Since your company doesn't have a unified coding style, just follow the
>> existing style of whatever file you're editing. And pick your own preferred
>> style when adding a new source file. This is what everyone else does.
>>
>>
> This is the current status quo.
>
>
> Peter
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/eb985b84-9bc9-4656-
> 9dac-a6ac14303fc1%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/eb985b84-9bc9-4656-9dac-a6ac14303fc1%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

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

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

<div dir=3D"ltr"><div><div>&gt; And I saw so many wasted hours where a deve=
loper rewrite a code part=20
from one style to another. And I took part in so many debate around=20
coding styles.<br><br></div>So the problem really is that in your company y=
ou don&#39;t have a style guide that is mandatory to everyone?<br>With all =
respect, let&#39;s not try to fix the lack of leadership and the weakness o=
f management in your company with a major language change.<br></div></div><=
div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Apr 4, 201=
7 at 4:53 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:hun.nemethpeter@gmai=
l.com" target=3D"_blank">hun.nemethpeter@gmail.com</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""><blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_qu=
ote"><div><br></div>Why is &quot;coding style fragmentation&quot; such a bi=
g issue?<br></div></div></div></blockquote><div><br></div></span><div>I des=
cribe this thing as a merge conflict generator. And I saw so many wasted ho=
urs where a developer rewrite a code part from one style to another. And I =
took part in so many debate around coding styles.</div><div>What I found is=
 that the main reason for the variable declaration coding style fragmentati=
on is the inherent weakness of the current syntax.</div><div>Developers wan=
ts clear view from a type and want to declare more then one in a line. Sepa=
rating type parts are confusing and writing every declaration to a new line=
 is an ugly solution.</div><div>Currently there is no good solution. Ok, I =
saw in this thread a template trick that is interesting.</div><div>The resu=
lt is two concurrent coding style and I think it worth eliminating it by a =
new syntax.</div><span class=3D""><div><br></div><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_qu=
ote"><br></div><div class=3D"gmail_quote">Since your company doesn&#39;t ha=
ve a unified coding style, just follow the existing style of whatever file =
you&#39;re editing. And pick your own preferred style when adding a new sou=
rce file. This is what everyone else does.<br></div><div class=3D"gmail_quo=
te"><div>=C2=A0</div></div></div></div></blockquote></span><div>This is the=
 current status quo.</div><div><br></div><div><br></div><div>Peter=C2=A0</d=
iv></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/eb985b84-9bc9-4656-9dac-a6ac14303fc1%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/eb98=
5b84-9bc9-4656-<wbr>9dac-a6ac14303fc1%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2B6mTDf4B5K8b9zte%3DCYW8LSWj0fF2mp=
4H%3DGJCMZBCG1aoJcdg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2B6mTDf4=
B5K8b9zte%3DCYW8LSWj0fF2mp4H%3DGJCMZBCG1aoJcdg%40mail.gmail.com</a>.<br />

--001a1136e238eed818054c4d787a--

.

------=_Part_10658_238686767.1491291911368
Content-Type: multipart/alternative;
 boundary="----=_Part_10659_37056331.1491291911369"

------=_Part_10659_37056331.1491291911369
Content-Type: text/plain; charset=UTF-8

Your idea won't really fix (all) your issues:

void foo(int *p, const int& r); // where do you stick the * and the & ?


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

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

<div dir=3D"ltr">Your idea won&#39;t really fix (all) your issues:<div><br>=
</div><div><div class=3D"prettyprint" style=3D"background-color: rgb(250, 2=
50, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wid=
th: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"=
subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">v=
oid</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">p</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">const</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> r</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" cla=
ss=3D"styled-by-prettify">// where do you stick the * and the &amp; ?</span=
></div></code></div><br></div><div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/439db180-b54b-42e3-a5d0-d429046ca7db%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/439db180-b54b-42e3-a5d0-d429046ca7db=
%40isocpp.org</a>.<br />

------=_Part_10659_37056331.1491291911369--

------=_Part_10658_238686767.1491291911368--

.

------=_Part_95_1997745423.1491292153634
Content-Type: multipart/alternative;
 boundary="----=_Part_96_247735623.1491292153634"

------=_Part_96_247735623.1491292153634
Content-Type: text/plain; charset=UTF-8



Op maandag 3 april 2017 16:45:12 UTC+2 schreef hun.nem...@gmail.com:
>
> I took part in so many syntax debates over the years on preferred variable
> declaration syntax.
>
> One of the neuralgic point of variable declaration syntax is the pointer
> and reference alignment style.
>
> The root problem is the following:
>
> int* a, b;
>
> This declares a pointer and an int which is confusing. So a common coding
> style to avoid this error is aligning pointer to variables:
>
> int *a, b;
>
> Which is also confusing sometimes as some type parts are separated from
> the "main" type.
>

Hi,

Does this occur (in your codebase) often?
Most of the time I initialize variables right away and then I don't do
multiple variables in one statement.


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

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

<div dir=3D"ltr"><br><br>Op maandag 3 april 2017 16:45:12 UTC+2 schreef hun=
..nem...@gmail.com:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div>I took part in so many syntax debates over the years on preferred=
 variable declaration syntax.</div><div><br></div><div>One of the neuralgic=
 point of variable declaration syntax is the pointer and reference alignmen=
t style.</div><div><br></div><div>The root problem is the following:<br></d=
iv><div><br></div><div><div style=3D"background-color:rgb(250,250,250);bord=
er-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:bre=
ak-word"><code><div><span style=3D"color:#008">int</span><span style=3D"col=
or:#660">*</span><span style=3D"color:#000"> a</span><span style=3D"color:#=
660">,</span><span style=3D"color:#000"> b</span><span style=3D"color:#660"=
>;</span></div></code></div><br></div><div>This declares a pointer and an i=
nt which is confusing. So a common coding style to avoid this error is alig=
ning pointer to variables:</div><div><br></div><div><div style=3D"backgroun=
d-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;b=
order-width:1px;word-wrap:break-word"><code><div><span style=3D"color:#008"=
>int</span><span style=3D"color:#000"> </span><span style=3D"color:#660">*<=
/span><span style=3D"color:#000">a</span><span style=3D"color:#660">,</span=
><span style=3D"color:#000"> b</span><span style=3D"color:#660">;</span></d=
iv></code></div><br></div><div>Which is also confusing sometimes as some ty=
pe parts are separated from the &quot;main&quot; type.</div></div></blockqu=
ote><div><br></div><div>Hi,</div><div><br></div><div>Does this occur (in yo=
ur codebase) often?</div><div>Most of the time I initialize variables right=
 away and then I don&#39;t do multiple variables in one statement.</div><di=
v>=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/246b9dad-71d9-4878-b251-05bb1ff81294%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/246b9dad-71d9-4878-b251-05bb1ff81294=
%40isocpp.org</a>.<br />

------=_Part_96_247735623.1491292153634--

------=_Part_95_1997745423.1491292153634--

.

I have to agree with Olaf in that you in good C++ normally only
declare one variable per line - and initialize it right away.
And of course I have to agree with Ville that this proposal should be
dead from the beginning, as it is trying to solve a non-existing
problem.

/Peter

On Tue, Apr 4, 2017 at 9:49 AM,  <olaf@join.cc> wrote:
>
>
> Op maandag 3 april 2017 16:45:12 UTC+2 schreef hun.nem...@gmail.com:
>>
>> I took part in so many syntax debates over the years on preferred variable
>> declaration syntax.
>>
>> One of the neuralgic point of variable declaration syntax is the pointer
>> and reference alignment style.
>>
>> The root problem is the following:
>>
>> int* a, b;
>>
>> This declares a pointer and an int which is confusing. So a common coding
>> style to avoid this error is aligning pointer to variables:
>>
>> int *a, b;
>>
>> Which is also confusing sometimes as some type parts are separated from
>> the "main" type.
>
>
> Hi,
>
> Does this occur (in your codebase) often?
> Most of the time I initialize variables right away and then I don't do
> multiple variables in one statement.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/246b9dad-71d9-4878-b251-05bb1ff81294%40isocpp.org.

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

.

------=_Part_2318_82055660.1491299133063
Content-Type: multipart/alternative;
 boundary="----=_Part_2319_1442835130.1491299133063"

------=_Part_2319_1442835130.1491299133063
Content-Type: text/plain; charset=UTF-8

If you have power you have everything. But I don't have enough power to
force one style  EVERYWHERE. And there is no winner here. I can select one
solution and force it everywhere but in that case I force an inherently bad
style.
Both dominant variable declaration style has weak in some case. Booth style
are unnatural.

Peter

On Tuesday, April 4, 2017 at 3:48:30 AM UTC+2, Maxim Yanchenko wrote:
>
> > And I saw so many wasted hours where a developer rewrite a code part
> from one style to another. And I took part in so many debate around coding
> styles.
>
> So the problem really is that in your company you don't have a style guide
> that is mandatory to everyone?
> With all respect, let's not try to fix the lack of leadership and the
> weakness of management in your company with a major language change.
>
>

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

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

<div dir=3D"ltr">If you have power you have everything. But I don&#39;t hav=
e enough power to force one style =C2=A0EVERYWHERE. And there is no winner =
here. I can select one solution and force it everywhere but in that case I =
force an inherently bad style.<div>Both dominant variable declaration style=
 has weak in some case. Booth style are unnatural.</div><div><br></div><div=
>Peter<br><br>On Tuesday, April 4, 2017 at 3:48:30 AM UTC+2, Maxim Yanchenk=
o wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>=
<div>&gt; And I saw so many wasted hours where a developer rewrite a code p=
art=20
from one style to another. And I took part in so many debate around=20
coding styles.<br><br></div>So the problem really is that in your company y=
ou don&#39;t have a style guide that is mandatory to everyone?<br>With all =
respect, let&#39;s not try to fix the lack of leadership and the weakness o=
f management in your company with a major language change.<br></div></div><=
div><br></div>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f31808bc-0fd2-4d1b-af05-9fba3b5b4899%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f31808bc-0fd2-4d1b-af05-9fba3b5b4899=
%40isocpp.org</a>.<br />

------=_Part_2319_1442835130.1491299133063--

------=_Part_2318_82055660.1491299133063--

.

------=_Part_2565_653143213.1491299337081
Content-Type: multipart/alternative;
 boundary="----=_Part_2566_585906425.1491299337081"

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


So you have an "int*" type with name "p" and a "const int&" type with name=
=20
"r". Why do you want to put a space in a type? Why do you want to separate=
=20
a type? The * and & signs are part of the type and they are not part of the=
=20
name.

Peter


On Tuesday, April 4, 2017 at 9:45:11 AM UTC+2, P=C3=A9ter Radics wrote:
>
> Your idea won't really fix (all) your issues:
>
> void foo(int *p, const int& r); // where do you stick the * and the & ?
>
>
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/e7956281-aef1-4990-8d7b-f8ab3ddcdebe%40isocpp.or=
g.

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

<div dir=3D"ltr"><br>So you have an &quot;int*&quot; type with name &quot;p=
&quot; and a &quot;const int&amp;&quot; type with name &quot;r&quot;. Why d=
o you want to put a space in a type? Why do you want to separate a type? Th=
e * and &amp; signs are part of the type and they are not part of the name.=
<div><br></div><div>Peter<br><br><br>On Tuesday, April 4, 2017 at 9:45:11 A=
M UTC+2, P=C3=A9ter Radics wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div dir=3D"ltr">Your idea won&#39;t really fix (all) your issues:<div><=
br></div><div><div 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><div><span style=3D"color:#008">void</span><span style=3D"color:#000"=
> foo</span><span style=3D"color:#660">(</span><span style=3D"color:#008">i=
nt</span><span style=3D"color:#000"> </span><span style=3D"color:#660">*</s=
pan><span style=3D"color:#000">p</span><span style=3D"color:#660">,</span><=
span style=3D"color:#000"> </span><span style=3D"color:#008">const</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#008">int</span><span=
 style=3D"color:#660">&amp;</span><span style=3D"color:#000"> r</span><span=
 style=3D"color:#660">);</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#800">// where do you stick the * and the &amp; ?</span></div><=
/code></div><br></div><div><br></div></div></blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e7956281-aef1-4990-8d7b-f8ab3ddcdebe%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e7956281-aef1-4990-8d7b-f8ab3ddcdebe=
%40isocpp.org</a>.<br />

------=_Part_2566_585906425.1491299337081--

------=_Part_2565_653143213.1491299337081--

.

------=_Part_2211_44302940.1491299743045
Content-Type: multipart/alternative;
 boundary="----=_Part_2212_1975128310.1491299743045"

------=_Part_2212_1975128310.1491299743045
Content-Type: text/plain; charset=UTF-8

I saw many cases where putting every pointer declaration to a new line was
impractical. And I saw cases where a given code parts come from C. Forcing
developers to put every declaration to a new line was error prone and slow.
And variable declaration is happen in classses also. Ok they are members in
that case but syntax is the same.

Consider

struct SomeGraph  {
    Node* top;
    Node* posX;
    Node* posY;
    Node* posZ;
    ...
};



Peter

On Tuesday, April 4, 2017 at 9:59:23 AM UTC+2, Peter Koch Larsen wrote:
>
> I have to agree with Olaf in that you in good C++ normally only
> declare one variable per line - and initialize it right away.
> And of course I have to agree with Ville that this proposal should be
> dead from the beginning, as it is trying to solve a non-existing
> problem.
>
> /Peter
>
>

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

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

<div dir=3D"ltr"><div>I saw many cases where putting every pointer declarat=
ion to a new line was impractical. And I saw cases where a given code parts=
 come from C. Forcing developers to put every declaration to a new line was=
 error prone and slow.</div>And variable declaration is happen in classses =
also. Ok they are members in that case but syntax is the same.<div><br></di=
v><div>Consider</div><div><br></div><div class=3D"prettyprint" style=3D"bac=
kground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border=
-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pr=
ettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by=
-prettify">SomeGraph</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> =C2=A0</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r>=C2=A0 =C2=A0 </span><span style=3D"color: #606;" class=3D"styled-by-pret=
tify">Node</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
*</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> top</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span=
><span style=3D"color: #606;" class=3D"styled-by-prettify">Node</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> posX</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">Node</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> posY</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">Node</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> posZ</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">...=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code>=
</div><div><br><br></div><div><br></div><div>Peter</div><div><br>On Tuesday=
, April 4, 2017 at 9:59:23 AM UTC+2, Peter Koch Larsen wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;">I have to agree with Olaf in that you in goo=
d C++ normally only
<br>declare one variable per line - and initialize it right away.
<br>And of course I have to agree with Ville that this proposal should be
<br>dead from the beginning, as it is trying to solve a non-existing
<br>problem.
<br>
<br>/Peter
<br><br></blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/194424f0-5f73-4aa3-b466-fc3dd5da208c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/194424f0-5f73-4aa3-b466-fc3dd5da208c=
%40isocpp.org</a>.<br />

------=_Part_2212_1975128310.1491299743045--

------=_Part_2211_44302940.1491299743045--

.

------=_Part_1431_553428894.1491321802799
Content-Type: multipart/alternative;
 boundary="----=_Part_1432_1753354563.1491321802799"

------=_Part_1432_1753354563.1491321802799
Content-Type: text/plain; charset=UTF-8

On Monday, April 3, 2017 at 2:08:25 PM UTC-4, hun.nem...@gmail.com wrote:
>
>
>> Yes, you could do
>>
>> using matrix = long_namespace::big_special_matrix<SoBigNumber>;
>>
>> to make the declarations shorter.
>>
>> matrix*   x;
>> matrix*   y;
>> matrix*   z;
>>
>> will confuse no one.
>>
>
> In this case you have to force developers to to create an abbreviation for
> every long typename during variable declaration.
> And you have to declare what is long. And again you have to copy paste
> that type again and again.
>
> struct A {
>     using matrix = long_namespace::big_special_matrix<SoBigNumber>;
>     matrix*   x;
>     matrix*   y;
>     matrix*   z;
> };
>
> vs.
>
> struct A {
>     long_namespace::big_special_matrix<SoBigNumber>* := x, y, z;
>  };
>
>
You don't have to copy again and again.

struct A {
    using matrixPtr = long_namespace::big_special_matrix<SoBigNumber>*;
    matrixPtr x, y, z;
}



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

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

<div dir=3D"ltr">On Monday, April 3, 2017 at 2:08:25 PM UTC-4, hun.nem...@g=
mail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><br>Yes, you could do
<br>
<br>using matrix =3D long_namespace::big_special_<wbr>matrix&lt;SoBigNumber=
&gt;;
<br>
<br>to make the declarations shorter.
<br>
<br>matrix* =C2=A0 x;
<br>matrix* =C2=A0 y;
<br>matrix* =C2=A0 z;
<br>
<br>will confuse no one.=C2=A0<br></blockquote><div><br></div><div>In this =
case you have to force developers to to create an abbreviation for every lo=
ng typename during variable declaration.</div><div>And you have to declare =
what is long. And again you have to copy paste that type again and again.</=
div><div><br></div><div style=3D"background-color:rgb(250,250,250);border-c=
olor:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-w=
ord"><code><div><span style=3D"color:#008">struct</span><span style=3D"colo=
r:#000"> A </span><span style=3D"color:#660">{</span><span style=3D"color:#=
000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">using</span><span =
style=3D"color:#000"> matrix </span><span style=3D"color:#660">=3D</span><s=
pan style=3D"color:#000"> long_namespace</span><span style=3D"color:#660">:=
:</span><span style=3D"color:#000">big_special_<wbr>matrix</span><span styl=
e=3D"color:#660">&lt;</span><span style=3D"color:#606">SoBigNumber</span><s=
pan style=3D"color:#660">&gt;;</span><span style=3D"color:#000"> <br>=C2=A0=
 =C2=A0 matrix</span><span style=3D"color:#660">*</span><span style=3D"colo=
r:#000"> =C2=A0 x</span><span style=3D"color:#660">;</span><span style=3D"c=
olor:#000"> <br>=C2=A0 =C2=A0 matrix</span><span style=3D"color:#660">*</sp=
an><span style=3D"color:#000"> =C2=A0 y</span><span style=3D"color:#660">;<=
/span><span style=3D"color:#000"> <br>=C2=A0 =C2=A0 matrix</span><span styl=
e=3D"color:#660">*</span><span style=3D"color:#000"> =C2=A0 z</span><span s=
tyle=3D"color:#660">;</span><span style=3D"color:#000"> <br></span><span st=
yle=3D"color:#660">};</span><span style=3D"color:#000"> <br></span></div></=
code></div><div><br>vs.<br></div><div><br></div><div style=3D"background-co=
lor:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;borde=
r-width:1px;word-wrap:break-word"><code><div><span style=3D"color:#008">str=
uct</span><span style=3D"color:#000"> A </span><span style=3D"color:#660">{=
</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 long_namespace</span><s=
pan style=3D"color:#660">::</span><span style=3D"color:#000">big_special_<w=
br>matrix</span><span style=3D"color:#660">&lt;</span><span style=3D"color:=
#606">SoBigNumber</span><span style=3D"color:#660">&gt;*</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">:=3D</span><span style=
=3D"color:#000"> x</span><span style=3D"color:#660">,</span><span style=3D"=
color:#000"> y</span><span style=3D"color:#660">,</span><span style=3D"colo=
r:#000"> z</span><span style=3D"color:#660">;</span><span style=3D"color:#0=
00"><br>=C2=A0</span><span style=3D"color:#660">};</span><span style=3D"col=
or:#000"> <br></span></div></code></div><div><br></div></div></blockquote><=
div><br></div><div>You don&#39;t have to copy again and again.</div><div>=
=C2=A0 <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"subp=
rettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">struc=
t</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> A </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">using</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> matrixPtr </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> long_namespace</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">big_special_matrix</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">SoBigNumber</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">&gt;*</span><font color=3D"=
#008800"><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0=
 matrixPtr x</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> y</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> z</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">}</span></font></div></code></div><br>=C2=A0</d=
iv></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9d7f1950-e591-4e50-9b27-221e48434037%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9d7f1950-e591-4e50-9b27-221e48434037=
%40isocpp.org</a>.<br />

------=_Part_1432_1753354563.1491321802799--

------=_Part_1431_553428894.1491321802799--

.

------=_Part_2479_1844717950.1491322270775
Content-Type: multipart/alternative;
 boundary="----=_Part_2480_296648726.1491322270775"

------=_Part_2480_296648726.1491322270775
Content-Type: text/plain; charset=UTF-8

The "int* a" coding style mostly comes with a "declare one variable per
line" rule to avoid the following cases: "int* a, b"
This solution breaks that rule and also introduce an other identifier just
to declare some variables.
There isn't a clean way to declare multiple pointer or reference in one
line. There are two competing method and both are bad in some way.
And this dual style itself cause bugs, debates and errors. That is the
reason behind this proposal.

Peter


>
> You don't have to copy again and again.
>
> struct A {
>     using matrixPtr = long_namespace::big_special_matrix<SoBigNumber>*;
>     matrixPtr x, y, z;
> }
>
>
>

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

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

<div dir=3D"ltr"><div>The &quot;int* a&quot; coding style mostly comes with=
 a &quot;declare one variable per line&quot; rule to avoid the following ca=
ses: &quot;int* a, b&quot;</div><div>This solution breaks that rule and als=
o introduce an other identifier just to declare some variables.</div><div>T=
here isn&#39;t a clean way to declare multiple pointer or reference in one =
line. There are two competing method and both are bad in some way.</div><di=
v>And this dual style itself cause bugs, debates and errors. That is the re=
ason behind this proposal.</div><div><br></div><div>Peter</div><div>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div></div></blockqu=
ote><div><br></div><div>You don&#39;t have to copy again and again.</div><d=
iv>=C2=A0 <div style=3D"background-color:rgb(250,250,250);border-color:rgb(=
187,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><cod=
e><div><span style=3D"color:#008">struct</span><span style=3D"color:#000"> =
A </span><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color:#008">using</span><span style=3D"=
color:#000"> matrixPtr </span><span style=3D"color:#660">=3D</span><span st=
yle=3D"color:#000"> long_namespace</span><span style=3D"color:#660">::</spa=
n><span style=3D"color:#000">big_special_<wbr>matrix</span><span style=3D"c=
olor:#660">&lt;</span><span style=3D"color:#606">SoBigNumber</span><span st=
yle=3D"color:#660">&gt;*</span><font color=3D"#008800"><span style=3D"color=
:#660">;</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 matrixPtr x</sp=
an><span style=3D"color:#660">,</span><span style=3D"color:#000"> y</span><=
span style=3D"color:#660">,</span><span style=3D"color:#000"> z</span><span=
 style=3D"color:#660">;</span><span style=3D"color:#000"><br></span><span s=
tyle=3D"color:#660">}</span></font></div></code></div><br>=C2=A0</div></div=
></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a2bf173f-047b-4ee5-90c4-a7caf18d6e31%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a2bf173f-047b-4ee5-90c4-a7caf18d6e31=
%40isocpp.org</a>.<br />

------=_Part_2480_296648726.1491322270775--

------=_Part_2479_1844717950.1491322270775--

.

------=_Part_9231_1300341547.1491326500981
Content-Type: multipart/alternative;
 boundary="----=_Part_9232_1399973627.1491326500981"

------=_Part_9232_1399973627.1491326500981
Content-Type: text/plain; charset=UTF-8

On Tuesday, April 4, 2017 at 12:11:10 PM UTC-4, hun.nem...@gmail.com wrote:
>
> The "int* a" coding style mostly comes with a "declare one variable per
> line" rule to avoid the following cases: "int* a, b"
> This solution breaks that rule
>

You said you wanted to declare them all on one line to avoid repeating the
type.  This does that.  You can't say on one hand "I want to declare all
the variables on one line to avoid repeating the type" and then on the
other hand "you can't do that because it breaks the rule of declaring only
one variable per line".  If you were going to only declare one variable per
line, then there would be no need for your proposal.

and also introduce an other identifier just to declare some variables.
> There isn't a clean way to declare multiple pointer or reference in one
> line. There are two competing method and both are bad in some way.
>
And this dual style itself cause bugs, debates and errors. That is the
> reason behind this proposal.
>

Yes, and "this proposal" of introducing another syntax for declaring
variables is also "bad in some way" as has been pointed out several times.
 The other suggested proposals in this thread can be done today.  Probably
the best one is the one that just adds `Type<>` around the `int *`.

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

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

<div dir=3D"ltr">On Tuesday, April 4, 2017 at 12:11:10 PM UTC-4, hun.nem...=
@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>The &quot;int* a&quot; coding style mostly comes with a &quot;decl=
are one variable per line&quot; rule to avoid the following cases: &quot;in=
t* a, b&quot;</div><div>This solution breaks that rule</div></div></blockqu=
ote><div><br></div><div>You said you wanted to declare them all on one line=
 to avoid repeating the type. =C2=A0This does that. =C2=A0You can&#39;t say=
 on one hand &quot;I want to declare all the variables on one line to avoid=
 repeating the type&quot; and then on the other hand &quot;you can&#39;t do=
 that because it breaks the rule of declaring only one variable per line&qu=
ot;. =C2=A0If you were going to only declare one variable per line, then th=
ere would be no need for your proposal.</div><div><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div> and also introduce an =
other identifier just to declare some variables.</div><div>There isn&#39;t =
a clean way to declare multiple pointer or reference in one line. There are=
 two competing method and both are bad in some way.=C2=A0</div></div></bloc=
kquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>A=
nd this dual style itself cause bugs, debates and errors. That is the reaso=
n behind this proposal.</div></div></blockquote><div><br></div><div>Yes, an=
d &quot;this proposal&quot; of introducing another syntax for declaring var=
iables is also &quot;bad in some way&quot; as has been pointed out several =
times. =C2=A0The other suggested proposals in this thread can be done today=
.. =C2=A0Probably the best one is the one that just adds `Type&lt;&gt;` arou=
nd the `int *`.</div><div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d26e61f9-4503-4762-a2b9-6ddc1e7b2a3e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d26e61f9-4503-4762-a2b9-6ddc1e7b2a3e=
%40isocpp.org</a>.<br />

------=_Part_9232_1399973627.1491326500981--

------=_Part_9231_1300341547.1491326500981--

.

------=_Part_2769_1589266585.1491329079559
Content-Type: multipart/alternative;
 boundary="----=_Part_2770_1290843354.1491329079559"

------=_Part_2770_1290843354.1491329079559
Content-Type: text/plain; charset=UTF-8



On Tuesday, April 4, 2017 at 7:21:41 PM UTC+2, Greg Marr wrote:
>
> On Tuesday, April 4, 2017 at 12:11:10 PM UTC-4, hun.nem...@gmail.com
> wrote:
>>
>> The "int* a" coding style mostly comes with a "declare one variable per
>> line" rule to avoid the following cases: "int* a, b"
>> This solution breaks that rule
>>
>
> You said you wanted to declare them all on one line to avoid repeating the
> type.  This does that.  You can't say on one hand "I want to declare all
> the variables on one line to avoid repeating the type" and then on the
> other hand "you can't do that because it breaks the rule of declaring only
> one variable per line".  If you were going to only declare one variable per
> line, then there would be no need for your proposal.
>
It is not just me. This is not my problem. I know the two solution. And I
understand why developers choose one or other method. Developers want
declare variables in a common form easily. They want declare multiple
variable or members in one line. They don't want to think on helper
identifiers just to declare variables and members. This is the reason for
the "int *a, *b;" style. On the other hand this style is confusing as the
type is separated. There is a main part and a pointer or reference part. So
there is an other style which keeps the type together. This is the "int* a;
int* b;" style. They have to declare every variable in new line in other
words they have to repeat the type part always.
So there is no good solution. Your idea is to declare a common short name
for every reference or pointer type is just uncomfortable.



>
> and also introduce an other identifier just to declare some variables.
>> There isn't a clean way to declare multiple pointer or reference in one
>> line. There are two competing method and both are bad in some way.
>>
> And this dual style itself cause bugs, debates and errors. That is the
>> reason behind this proposal.
>>
>
> Yes, and "this proposal" of introducing another syntax for declaring
> variables is also "bad in some way" as has been pointed out several times.
>  The other suggested proposals in this thread can be done today.  Probably
> the best one is the one that just adds `Type<>` around the `int *`.
>
> The current situation is that there is no good choice so we have two half
solution. My proposal is to create a good one and deprecate the two half
solution.
I can imagine that force using the Type<> template usage for every variable
declaration will slow down the compilation and I am not sure it will break
the binary compatibility or not. I think we need a dedicated language
feature for straightforward variable declaration. But I will play with this
idea.


Peter

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

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

<div dir=3D"ltr"><br><br>On Tuesday, April 4, 2017 at 7:21:41 PM UTC+2, Gre=
g Marr wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
On Tuesday, April 4, 2017 at 12:11:10 PM UTC-4, <a>hun.nem...@gmail.com</a>=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>The &q=
uot;int* a&quot; coding style mostly comes with a &quot;declare one variabl=
e per line&quot; rule to avoid the following cases: &quot;int* a, b&quot;</=
div><div>This solution breaks that rule</div></div></blockquote><div><br></=
div><div>You said you wanted to declare them all on one line to avoid repea=
ting the type. =C2=A0This does that. =C2=A0You can&#39;t say on one hand &q=
uot;I want to declare all the variables on one line to avoid repeating the =
type&quot; and then on the other hand &quot;you can&#39;t do that because i=
t breaks the rule of declaring only one variable per line&quot;. =C2=A0If y=
ou were going to only declare one variable per line, then there would be no=
 need for your proposal.</div></div></blockquote><div>It is not just me. Th=
is is not my problem. I know the two solution. And I understand why develop=
ers choose one or other method. Developers want declare variables in a comm=
on form easily. They want declare multiple variable or members in one line.=
 They don&#39;t want to think on helper identifiers just to declare variabl=
es and members. This is the reason for the &quot;int *a, *b;&quot; style. O=
n the other hand this style is confusing as the type is separated. There is=
 a main part and a pointer or reference part. So there is an other style wh=
ich keeps the type together. This is the &quot;int* a; int* b;&quot; style.=
 They have to declare every variable in new line in other words they have t=
o repeat the type part always.<br></div><div>So there is no good solution. =
Your idea is to declare a common short name for every reference or pointer =
type is just uncomfortable.</div><div><br></div><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div> and also introduce a=
n other identifier just to declare some variables.</div><div>There isn&#39;=
t a clean way to declare multiple pointer or reference in one line. There a=
re two competing method and both are bad in some way.=C2=A0</div></div></bl=
ockquote><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>And =
this dual style itself cause bugs, debates and errors. That is the reason b=
ehind this proposal.</div></div></blockquote><div><br></div><div>Yes, and &=
quot;this proposal&quot; of introducing another syntax for declaring variab=
les is also &quot;bad in some way&quot; as has been pointed out several tim=
es. =C2=A0The other suggested proposals in this thread can be done today. =
=C2=A0Probably the best one is the one that just adds `Type&lt;&gt;` around=
 the `int *`.</div><div><br></div></div></blockquote><div>The current situa=
tion is that there is no good choice so we have two half solution. My propo=
sal is to create a good one and deprecate the two half solution.=C2=A0</div=
><div>I can imagine that force using the Type&lt;&gt; template usage for ev=
ery variable declaration will slow down the compilation and I am not sure i=
t will break the binary compatibility or not. I think we need a dedicated l=
anguage feature for straightforward variable declaration. But I will play w=
ith this idea.</div><div><br></div><div><br></div><div>Peter=C2=A0</div></d=
iv>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c3647444-d0e4-4aa6-b53b-e00e91bee70f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c3647444-d0e4-4aa6-b53b-e00e91bee70f=
%40isocpp.org</a>.<br />

------=_Part_2770_1290843354.1491329079559--

------=_Part_2769_1589266585.1491329079559--

.

------=_Part_11851_1066927688.1491330944051
Content-Type: multipart/alternative;
 boundary="----=_Part_11852_156963880.1491330944052"

------=_Part_11852_156963880.1491330944052
Content-Type: text/plain; charset=UTF-8

On Tuesday, April 4, 2017 at 2:04:39 PM UTC-4, hun.nem...@gmail.com wrote:
>
> On Tuesday, April 4, 2017 at 7:21:41 PM UTC+2, Greg Marr wrote:
>>
>> On Tuesday, April 4, 2017 at 12:11:10 PM UTC-4, hun.nem...@gmail.com
>> wrote:
>>>
>>> The "int* a" coding style mostly comes with a "declare one variable per
>>> line" rule to avoid the following cases: "int* a, b"
>>> This solution breaks that rule
>>>
>>
>> You said you wanted to declare them all on one line to avoid repeating
>> the type.  This does that.  You can't say on one hand "I want to declare
>> all the variables on one line to avoid repeating the type" and then on the
>> other hand "you can't do that because it breaks the rule of declaring only
>> one variable per line".  If you were going to only declare one variable per
>> line, then there would be no need for your proposal.
>>
> It is not just me. This is not my problem. I know the two solution. And I
> understand why developers choose one or other method. Developers want
> declare variables in a common form easily. They want declare multiple
> variable or members in one line. They don't want to think on helper
> identifiers just to declare variables and members. This is the reason for
> the "int *a, *b;" style. On the other hand this style is confusing as the
> type is separated. There is a main part and a pointer or reference part. So
> there is an other style which keeps the type together. This is the "int* a;
> int* b;" style. They have to declare every variable in new line in other
> words they have to repeat the type part always.
> So there is no good solution. Your idea is to declare a common short name
> for every reference or pointer type is just uncomfortable.
>

So let me make sure I have this right. You want to change the C++ language,
deprecating literally *every existing C++ program*, all so that things are
a little more "comfortable" for you. Not because the language is broken.
Not because the language is lacking in some genuinely useful feature. But
simply because the solution to your problem that currently exists is not
entirely ideal.

We are not going to deprecate basic syntax of a 30+ year old language
simply because it's *slightly inconvenient*. You have a PEBKAC problem, so
solve it BKAC.

The problem you cite is not a problem of *significance*. C++'s variable
declaration syntax barely rises to the level of an *annoyance*. An
annoyance that has a slightly verbose but perfectly adequate *solution*.

All you have to do is tell people that, if they're going to declare
multiple pointer/reference variables on a single line, they must use the
`Type<>` template. There: problem between keyboard and chair solved.

We should add language features so that people are better able to solve
problems. Not because they can't be bothered to follow a convention or
because you have some merge conflicts due to spaces.

and also introduce an other identifier just to declare some variables.
>>> There isn't a clean way to declare multiple pointer or reference in one
>>> line. There are two competing method and both are bad in some way.
>>>
>> And this dual style itself cause bugs, debates and errors. That is the
>>> reason behind this proposal.
>>>
>>
>> Yes, and "this proposal" of introducing another syntax for declaring
>> variables is also "bad in some way" as has been pointed out several times.
>>  The other suggested proposals in this thread can be done today.  Probably
>> the best one is the one that just adds `Type<>` around the `int *`.
>>
>> The current situation is that there is no good choice so we have two half
> solution. My proposal is to create a good one and deprecate the two half
> solution.
> I can imagine that force using the Type<> template usage for every
> variable declaration will slow down the compilation
>

Why would you force every variable declaration to use a tool that is only
necessary for multiple variable declarations of pointer/reference types?

and I am not sure it will break the binary compatibility or not.
>

`Type<T>` is an alias. It is exactly identical to `T`. It cannot break
compatibility with anything, any more than `using Alias = int; Alias i;`
breaks compatibility with `int i;`.


> I think we need a dedicated language feature for straightforward variable
> declaration.
>

No, we don't. C and C++ have managed to survive for decades without them.

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

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

<div dir=3D"ltr">On Tuesday, April 4, 2017 at 2:04:39 PM UTC-4, hun.nem...@=
gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">On Tuesday, April 4, 2017 at 7:21:41 PM UTC+2, Greg Marr wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Tuesday, April 4, 2017 a=
t 12:11:10 PM UTC-4, <a>hun.nem...@gmail.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"><div dir=3D"ltr"><div>The &quot;int* a&quot; coding sty=
le mostly comes with a &quot;declare one variable per line&quot; rule to av=
oid the following cases: &quot;int* a, b&quot;</div><div>This solution brea=
ks that rule</div></div></blockquote><div><br></div><div>You said you wante=
d to declare them all on one line to avoid repeating the type. =C2=A0This d=
oes that. =C2=A0You can&#39;t say on one hand &quot;I want to declare all t=
he variables on one line to avoid repeating the type&quot; and then on the =
other hand &quot;you can&#39;t do that because it breaks the rule of declar=
ing only one variable per line&quot;. =C2=A0If you were going to only decla=
re one variable per line, then there would be no need for your proposal.</d=
iv></div></blockquote><div>It is not just me. This is not my problem. I kno=
w the two solution. And I understand why developers choose one or other met=
hod. Developers want declare variables in a common form easily. They want d=
eclare multiple variable or members in one line. They don&#39;t want to thi=
nk on helper identifiers just to declare variables and members. This is the=
 reason for the &quot;int *a, *b;&quot; style. On the other hand this style=
 is confusing as the type is separated. There is a main part and a pointer =
or reference part. So there is an other style which keeps the type together=
.. This is the &quot;int* a; int* b;&quot; style. They have to declare every=
 variable in new line in other words they have to repeat the type part alwa=
ys.<br></div><div>So there is no good solution. Your idea is to declare a c=
ommon short name for every reference or pointer type is just uncomfortable.=
</div></div></blockquote><div><br>So let me make sure I have this right. Yo=
u want to change the C++ language, deprecating literally <i>every existing =
C++ program</i>, all so that things are a little more &quot;comfortable&quo=
t; for you. Not because the language is broken. Not because the language is=
 lacking in some genuinely useful feature. But simply because the solution =
to your problem that currently exists is not entirely ideal.<br><br>We are =
not going to deprecate basic syntax of a 30+ year old language simply becau=
se it&#39;s <i>slightly inconvenient</i>. You have a PEBKAC problem, so sol=
ve it BKAC.<br><br>The problem you cite is not a problem of <i>significance=
</i>. C++&#39;s variable declaration syntax barely rises to the level of an=
 <i>annoyance</i>. An annoyance that has a slightly verbose but perfectly a=
dequate <i>solution</i>.<br><br>All you have to do is tell people that, if =
they&#39;re going to declare multiple pointer/reference variables on a sing=
le line, they must use the `Type&lt;&gt;` template. There: problem between =
keyboard and chair solved.<br><br>We should add language features so that p=
eople are better able to solve problems. Not because they can&#39;t be both=
ered to follow a convention or because you have some merge conflicts due to=
 spaces.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=
 and also introduce an other identifier just to declare some variables.</di=
v><div>There isn&#39;t a clean way to declare multiple pointer or reference=
 in one line. There are two competing method and both are bad in some way.=
=C2=A0</div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div>And this dual style itself cause bugs, debates and errors=
.. That is the reason behind this proposal.</div></div></blockquote><div><br=
></div><div>Yes, and &quot;this proposal&quot; of introducing another synta=
x for declaring variables is also &quot;bad in some way&quot; as has been p=
ointed out several times. =C2=A0The other suggested proposals in this threa=
d can be done today. =C2=A0Probably the best one is the one that just adds =
`Type&lt;&gt;` around the `int *`.</div><div><br></div></div></blockquote><=
div>The current situation is that there is no good choice so we have two ha=
lf solution. My proposal is to create a good one and deprecate the two half=
 solution.</div><div>I can imagine that force using the Type&lt;&gt; templa=
te usage for every variable declaration will slow down the compilation</div=
></div></blockquote><div><br>Why would you force every variable declaration=
 to use a tool that is only necessary for multiple variable declarations of=
 pointer/reference types?<br><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr"><div>and I am not sure it will break the binary c=
ompatibility or not.</div></div></blockquote><div><br>`Type&lt;T&gt;` is an=
 alias. It is exactly identical to `T`. It cannot break compatibility with =
anything, any more than `using Alias =3D int; Alias i;` breaks compatibilit=
y with `int i;`.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div dir=3D"ltr"><div>I think we need a dedicated language feature for st=
raightforward variable declaration.</div></div></blockquote><div><br>No, we=
 don&#39;t. C and C++ have managed to survive for decades without them. <br=
></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/80562e07-905a-4a47-b661-8caeb43c85bd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/80562e07-905a-4a47-b661-8caeb43c85bd=
%40isocpp.org</a>.<br />

------=_Part_11852_156963880.1491330944052--

------=_Part_11851_1066927688.1491330944051--

.

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

On Tue, Apr 4, 2017 at 8:04 PM <hun.nemethpeter@gmail.com> wrote:

>
> and also introduce an other identifier just to declare some variables.
> There isn't a clean way to declare multiple pointer or reference in one
> line. There are two competing method and both are bad in some way.
>
> And this dual style itself cause bugs, debates and errors. That is the
> reason behind this proposal.
>
>
> Yes, and "this proposal" of introducing another syntax for declaring
> variables is also "bad in some way" as has been pointed out several times.
> The other suggested proposals in this thread can be done today.  Probably
> the best one is the one that just adds `Type<>` around the `int *`.
>
> The current situation is that there is no good choice so we have two half
> solution. My proposal is to create a good one and deprecate the two half
> solution.
>

You keep thinking this is possible. It'll be better for everyone's
(including yours!) time management and sanity if you just trust us on how
deprecation (1) is impossible and (2) even if it wasn't impossible, would
never proceed to actual removal of the feature from the language.

As others have pointed out before: just because it's deprecated *will not* make
people convert their codebases into this new syntax.

(And that assumes it ever gets past a plenary vote in WG21. Or *to* a
plenary vote in WG21.)


> I can imagine that force using the Type<> template usage for every
> variable declaration will slow down the compilation and I am not sure it
> will break the binary compatibility or not. I think we need a dedicated
> language feature for straightforward variable declaration. But I will play
> with this idea.
>
>
> Peter
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c3647444-d0e4-4aa6-b53b-e00e91bee70f%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c3647444-d0e4-4aa6-b53b-e00e91bee70f%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

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

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

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue=
, Apr 4, 2017 at 8:04 PM &lt;<a href=3D"mailto:hun.nemethpeter@gmail.com">h=
un.nemethpeter@gmail.com</a>&gt; wrote:</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr" class=3D"gmail_msg"><blockquote class=3D"gmail_quote gmai=
l_msg" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr" class=3D"gmail_msg"><div class=3D"gmail_msg">=
<br class=3D"gmail_msg"></div><blockquote class=3D"gmail_quote gmail_msg" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr" class=3D"gmail_msg"><div class=3D"gmail_msg"> and als=
o introduce an other identifier just to declare some variables.</div><div c=
lass=3D"gmail_msg">There isn&#39;t a clean way to declare multiple pointer =
or reference in one line. There are two competing method and both are bad i=
n some way.=C2=A0</div></div></blockquote><blockquote class=3D"gmail_quote =
gmail_msg" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr" class=3D"gmail_msg"><div class=3D"gmail_m=
sg">And this dual style itself cause bugs, debates and errors. That is the =
reason behind this proposal.</div></div></blockquote><div class=3D"gmail_ms=
g"><br class=3D"gmail_msg"></div><div class=3D"gmail_msg">Yes, and &quot;th=
is proposal&quot; of introducing another syntax for declaring variables is =
also &quot;bad in some way&quot; as has been pointed out several times.=C2=
=A0 The other suggested proposals in this thread can be done today.=C2=A0 P=
robably the best one is the one that just adds `Type&lt;&gt;` around the `i=
nt *`.</div><div class=3D"gmail_msg"><br class=3D"gmail_msg"></div></div></=
blockquote></div><div dir=3D"ltr" class=3D"gmail_msg"><div class=3D"gmail_m=
sg">The current situation is that there is no good choice so we have two ha=
lf solution. My proposal is to create a good one and deprecate the two half=
 solution.=C2=A0</div></div></blockquote><div><br></div><div>You keep think=
ing this is possible. It&#39;ll be better for everyone&#39;s (including you=
rs!) time management and sanity if you just trust us on how deprecation (1)=
 is impossible and (2) even if it wasn&#39;t impossible, would never procee=
d to actual removal of the feature from the language.</div><div><br></div><=
div>As others have pointed out before: just because it&#39;s deprecated <i>=
will not</i>=C2=A0make people convert their codebases into this new syntax.=
</div><div><br></div><div>(And that assumes it ever gets past a plenary vot=
e in WG21. Or <i>to</i>=C2=A0a plenary vote in WG21.)</div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr" class=3D"gmail_msg"><div c=
lass=3D"gmail_msg">I can imagine that force using the Type&lt;&gt; template=
 usage for every variable declaration will slow down the compilation and I =
am not sure it will break the binary compatibility or not. I think we need =
a dedicated language feature for straightforward variable declaration. But =
I will play with this idea.</div><div class=3D"gmail_msg"><br class=3D"gmai=
l_msg"></div><div class=3D"gmail_msg"><br class=3D"gmail_msg"></div><div cl=
ass=3D"gmail_msg">Peter=C2=A0</div></div>

<p class=3D"gmail_msg"></p>

-- <br class=3D"gmail_msg">
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br class=3D"gmail_msg=
">
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" class=3D"gm=
ail_msg" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br cla=
ss=3D"gmail_msg">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"gmail_msg" target=3D"_blank">std-proposals@isocpp.org</a>.<b=
r class=3D"gmail_msg">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c3647444-d0e4-4aa6-b53b-e00e91bee70f%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" class=3D"gmail_msg=
" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-prop=
osals/c3647444-d0e4-4aa6-b53b-e00e91bee70f%40isocpp.org</a>.<br class=3D"gm=
ail_msg">
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdTqKhs9Yq7HY-qGoUqJqtjrketCj4oP=
C7XqU_%2Bs0UeYHg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdTqKhs9Yq=
7HY-qGoUqJqtjrketCj4oPC7XqU_%2Bs0UeYHg%40mail.gmail.com</a>.<br />

--001a114017a0dceabd054c5b7843--

.

------=_Part_9440_1032655119.1491331301555
Content-Type: multipart/alternative;
 boundary="----=_Part_9441_2072131890.1491331301555"

------=_Part_9441_2072131890.1491331301555
Content-Type: text/plain; charset=UTF-8

On Tuesday, April 4, 2017 at 2:04:39 PM UTC-4, hun.nem...@gmail.com wrote:
>
> It is not just me. This is not my problem.
>

But... it *is* your problem.

On this thread, I count 15 separate responders to your suggestion. More
than half of them question the motivation for the feature and/or the
cost/benefit of it. And not one of them has been supportive of it.

Granted, 16 people is not a great sample size, but I don't think it's too
far of a stretch to say that it is just you.

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

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

<div dir=3D"ltr">On Tuesday, April 4, 2017 at 2:04:39 PM UTC-4, hun.nem...@=
gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div>It is not just me. This is not my problem.</div></div></blockquote>=
<div><br>But... it <i>is</i> your problem.<br><br>On this thread, I count 1=
5 separate responders to your suggestion. More than half of them question t=
he motivation for the feature and/or the cost/benefit of it. And not one of=
 them has been supportive of it.<br></div><br>Granted, 16 people is not a g=
reat sample size, but I don&#39;t think it&#39;s too far of a stretch to sa=
y that it is just you.<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d4594e04-2ff0-4d74-bb2a-e80585f0c00c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d4594e04-2ff0-4d74-bb2a-e80585f0c00c=
%40isocpp.org</a>.<br />

------=_Part_9441_2072131890.1491331301555--

------=_Part_9440_1032655119.1491331301555--

.

------=_Part_2424_916980868.1491333698559
Content-Type: multipart/alternative;
 boundary="----=_Part_2425_1154189102.1491333698559"

------=_Part_2425_1154189102.1491333698559
Content-Type: text/plain; charset=UTF-8


>
>
>
> So let me make sure I have this right. You want to change the C++
> language, deprecating literally *every existing C++ program*, all so that
> things are a little more "comfortable" for you. Not because the language is
> broken. Not because the language is lacking in some genuinely useful
> feature. But simply because the solution to your problem that currently
> exists is not entirely ideal.
>
> We are not going to deprecate basic syntax of a 30+ year old language
> simply because it's *slightly inconvenient*. You have a PEBKAC problem,
> so solve it BKAC.
>
> The problem you cite is not a problem of *significance*. C++'s variable
> declaration syntax barely rises to the level of an *annoyance*. An
> annoyance that has a slightly verbose but perfectly adequate *solution*.
>
> All you have to do is tell people that, if they're going to declare
> multiple pointer/reference variables on a single line, they must use the
> `Type<>` template. There: problem between keyboard and chair solved.
>
> We should add language features so that people are better able to solve
> problems. Not because they can't be bothered to follow a convention or
> because you have some merge conflicts due to spaces.
>
The current syntax is cause duality in coding style and both dominant
coding style is weak in some way. This is a 30+ years weakness which should
be fixed. It is not a valuable feature of the language. It is an annoying
and confusing part of the language.It was inherited from the C. I think
every newer language just solved this problem.
The "int *a, *b;" syntax just stupid. The type was split in for no good
reason. The only benefit of this syntax is to allow multiple pointer
declaration.
The current dual style situation is just bad and cause constant confusing.
But I agree if somebody just using one syntax all the time this problem
doesn't exist for him.
I think we should test the mass using of a Type<> template before we accept
it as a real solution.
If the Type<> template is really a usable solution then we should deprecate
the old "int *a, *b" style as it is just confusing and cause code
fragmentation.


>
> and also introduce an other identifier just to declare some variables.
>>>> There isn't a clean way to declare multiple pointer or reference in one
>>>> line. There are two competing method and both are bad in some way.
>>>>
>>> And this dual style itself cause bugs, debates and errors. That is the
>>>> reason behind this proposal.
>>>>
>>>
>>> Yes, and "this proposal" of introducing another syntax for declaring
>>> variables is also "bad in some way" as has been pointed out several times.
>>>  The other suggested proposals in this thread can be done today.  Probably
>>> the best one is the one that just adds `Type<>` around the `int *`.
>>>
>>> The current situation is that there is no good choice so we have two
>> half solution. My proposal is to create a good one and deprecate the two
>> half solution.
>> I can imagine that force using the Type<> template usage for every
>> variable declaration will slow down the compilation
>>
>
> Why would you force every variable declaration to use a tool that is only
> necessary for multiple variable declarations of pointer/reference types?
>
For simplicity and to avoid errors. The code lines are changing in time so
adding a new variable shouldn't cause time wasting.
Consider

int *a;


A developer adds a new variable
int* a, b;

Boom, he wasted a compiling cycle.


>
> and I am not sure it will break the binary compatibility or not.
>>
>
> `Type<T>` is an alias. It is exactly identical to `T`. It cannot break
> compatibility with anything, any more than `using Alias = int; Alias i;`
> breaks compatibility with `int i;`.
>
If this really true, then my only proposal is to deprecate the "int *a,
*b;" style variable declaration as it cause errors. But it is hard to
deprecate just that part. Developers accidentally can write it and they
won't get compiler warning for it.


>
>
>> I think we need a dedicated language feature for straightforward variable
>> declaration.
>>
>
> No, we don't. C and C++ have managed to survive for decades without them.
>
Surviving doesn't mean not changing. Surviving means adopting. Little
syntax refreshing will keep it just alive.
Even the C language deprecated the old style function declartion syntax:

And what? Nothing happened. I remember the patches in gcc that just removed
it from the code base and that is all.

// this was a valid syntax

void
error(message,a1,a2,a3,a4,a5,a6,a7)
        char *message;
        char *a1,*a2,*a3,*a4,*a5,*a6,*a7;{
  fprintf(stderr,message,a1,a2,a3,a4,a5,a6,a7);}




Peter

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

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

<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><div><br>=
So let me make sure I have this right. You want to change the C++ language,=
 deprecating literally <i>every existing C++ program</i>, all so that thing=
s are a little more &quot;comfortable&quot; for you. Not because the langua=
ge is broken. Not because the language is lacking in some genuinely useful =
feature. But simply because the solution to your problem that currently exi=
sts is not entirely ideal.<br><br>We are not going to deprecate basic synta=
x of a 30+ year old language simply because it&#39;s <i>slightly inconvenie=
nt</i>. You have a PEBKAC problem, so solve it BKAC.<br><br>The problem you=
 cite is not a problem of <i>significance</i>. C++&#39;s variable declarati=
on syntax barely rises to the level of an <i>annoyance</i>. An annoyance th=
at has a slightly verbose but perfectly adequate <i>solution</i>.<br><br>Al=
l you have to do is tell people that, if they&#39;re going to declare multi=
ple pointer/reference variables on a single line, they must use the `Type&l=
t;&gt;` template. There: problem between keyboard and chair solved.<br><br>=
We should add language features so that people are better able to solve pro=
blems. Not because they can&#39;t be bothered to follow a convention or bec=
ause you have some merge conflicts due to spaces.<br></div></div></blockquo=
te><div>The current syntax is cause duality in coding style and both domina=
nt coding style is weak in some way. This is a 30+ years weakness which sho=
uld be fixed. It is not a valuable feature of the language. It is an annoyi=
ng and confusing part of the language.It was inherited from the C. I think =
every newer language just solved this problem.</div><div>The &quot;int *a, =
*b;&quot; syntax just stupid. The type was split in for no good reason. The=
 only benefit of this syntax is to allow multiple pointer declaration.</div=
><div>The current dual style situation is just bad and cause constant confu=
sing. But I agree if somebody just using one syntax all the time this probl=
em doesn&#39;t exist for him.</div><div>I think we should test the mass usi=
ng of a Type&lt;&gt; template before we accept it as a real solution.</div>=
<div>If the Type&lt;&gt; template is really a usable solution then we shoul=
d deprecate the old &quot;int *a, *b&quot; style as it is just confusing an=
d cause code fragmentation.</div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr"><div><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div> and also introduce an other identifier just to de=
clare some variables.</div><div>There isn&#39;t a clean way to declare mult=
iple pointer or reference in one line. There are two competing method and b=
oth are bad in some way.=C2=A0</div></div></blockquote><blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div>And this dual style itself cause =
bugs, debates and errors. That is the reason behind this proposal.</div></d=
iv></blockquote><div><br></div><div>Yes, and &quot;this proposal&quot; of i=
ntroducing another syntax for declaring variables is also &quot;bad in some=
 way&quot; as has been pointed out several times. =C2=A0The other suggested=
 proposals in this thread can be done today. =C2=A0Probably the best one is=
 the one that just adds `Type&lt;&gt;` around the `int *`.</div><div><br></=
div></div></blockquote><div>The current situation is that there is no good =
choice so we have two half solution. My proposal is to create a good one an=
d deprecate the two half solution.</div><div>I can imagine that force using=
 the Type&lt;&gt; template usage for every variable declaration will slow d=
own the compilation</div></div></blockquote><div><br>Why would you force ev=
ery variable declaration to use a tool that is only necessary for multiple =
variable declarations of pointer/reference types?<br></div></div></blockquo=
te><div>For simplicity and to avoid errors. The code lines are changing in =
time so adding a new variable shouldn&#39;t cause time wasting.</div><div>C=
onsider=C2=A0</div><div><br></div><div class=3D"prettyprint" style=3D"backg=
round-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-s=
tyle: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pret=
typrint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify">a=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></=
code></div><div><br><br></div><div>A developer adds a new variable</div><di=
v class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bord=
er-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-prettify">int</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> a</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> b</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">;</span></div></code></div><div><br></div><div>Boom, he =
wasted a compiling cycle.<br></div><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr"><div>and I am not sure it will break th=
e binary compatibility or not.</div></div></blockquote><div><br>`Type&lt;T&=
gt;` is an alias. It is exactly identical to `T`. It cannot break compatibi=
lity with anything, any more than `using Alias =3D int; Alias i;` breaks co=
mpatibility with `int i;`.<br></div></div></blockquote><div>If this really =
true, then my only proposal is to deprecate the &quot;int *a, *b;&quot; sty=
le variable declaration as it cause errors. But it is hard to deprecate jus=
t that part. Developers accidentally can write it and they won&#39;t get co=
mpiler warning for it.<br></div><div>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"><div>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div>I think we need a dedicated languag=
e feature for straightforward variable declaration.</div></div></blockquote=
><div><br>No, we don&#39;t. C and C++ have managed to survive for decades w=
ithout them. <br></div></div></blockquote><div>Surviving doesn&#39;t mean n=
ot changing. Surviving means adopting. Little syntax refreshing will keep i=
t just alive.</div><div>Even the C language deprecated the old style functi=
on declartion syntax:</div><div><br></div><div>And what? Nothing happened. =
I remember the patches in gcc that just removed it from the code base and t=
hat is all.</div><div><pre class=3D"lang-c prettyprint prettyprinted" style=
=3D"padding: 5px; width: auto; max-height: 600px; overflow: auto; font-fami=
ly: Consolas, Menlo, Monaco, &quot;Lucida Console&quot;, &quot;Liberation M=
ono&quot;, &quot;DejaVu Sans Mono&quot;, &quot;Bitstream Vera Sans Mono&quo=
t;, &quot;Courier New&quot;, monospace, sans-serif; background-color: rgb(2=
39, 240, 241); color: rgb(57, 51, 24); word-wrap: normal;"><code style=3D"f=
ont-family: Consolas, Menlo, Monaco, &quot;Lucida Console&quot;, &quot;Libe=
ration Mono&quot;, &quot;DejaVu Sans Mono&quot;, &quot;Bitstream Vera Sans =
Mono&quot;, &quot;Courier New&quot;, monospace, sans-serif; white-space: in=
herit;"><span class=3D"kwd" style=3D"color: rgb(16, 16, 148);">// this was =
a valid syntax</span></code></pre><pre class=3D"lang-c prettyprint prettypr=
inted" style=3D"padding: 5px; width: auto; max-height: 600px; overflow: aut=
o; font-family: Consolas, Menlo, Monaco, &quot;Lucida Console&quot;, &quot;=
Liberation Mono&quot;, &quot;DejaVu Sans Mono&quot;, &quot;Bitstream Vera S=
ans Mono&quot;, &quot;Courier New&quot;, monospace, sans-serif; background-=
color: rgb(239, 240, 241); color: rgb(57, 51, 24); word-wrap: normal;"><cod=
e style=3D"font-family: Consolas, Menlo, Monaco, &quot;Lucida Console&quot;=
, &quot;Liberation Mono&quot;, &quot;DejaVu Sans Mono&quot;, &quot;Bitstrea=
m Vera Sans Mono&quot;, &quot;Courier New&quot;, monospace, sans-serif; whi=
te-space: inherit;"><span class=3D"kwd" style=3D"color: rgb(16, 16, 148);">=
void</span><span class=3D"pln" style=3D"color: rgb(48, 51, 54);">
error</span><span class=3D"pun" style=3D"color: rgb(48, 51, 54);">(</span><=
span class=3D"pln" style=3D"color: rgb(48, 51, 54);">message</span><span cl=
ass=3D"pun" style=3D"color: rgb(48, 51, 54);">,</span><span class=3D"pln" s=
tyle=3D"color: rgb(48, 51, 54);">a1</span><span class=3D"pun" style=3D"colo=
r: rgb(48, 51, 54);">,</span><span class=3D"pln" style=3D"color: rgb(48, 51=
, 54);">a2</span><span class=3D"pun" style=3D"color: rgb(48, 51, 54);">,</s=
pan><span class=3D"pln" style=3D"color: rgb(48, 51, 54);">a3</span><span cl=
ass=3D"pun" style=3D"color: rgb(48, 51, 54);">,</span><span class=3D"pln" s=
tyle=3D"color: rgb(48, 51, 54);">a4</span><span class=3D"pun" style=3D"colo=
r: rgb(48, 51, 54);">,</span><span class=3D"pln" style=3D"color: rgb(48, 51=
, 54);">a5</span><span class=3D"pun" style=3D"color: rgb(48, 51, 54);">,</s=
pan><span class=3D"pln" style=3D"color: rgb(48, 51, 54);">a6</span><span cl=
ass=3D"pun" style=3D"color: rgb(48, 51, 54);">,</span><span class=3D"pln" s=
tyle=3D"color: rgb(48, 51, 54);">a7</span><span class=3D"pun" style=3D"colo=
r: rgb(48, 51, 54);">)</span><span class=3D"pln" style=3D"color: rgb(48, 51=
, 54);">
        </span><span class=3D"kwd" style=3D"color: rgb(16, 16, 148);">char<=
/span><span class=3D"pln" style=3D"color: rgb(48, 51, 54);"> </span><span c=
lass=3D"pun" style=3D"color: rgb(48, 51, 54);">*</span><span class=3D"pln" =
style=3D"color: rgb(48, 51, 54);">message</span><span class=3D"pun" style=
=3D"color: rgb(48, 51, 54);">;</span><span class=3D"pln" style=3D"color: rg=
b(48, 51, 54);">
        </span><span class=3D"kwd" style=3D"color: rgb(16, 16, 148);">char<=
/span><span class=3D"pln" style=3D"color: rgb(48, 51, 54);"> </span><span c=
lass=3D"pun" style=3D"color: rgb(48, 51, 54);">*</span><span class=3D"pln" =
style=3D"color: rgb(48, 51, 54);">a1</span><span class=3D"pun" style=3D"col=
or: rgb(48, 51, 54);">,*</span><span class=3D"pln" style=3D"color: rgb(48, =
51, 54);">a2</span><span class=3D"pun" style=3D"color: rgb(48, 51, 54);">,*=
</span><span class=3D"pln" style=3D"color: rgb(48, 51, 54);">a3</span><span=
 class=3D"pun" style=3D"color: rgb(48, 51, 54);">,*</span><span class=3D"pl=
n" style=3D"color: rgb(48, 51, 54);">a4</span><span class=3D"pun" style=3D"=
color: rgb(48, 51, 54);">,*</span><span class=3D"pln" style=3D"color: rgb(4=
8, 51, 54);">a5</span><span class=3D"pun" style=3D"color: rgb(48, 51, 54);"=
>,*</span><span class=3D"pln" style=3D"color: rgb(48, 51, 54);">a6</span><s=
pan class=3D"pun" style=3D"color: rgb(48, 51, 54);">,*</span><span class=3D=
"pln" style=3D"color: rgb(48, 51, 54);">a7</span><span class=3D"pun" style=
=3D"color: rgb(48, 51, 54);">;</span><span class=3D"pln" style=3D"color: rg=
b(48, 51, 54);">
</span><span class=3D"pun" style=3D"color: rgb(48, 51, 54);">{</span><span =
class=3D"pln" style=3D"color: rgb(48, 51, 54);">
  fprintf</span><span class=3D"pun" style=3D"color: rgb(48, 51, 54);">(</sp=
an><span class=3D"pln" style=3D"color: rgb(48, 51, 54);">stderr</span><span=
 class=3D"pun" style=3D"color: rgb(48, 51, 54);">,</span><span class=3D"pln=
" style=3D"color: rgb(48, 51, 54);">message</span><span class=3D"pun" style=
=3D"color: rgb(48, 51, 54);">,</span><span class=3D"pln" style=3D"color: rg=
b(48, 51, 54);">a1</span><span class=3D"pun" style=3D"color: rgb(48, 51, 54=
);">,</span><span class=3D"pln" style=3D"color: rgb(48, 51, 54);">a2</span>=
<span class=3D"pun" style=3D"color: rgb(48, 51, 54);">,</span><span class=
=3D"pln" style=3D"color: rgb(48, 51, 54);">a3</span><span class=3D"pun" sty=
le=3D"color: rgb(48, 51, 54);">,</span><span class=3D"pln" style=3D"color: =
rgb(48, 51, 54);">a4</span><span class=3D"pun" style=3D"color: rgb(48, 51, =
54);">,</span><span class=3D"pln" style=3D"color: rgb(48, 51, 54);">a5</spa=
n><span class=3D"pun" style=3D"color: rgb(48, 51, 54);">,</span><span class=
=3D"pln" style=3D"color: rgb(48, 51, 54);">a6</span><span class=3D"pun" sty=
le=3D"color: rgb(48, 51, 54);">,</span><span class=3D"pln" style=3D"color: =
rgb(48, 51, 54);">a7</span><span class=3D"pun" style=3D"color: rgb(48, 51, =
54);">);</span><span class=3D"pln" style=3D"color: rgb(48, 51, 54);">
</span><span class=3D"pun" style=3D"color: rgb(48, 51, 54);">}</span></code=
></pre></div><div><br></div><div><br></div><div><br></div><div>Peter=C2=A0<=
/div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e8c176bc-e408-48d6-8cd5-9e7dc63e9abc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e8c176bc-e408-48d6-8cd5-9e7dc63e9abc=
%40isocpp.org</a>.<br />

------=_Part_2425_1154189102.1491333698559--

------=_Part_2424_916980868.1491333698559--

.

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

On Mon, Apr 3, 2017 at 1:53 PM, <hun.nemethpeter@gmail.com> wrote:

>
>> Why is "coding style fragmentation" such a big issue?
>>
>
> I describe this thing as a merge conflict generator. And I saw so many
> wasted hours where a developer rewrite a code part from one style to
> another. And I took part in so many debate around coding styles.
> What I found is that the main reason for the variable declaration coding
> style fragmentation is the inherent weakness of the current syntax.
> Developers wants clear view from a type and want to declare more then one
> in a line. Separating type parts are confusing and writing every
> declaration to a new line is an ugly solution.
> Currently there is no good solution. Ok, I saw in this thread a template
> trick that is interesting.
> The result is two concurrent coding style and I think it worth eliminating
> it by a new syntax.
>
>
>
>>
>> Since your company doesn't have a unified coding style, just follow the
>> existing style of whatever file you're editing. And pick your own preferred
>> style when adding a new source file. This is what everyone else does.
>>
>>
> This is the current status quo.
>

It sounds like it's *not* the *status quo* at your company. If it were,
then you wouldn't have merge conflicts, because two people who are editing
the same file should both follow the existing coding style *in that file*.

In fact, you admitted:

> I saw so many wasted hours where a developer rewrite a code part from one
> style to another


That's the real problem right there: that your company has developers who
care more about rewriting source files *to suit their own preference* than
about actually doing productive work.

If I have a strong irrational dislike for multiple return statements in a
function, should we deprecate that too? How is that any different from what
you're proposing?


>
>
> Peter
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/eb985b84-9bc9-4656-
> 9dac-a6ac14303fc1%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/eb985b84-9bc9-4656-9dac-a6ac14303fc1%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>



--
*Brian Bi*

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

--001a113ac2761eb10e054c5c5356
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 M=
on, Apr 3, 2017 at 1:53 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:hun.ne=
methpeter@gmail.com" target=3D"_blank">hun.nemethpeter@gmail.com</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><span class=3D"gmail-"><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div><br></div>Why =
is &quot;coding style fragmentation&quot; such a big issue?<br></div></div>=
</div></blockquote><div><br></div></span><div>I describe this thing as a me=
rge conflict generator. And I saw so many wasted hours where a developer re=
write a code part from one style to another. And I took part in so many deb=
ate around coding styles.</div><div>What I found is that the main reason fo=
r the variable declaration coding style fragmentation is the inherent weakn=
ess of the current syntax.</div><div>Developers wants clear view from a typ=
e and want to declare more then one in a line. Separating type parts are co=
nfusing and writing every declaration to a new line is an ugly solution.</d=
iv><div>Currently there is no good solution. Ok, I saw in this thread a tem=
plate trick that is interesting.</div><div>The result is two concurrent cod=
ing style and I think it worth eliminating it by a new syntax.</div><span c=
lass=3D"gmail-"><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><br=
></div><div class=3D"gmail_quote">Since your company doesn&#39;t have a uni=
fied coding style, just follow the existing style of whatever file you&#39;=
re editing. And pick your own preferred style when adding a new source file=
.. This is what everyone else does.<br></div><div class=3D"gmail_quote"><div=
>=C2=A0</div></div></div></div></blockquote></span><div>This is the current=
 status quo.</div></div></blockquote><div><br></div><div>It sounds like it&=
#39;s <b>not</b> the <i>status quo</i> at your company. If it were, then yo=
u wouldn&#39;t have merge conflicts, because two people who are editing the=
 same file should both follow the existing coding style <i>in that file</i>=
..<br><br></div><div>In fact, you admitted:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex">I saw so many wasted hours where a developer rewrite a=
 code part from one style to another</blockquote><div><br></div><div>That&#=
39;s the real problem right there: that your company has developers who car=
e more about rewriting source files <i>to suit their own preference</i> tha=
n about actually doing productive work.<br><br></div><div>If I have a stron=
g irrational dislike for multiple return statements in a function, should w=
e deprecate that too? How is that any different from what you&#39;re propos=
ing?<br></div></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div dir=3D"ltr"><div><br></div><div><br></div><div>Peter=C2=A0=
</div></div><span class=3D"gmail-">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/eb985b84-9bc9-4656-9dac-a6ac14303fc1%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/eb98=
5b84-9bc9-4656-<wbr>9dac-a6ac14303fc1%40isocpp.org</a><wbr>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature"><div dir=3D"ltr"><div><div dir=3D"ltr"><font color=3D"#c0c0c0"><i>B=
rian Bi</i></font><br><div></div><div></div><div></div></div></div></div></=
div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAMmfjbMLhUwmn3EC_Mm-mnj_oW_RJUGw2SCb=
%2B7gC%2BEsLbuDzKw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMmfjbMLhUwm=
n3EC_Mm-mnj_oW_RJUGw2SCb%2B7gC%2BEsLbuDzKw%40mail.gmail.com</a>.<br />

--001a113ac2761eb10e054c5c5356--

.

------=_Part_2377_1761799189.1491334567111
Content-Type: multipart/alternative;
 boundary="----=_Part_2378_37408059.1491334567111"

------=_Part_2378_37408059.1491334567111
Content-Type: text/plain; charset=UTF-8


>
>
>>> The current situation is that there is no good choice so we have two
>> half solution. My proposal is to create a good one and deprecate the two
>> half solution.
>>
>
> You keep thinking this is possible. It'll be better for everyone's
> (including yours!) time management and sanity if you just trust us on how
> deprecation (1) is impossible and (2) even if it wasn't impossible, would
> never proceed to actual removal of the feature from the language.
>
> As others have pointed out before: just because it's deprecated *will not* make
> people convert their codebases into this new syntax.
>
> (And that assumes it ever gets past a plenary vote in WG21. Or *to* a
> plenary vote in WG21.)
>

I described a proposal for a language weakness.This language weakness cause
coding fragmentation and continuous debates. I hope we can came up we with
a good solution.

Yes, this is not the biggest problem, we shouldn't hurry we have enough
time to talk about it. I accept that this will be a slow process. But we
shouldn't bother the slowness if the direction is good.

I hope we can eliminate the "int* a" vs. "int *a" duality from the language
in one way or another.


Peter

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

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

<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div class=3D=
"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div></div></blockquo=
te></div><div dir=3D"ltr"><div>The current situation is that there is no go=
od choice so we have two half solution. My proposal is to create a good one=
 and deprecate the two half solution.=C2=A0</div></div></blockquote><div><b=
r></div><div>You keep thinking this is possible. It&#39;ll be better for ev=
eryone&#39;s (including yours!) time management and sanity if you just trus=
t us on how deprecation (1) is impossible and (2) even if it wasn&#39;t imp=
ossible, would never proceed to actual removal of the feature from the lang=
uage.</div><div><br></div><div>As others have pointed out before: just beca=
use it&#39;s deprecated <i>will not</i>=C2=A0make people convert their code=
bases into this new syntax.</div><div><br></div><div>(And that assumes it e=
ver gets past a plenary vote in WG21. Or <i>to</i>=C2=A0a plenary vote in W=
G21.)</div></div></div></blockquote><div><br></div><div>I described a propo=
sal for a language weakness.This language weakness cause coding fragmentati=
on and continuous debates. I hope we can came up we with a good solution.</=
div><div><br></div><div>Yes, this is not the biggest problem, we shouldn&#3=
9;t hurry we have enough time to talk about it. I accept that this will be =
a slow process. But we shouldn&#39;t bother the slowness if the direction i=
s good.</div><div><br></div><div>I hope we can eliminate the &quot;int* a&q=
uot; vs. &quot;int *a&quot; duality from the language in one way or another=
..</div><div><br></div><div><br></div><div>Peter=C2=A0</div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/78dd8d28-3433-41e2-b57c-d561e03c4d03%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/78dd8d28-3433-41e2-b57c-d561e03c4d03=
%40isocpp.org</a>.<br />

------=_Part_2378_37408059.1491334567111--

------=_Part_2377_1761799189.1491334567111--

.

------=_Part_1033_1769722834.1491335020784
Content-Type: multipart/alternative;
 boundary="----=_Part_1034_1402901653.1491335020785"

------=_Part_1034_1402901653.1491335020785
Content-Type: text/plain; charset=UTF-8



On Tuesday, April 4, 2017 at 8:41:41 PM UTC+2, Nicol Bolas wrote:
>
> On Tuesday, April 4, 2017 at 2:04:39 PM UTC-4, hun.nem...@gmail.com wrote:
>>
>> It is not just me. This is not my problem.
>>
>
> But... it *is* your problem.
>
> On this thread, I count 15 separate responders to your suggestion. More
> than half of them question the motivation for the feature and/or the
> cost/benefit of it. And not one of them has been supportive of it.
>
> Granted, 16 people is not a great sample size, but I don't think it's too
> far of a stretch to say that it is just you.
>

There was a topic recently on a forum and we agreed there that this syntax
just weak. I came here with a solution to this problem.I think counting the
initial responders opinions is not cover the full picture.
I think I am able to brings supporters for this topic but I don't want to.
The problem is real. I can accept a better solution also.

Peter

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

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

<div dir=3D"ltr"><br><br>On Tuesday, April 4, 2017 at 8:41:41 PM UTC+2, Nic=
ol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
">On Tuesday, April 4, 2017 at 2:04:39 PM UTC-4, <a>hun.nem...@gmail.com</a=
> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>It is=
 not just me. This is not my problem.</div></div></blockquote><div><br>But.=
... it <i>is</i> your problem.<br><br>On this thread, I count 15 separate re=
sponders to your suggestion. More than half of them question the motivation=
 for the feature and/or the cost/benefit of it. And not one of them has bee=
n supportive of it.<br></div><br>Granted, 16 people is not a great sample s=
ize, but I don&#39;t think it&#39;s too far of a stretch to say that it is =
just you.<br></div></blockquote><div><br></div><div>There was a topic recen=
tly on a forum and we agreed there that this syntax just weak. I came here =
with a solution to this problem.I think counting the initial responders opi=
nions is not cover the full picture.</div><div>I think I am able to brings =
supporters for this topic but I don&#39;t want to. The problem is real. I c=
an accept a better solution also.</div><div><br></div><div>Peter=C2=A0</div=
></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/91929ad9-2150-4d65-b758-525267e6b44f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/91929ad9-2150-4d65-b758-525267e6b44f=
%40isocpp.org</a>.<br />

------=_Part_1034_1402901653.1491335020785--

------=_Part_1033_1769722834.1491335020784--

.

------=_Part_9740_156509910.1491335921783
Content-Type: multipart/alternative;
 boundary="----=_Part_9741_2088784362.1491335921783"

------=_Part_9741_2088784362.1491335921783
Content-Type: text/plain; charset=UTF-8

Honestly, this proposal has no chance. I'm just trying to save you wasting
you time.
Good luck with the next idea though. Don't give up completely.

On Wednesday, April 5, 2017 at 7:43:40 AM UTC+12, hun.nem...@gmail.com
wrote:

>
>
> On Tuesday, April 4, 2017 at 8:41:41 PM UTC+2, Nicol Bolas wrote:
>>
>> On Tuesday, April 4, 2017 at 2:04:39 PM UTC-4, hun.nem...@gmail.com
>> wrote:
>>>
>>> It is not just me. This is not my problem.
>>>
>>
>> But... it *is* your problem.
>>
>> On this thread, I count 15 separate responders to your suggestion. More
>> than half of them question the motivation for the feature and/or the
>> cost/benefit of it. And not one of them has been supportive of it.
>>
>> Granted, 16 people is not a great sample size, but I don't think it's too
>> far of a stretch to say that it is just you.
>>
>
> There was a topic recently on a forum and we agreed there that this syntax
> just weak. I came here with a solution to this problem.I think counting the
> initial responders opinions is not cover the full picture.
> I think I am able to brings supporters for this topic but I don't want to.
> The problem is real. I can accept a better solution also.
>
> Peter
>

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

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

<div dir=3D"ltr"><div>Honestly, this proposal has no chance. I&#39;m just t=
rying to save you wasting you time.</div><div>Good luck with the next idea =
though. Don&#39;t give up completely.</div><div><br>On Wednesday, April 5, =
2017 at 7:43:40 AM UTC+12, hun.nem...@gmail.com wrote:</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; b=
order-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-s=
tyle: solid;"><div dir=3D"ltr"><br><br>On Tuesday, April 4, 2017 at 8:41:41=
 PM UTC+2, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204,=
 204); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">=
On Tuesday, April 4, 2017 at 2:04:39 PM UTC-4, <a>hun.nem...@gmail.com</a> =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex;=
 padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-widt=
h: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>It is not just me.=
 This is not my problem.</div></div></blockquote><div><br>But... it <i>is</=
i> your problem.<br><br>On this thread, I count 15 separate responders to y=
our suggestion. More than half of them question the motivation for the feat=
ure and/or the cost/benefit of it. And not one of them has been supportive =
of it.<br></div><br>Granted, 16 people is not a great sample size, but I do=
n&#39;t think it&#39;s too far of a stretch to say that it is just you.<br>=
</div></blockquote><div><br></div><div>There was a topic recently on a foru=
m and we agreed there that this syntax just weak. I came here with a soluti=
on to this problem.I think counting the initial responders opinions is not =
cover the full picture.</div><div>I think I am able to brings supporters fo=
r this topic but I don&#39;t want to. The problem is real. I can accept a b=
etter solution also.</div><div><br></div><div>Peter=C2=A0</div></div></bloc=
kquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d63dd098-19a1-4faf-bef3-e928d39865ab%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d63dd098-19a1-4faf-bef3-e928d39865ab=
%40isocpp.org</a>.<br />

------=_Part_9741_2088784362.1491335921783--

------=_Part_9740_156509910.1491335921783--

.

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

On Tue, Apr 4, 2017, 9:36 PM <hun.nemethpeter@gmail.com> wrote:

>
> The current situation is that there is no good choice so we have two half
> solution. My proposal is to create a good one and deprecate the two half
> solution.
>
>
> You keep thinking this is possible. It'll be better for everyone's
> (including yours!) time management and sanity if you just trust us on how
> deprecation (1) is impossible and (2) even if it wasn't impossible, would
> never proceed to actual removal of the feature from the language.
>
> As others have pointed out before: just because it's deprecated *will not* make
> people convert their codebases into this new syntax.
>
> (And that assumes it ever gets past a plenary vote in WG21. Or *to* a
> plenary vote in WG21.)
>
>
> I described a proposal for a language weakness.This language weakness
> cause coding fragmentation and continuous debates. I hope we can came up we
> with a good solution.
>
> Yes, this is not the biggest problem, we shouldn't hurry we have enough
> time to talk about it. I accept that this will be a slow process. But we
> shouldn't bother the slowness if the direction is good.
>

This is not about "slowness" - I don't care how long this takes not to be
accepted (and I guarantee you this never even reaches plenary.)

You assert on this being a good direction. It's not. If you disagree,
please write a paper and come to EWG, though if you do I hope Ville cuts
the discussion down to presentation and a "do we even eant to ever talk
about this" up-down vote.


> I hope we can eliminate the "int* a" vs. "int *a" duality from the
> language in one way or another.
>

This "argument" is just noise, since it's trivial to unify this across a
codebase with say clang-format.


>
> Peter
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/78dd8d28-3433-41e2-b57c-d561e03c4d03%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/78dd8d28-3433-41e2-b57c-d561e03c4d03%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

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

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

<br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Apr 4, 2017, 9:=
36 PM  &lt;<a href=3D"mailto:hun.nemethpeter@gmail.com">hun.nemethpeter@gma=
il.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote c=
lass=3D"gmail_quote gmail_msg" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr" class=3D"gmail_msg"><=
div class=3D"gmail_quote gmail_msg"><blockquote class=3D"gmail_quote gmail_=
msg" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr" class=3D"gmail_msg"><blockquote class=3D"gmail_quote gma=
il_msg" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr" class=3D"gmail_msg"><div class=3D"gmail_msg"=
><br class=3D"gmail_msg"></div></div></blockquote></div><div dir=3D"ltr" cl=
ass=3D"gmail_msg"><div class=3D"gmail_msg">The current situation is that th=
ere is no good choice so we have two half solution. My proposal is to creat=
e a good one and deprecate the two half solution.=C2=A0</div></div></blockq=
uote><div class=3D"gmail_msg"><br class=3D"gmail_msg"></div><div class=3D"g=
mail_msg">You keep thinking this is possible. It&#39;ll be better for every=
one&#39;s (including yours!) time management and sanity if you just trust u=
s on how deprecation (1) is impossible and (2) even if it wasn&#39;t imposs=
ible, would never proceed to actual removal of the feature from the languag=
e.</div><div class=3D"gmail_msg"><br class=3D"gmail_msg"></div><div class=
=3D"gmail_msg">As others have pointed out before: just because it&#39;s dep=
recated <i class=3D"gmail_msg">will not</i>=C2=A0make people convert their =
codebases into this new syntax.</div><div class=3D"gmail_msg"><br class=3D"=
gmail_msg"></div><div class=3D"gmail_msg">(And that assumes it ever gets pa=
st a plenary vote in WG21. Or <i class=3D"gmail_msg">to</i>=C2=A0a plenary =
vote in WG21.)</div></div></div></blockquote><div class=3D"gmail_msg"><br c=
lass=3D"gmail_msg"></div><div class=3D"gmail_msg">I described a proposal fo=
r a language weakness.This language weakness cause coding fragmentation and=
 continuous debates. I hope we can came up we with a good solution.</div><d=
iv class=3D"gmail_msg"><br class=3D"gmail_msg"></div><div class=3D"gmail_ms=
g">Yes, this is not the biggest problem, we shouldn&#39;t hurry we have eno=
ugh time to talk about it. I accept that this will be a slow process. But w=
e shouldn&#39;t bother the slowness if the direction is good.</div></blockq=
uote></div><div><br></div><div>This is not about &quot;slowness&quot; - I d=
on&#39;t care how long this takes not to be accepted (and I guarantee you t=
his never even reaches plenary.)</div><div><br></div><div>You assert on thi=
s being a good direction. It&#39;s not. If you disagree, please write a pap=
er and come to EWG, though if you do I hope Ville cuts the discussion down =
to presentation and a &quot;do we even eant to ever talk about this&quot; u=
p-down vote.</div><div><br></div><div class=3D"gmail_quote"><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div class=3D"gmail_msg"><br class=3D"gmail_msg"></div><div=
 class=3D"gmail_msg">I hope we can eliminate the &quot;int* a&quot; vs. &qu=
ot;int *a&quot; duality from the language in one way or another.</div><div =
class=3D"gmail_msg"></div></blockquote></div><div><br></div><div>This &quot=
;argument&quot; is just noise, since it&#39;s trivial to unify this across =
a codebase with say clang-format.=C2=A0</div><div><br></div><div class=3D"g=
mail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_msg"><br cla=
ss=3D"gmail_msg"></div><div class=3D"gmail_msg"><br class=3D"gmail_msg"></d=
iv><div class=3D"gmail_msg">Peter=C2=A0</div>

<p class=3D"gmail_msg"></p>

-- <br class=3D"gmail_msg">
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br class=3D"gmail_msg=
">
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" class=3D"gm=
ail_msg" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br cla=
ss=3D"gmail_msg">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"gmail_msg" target=3D"_blank">std-proposals@isocpp.org</a>.<b=
r class=3D"gmail_msg">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/78dd8d28-3433-41e2-b57c-d561e03c4d03%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" class=3D"gmail_msg=
" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-prop=
osals/78dd8d28-3433-41e2-b57c-d561e03c4d03%40isocpp.org</a>.<br class=3D"gm=
ail_msg">
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdSeWLDHiBa%3DAdH77PcPgvqTsRPrcd=
LFOWa72VsTrvE-hA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdSeWLDHiB=
a%3DAdH77PcPgvqTsRPrcdLFOWa72VsTrvE-hA%40mail.gmail.com</a>.<br />

--001a1140193eced3dd054c5cc6c6--

.

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

On Tuesday, 4 April 2017 20:21:38 UTC+1, hun.nem...@gmail.com  wrote:
>=20
> If this really true, then my only proposal is to deprecate the "int *a, *=
b;" style variable declaration as it cause errors. But it is hard to deprec=
ate just that part. Developers accidentally can write it and they won't get=
 compiler warning for it.
>=20

Actually, why not? If clang and gcc can warn about misleadingly indented if=
/else statements (Wmisleading-indentation) then they should be able to warn=
 about misleading pointer/reference qualifiers in multiple variable declara=
tions. It could be a nice feature request for someone to implement.=20

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/723f7544-c497-425e-b557-c877ed726127%40isocpp.or=
g.

------=_Part_2449_845503605.1491336673565--

.

------=_Part_2736_1365416692.1491336907334
Content-Type: multipart/alternative;
 boundary="----=_Part_2737_535860334.1491336907334"

------=_Part_2737_535860334.1491336907334
Content-Type: text/plain; charset=UTF-8


>
>
> This is not about "slowness" - I don't care how long this takes not to be
> accepted (and I guarantee you this never even reaches plenary.)
>
> You assert on this being a good direction. It's not. If you disagree,
> please write a paper and come to EWG, though if you do I hope Ville cuts
> the discussion down to presentation and a "do we even eant to ever talk
> about this" up-down vote.
>
I think I wrote down the problem and I proposed a solution to it. I can't
do more.


>
>
>> I hope we can eliminate the "int* a" vs. "int *a" duality from the
>> language in one way or another.
>>
>
> This "argument" is just noise, since it's trivial to unify this across a
> codebase with say clang-format.
>
I think this aspect of the language is just annoying. Not a big bug not a
show stopper it is just annoying. Sometimes cause headache for the code
maintainers and developers. I think we can do it better.


Peter

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

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div><br></di=
v><div>This is not about &quot;slowness&quot; - I don&#39;t care how long t=
his takes not to be accepted (and I guarantee you this never even reaches p=
lenary.)</div><div><br></div><div>You assert on this being a good direction=
.. It&#39;s not. If you disagree, please write a paper and come to EWG, thou=
gh if you do I hope Ville cuts the discussion down to presentation and a &q=
uot;do we even eant to ever talk about this&quot; up-down vote.</div></bloc=
kquote><div>I think I wrote down the problem and I proposed a solution to i=
t. I can&#39;t do more.</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div><br></div><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div><br></div><div>I hope we can eliminate the &quot;int* a&=
quot; vs. &quot;int *a&quot; duality from the language in one way or anothe=
r.</div><div></div></blockquote></div><div><br></div><div>This &quot;argume=
nt&quot; is just noise, since it&#39;s trivial to unify this across a codeb=
ase with say clang-format.=C2=A0</div></blockquote><div>I think this aspect=
 of the language is just annoying. Not a big bug not a show stopper it is j=
ust annoying. Sometimes cause headache for the code maintainers and develop=
ers. I think we can do it better.</div><div><br></div><div><br></div><div>P=
eter</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/cdf7e64c-8728-4495-aa0f-9818bec965fd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cdf7e64c-8728-4495-aa0f-9818bec965fd=
%40isocpp.org</a>.<br />

------=_Part_2737_535860334.1491336907334--

------=_Part_2736_1365416692.1491336907334--

.

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

On Tue, Apr 4, 2017, 10:15 PM <hun.nemethpeter@gmail.com> wrote:

>
> This is not about "slowness" - I don't care how long this takes not to be
> accepted (and I guarantee you this never even reaches plenary.)
>
> You assert on this being a good direction. It's not. If you disagree,
> please write a paper and come to EWG, though if you do I hope Ville cuts
> the discussion down to presentation and a "do we even eant to ever talk
> about this" up-down vote.
>
> I think I wrote down the problem and I proposed a solution to it. I can't
> do more.
>

I'm yet to see your paper formally proposed to the committee.


>
>
>
> I hope we can eliminate the "int* a" vs. "int *a" duality from the
> language in one way or another.
>
>
> This "argument" is just noise, since it's trivial to unify this across a
> codebase with say clang-format.
>
> I think this aspect of the language is just annoying. Not a big bug not a
> show stopper it is just annoying. Sometimes cause headache for the code
> maintainers and developers. I think we can do it better.
>
>
> Peter
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cdf7e64c-8728-4495-aa0f-9818bec965fd%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cdf7e64c-8728-4495-aa0f-9818bec965fd%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

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

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

<br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Apr 4, 2017, 10=
:15 PM  &lt;<a href=3D"mailto:hun.nemethpeter@gmail.com">hun.nemethpeter@gm=
ail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr" class=3D"gmail_msg"><blockquote class=3D"gmail_quote gmail_msg" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div class=3D"gmail_msg"><br class=3D"gmail_msg"></div><div class=3D"gmail=
_msg">This is not about &quot;slowness&quot; - I don&#39;t care how long th=
is takes not to be accepted (and I guarantee you this never even reaches pl=
enary.)</div><div class=3D"gmail_msg"><br class=3D"gmail_msg"></div><div cl=
ass=3D"gmail_msg">You assert on this being a good direction. It&#39;s not. =
If you disagree, please write a paper and come to EWG, though if you do I h=
ope Ville cuts the discussion down to presentation and a &quot;do we even e=
ant to ever talk about this&quot; up-down vote.</div></blockquote></div><di=
v dir=3D"ltr" class=3D"gmail_msg"><div class=3D"gmail_msg">I think I wrote =
down the problem and I proposed a solution to it. I can&#39;t do more.</div=
></div></blockquote></div><div><br></div><div>I&#39;m yet to see your paper=
 formally proposed to the committee.</div><div><br></div><div class=3D"gmai=
l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr" class=3D"gmail_msg=
"><div class=3D"gmail_msg">=C2=A0</div><blockquote class=3D"gmail_quote gma=
il_msg" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div class=3D"gmail_msg"><br class=3D"gmail_msg"></div><div c=
lass=3D"gmail_quote gmail_msg"><blockquote class=3D"gmail_quote gmail_msg" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v class=3D"gmail_msg"><br class=3D"gmail_msg"></div><div class=3D"gmail_msg=
">I hope we can eliminate the &quot;int* a&quot; vs. &quot;int *a&quot; dua=
lity from the language in one way or another.</div><div class=3D"gmail_msg"=
></div></blockquote></div><div class=3D"gmail_msg"><br class=3D"gmail_msg">=
</div><div class=3D"gmail_msg">This &quot;argument&quot; is just noise, sin=
ce it&#39;s trivial to unify this across a codebase with say clang-format.=
=C2=A0</div></blockquote></div><div dir=3D"ltr" class=3D"gmail_msg"><div cl=
ass=3D"gmail_msg">I think this aspect of the language is just annoying. Not=
 a big bug not a show stopper it is just annoying. Sometimes cause headache=
 for the code maintainers and developers. I think we can do it better.</div=
><div class=3D"gmail_msg"><br class=3D"gmail_msg"></div><div class=3D"gmail=
_msg"><br class=3D"gmail_msg"></div><div class=3D"gmail_msg">Peter</div></d=
iv>

<p class=3D"gmail_msg"></p>

-- <br class=3D"gmail_msg">
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br class=3D"gmail_msg=
">
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" class=3D"gm=
ail_msg" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br cla=
ss=3D"gmail_msg">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"gmail_msg" target=3D"_blank">std-proposals@isocpp.org</a>.<b=
r class=3D"gmail_msg">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/cdf7e64c-8728-4495-aa0f-9818bec965fd%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" class=3D"gmail_msg=
" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-prop=
osals/cdf7e64c-8728-4495-aa0f-9818bec965fd%40isocpp.org</a>.<br class=3D"gm=
ail_msg">
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdQPTsBYsnz3KMUGj%2BW5pAoPN%3DSh=
5ya0wsMU%2B_gKvLM%3DMA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdQP=
TsBYsnz3KMUGj%2BW5pAoPN%3DSh5ya0wsMU%2B_gKvLM%3DMA%40mail.gmail.com</a>.<br=
 />

--001a1140331ed99527054c5cf3ca--

.

------=_Part_2860_1385350244.1491337117674
Content-Type: multipart/alternative;
 boundary="----=_Part_2861_103084247.1491337117674"

------=_Part_2861_103084247.1491337117674
Content-Type: text/plain; charset=UTF-8



On Tuesday, April 4, 2017 at 10:11:13 PM UTC+2, Edward Catmur wrote:
>
> On Tuesday, 4 April 2017 20:21:38 UTC+1, hun.nem...@gmail.com  wrote:
> >
> > If this really true, then my only proposal is to deprecate the "int *a,
> *b;" style variable declaration as it cause errors. But it is hard to
> deprecate just that part. Developers accidentally can write it and they
> won't get compiler warning for it.
> >
>
> Actually, why not? If clang and gcc can warn about misleadingly indented
> if/else statements (Wmisleading-indentation) then they should be able to
> warn about misleading pointer/reference qualifiers in multiple variable
> declarations. It could be a nice feature request for someone to implement.
>
I think we should just allow only the "type identifier, identifier,...;"
form. This will start reducing the code fragmentation.
We should deprecate/reject/warning for "int *a, *b;" style. If the Type<>
thing is working then we are in a half finished state.

Peter

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4fcbfa7b-f33f-452b-97cf-53847d179826%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Tuesday, April 4, 2017 at 10:11:13 PM UTC+2, Ed=
ward Catmur wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tuesday, =
4 April 2017 20:21:38 UTC+1, <a>hun.nem...@gmail.com</a> =C2=A0wrote:<br>&g=
t; <br>&gt; If this really true, then my only proposal is to deprecate the =
&quot;int *a, *b;&quot; style variable declaration as it cause errors. But =
it is hard to deprecate just that part. Developers accidentally can write i=
t and they won&#39;t get compiler warning for it.<br>&gt; <p>Actually, why =
not? If clang and gcc can warn about misleadingly indented if/else statemen=
ts (Wmisleading-indentation) then they should be able to warn about mislead=
ing pointer/reference qualifiers in multiple variable declarations. It coul=
d be a nice feature request for someone to implement.</p></blockquote><div>=
I think we should just allow only the &quot;type identifier, identifier,...=
;&quot; form. This will start reducing the code fragmentation.<br></div><di=
v>We should deprecate/reject/warning for &quot;int *a, *b;&quot; style. If =
the Type&lt;&gt; thing is working then we are in a half finished state.</di=
v><div><br></div><div>Peter</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4fcbfa7b-f33f-452b-97cf-53847d179826%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4fcbfa7b-f33f-452b-97cf-53847d179826=
%40isocpp.org</a>.<br />

------=_Part_2861_103084247.1491337117674--

------=_Part_2860_1385350244.1491337117674--

.

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

Let's be blunt: which part of "there's no chance in hell this ever passes
EWG, not to even talk about getting voted on by the entire committee" do
you not understand?

Perhaps you'll understand it better if you write an actual proposal and get
rejected by EWG explicitly.

On Tue, Apr 4, 2017, 10:18 PM <hun.nemethpeter@gmail.com> wrote:

>
>
> On Tuesday, April 4, 2017 at 10:11:13 PM UTC+2, Edward Catmur wrote:
>
> On Tuesday, 4 April 2017 20:21:38 UTC+1, hun.nem...@gmail.com  wrote:
> >
> > If this really true, then my only proposal is to deprecate the "int *a,
> *b;" style variable declaration as it cause errors. But it is hard to
> deprecate just that part. Developers accidentally can write it and they
> won't get compiler warning for it.
> >
>
> Actually, why not? If clang and gcc can warn about misleadingly indented
> if/else statements (Wmisleading-indentation) then they should be able to
> warn about misleading pointer/reference qualifiers in multiple variable
> declarations. It could be a nice feature request for someone to implement.
>
> I think we should just allow only the "type identifier, identifier,...;"
> form. This will start reducing the code fragmentation.
> We should deprecate/reject/warning for "int *a, *b;" style. If the Type<>
> thing is working then we are in a half finished state.
>
> Peter
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4fcbfa7b-f33f-452b-97cf-53847d179826%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4fcbfa7b-f33f-452b-97cf-53847d179826%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

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

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

<p dir=3D"ltr">Let&#39;s be blunt: which part of &quot;there&#39;s no chanc=
e in hell this ever passes EWG, not to even talk about getting voted on by =
the entire committee&quot; do you not understand?</p>
<p dir=3D"ltr">Perhaps you&#39;ll understand it better if you write an actu=
al proposal and get rejected by EWG explicitly.</p>
<br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Apr 4, 2017, 10:18 =
PM  &lt;<a href=3D"mailto:hun.nemethpeter@gmail.com">hun.nemethpeter@gmail.=
com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
 class=3D"gmail_msg"><br class=3D"gmail_msg"><br class=3D"gmail_msg">On Tue=
sday, April 4, 2017 at 10:11:13 PM UTC+2, Edward Catmur wrote:<blockquote c=
lass=3D"gmail_quote gmail_msg" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">On Tuesday, 4 April 2017 20:21:38 UTC+=
1, <a class=3D"gmail_msg">hun.nem...@gmail.com</a> =C2=A0wrote:<br class=3D=
"gmail_msg">&gt; <br class=3D"gmail_msg">&gt; If this really true, then my =
only proposal is to deprecate the &quot;int *a, *b;&quot; style variable de=
claration as it cause errors. But it is hard to deprecate just that part. D=
evelopers accidentally can write it and they won&#39;t get compiler warning=
 for it.<br class=3D"gmail_msg">&gt; <p class=3D"gmail_msg">Actually, why n=
ot? If clang and gcc can warn about misleadingly indented if/else statement=
s (Wmisleading-indentation) then they should be able to warn about misleadi=
ng pointer/reference qualifiers in multiple variable declarations. It could=
 be a nice feature request for someone to implement.</p></blockquote></div>=
<div dir=3D"ltr" class=3D"gmail_msg"><div class=3D"gmail_msg">I think we sh=
ould just allow only the &quot;type identifier, identifier,...;&quot; form.=
 This will start reducing the code fragmentation.<br class=3D"gmail_msg"></=
div><div class=3D"gmail_msg">We should deprecate/reject/warning for &quot;i=
nt *a, *b;&quot; style. If the Type&lt;&gt; thing is working then we are in=
 a half finished state.</div><div class=3D"gmail_msg"><br class=3D"gmail_ms=
g"></div><div class=3D"gmail_msg">Peter</div></div>

<p class=3D"gmail_msg"></p>

-- <br class=3D"gmail_msg">
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br class=3D"gmail_msg=
">
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" class=3D"gm=
ail_msg" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br cla=
ss=3D"gmail_msg">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"gmail_msg" target=3D"_blank">std-proposals@isocpp.org</a>.<b=
r class=3D"gmail_msg">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4fcbfa7b-f33f-452b-97cf-53847d179826%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" class=3D"gmail_msg=
" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-prop=
osals/4fcbfa7b-f33f-452b-97cf-53847d179826%40isocpp.org</a>.<br class=3D"gm=
ail_msg">
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdTtLFmxgh7M083OWWETXxy9287m96Ye=
EsSDFJggZNscPg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdTtLFmxgh7M=
083OWWETXxy9287m96YeEsSDFJggZNscPg%40mail.gmail.com</a>.<br />

--94eb2c1abc0205003f054c5d3159--

.

------=_Part_2620_145881722.1491338291972
Content-Type: multipart/alternative;
 boundary="----=_Part_2621_403828231.1491338291973"

------=_Part_2621_403828231.1491338291973
Content-Type: text/plain; charset=UTF-8




> I'm yet to see your paper formally proposed to the committee.
>
>>
>> Do you think I should create a proposal on this topic?

I think the original C style variable declaration is flawed.
int* a, b;
should declare
int* a;
int* b;
but it creates
int* a;
int b;

This semantic is confusing enough so there is a large supporters of the
declare only one variable per line group.

So the current proposal is to deprecate this old style type split
declaration.
We should introduce a helper alias template in global namespace.

template<class T>
using var = T;

so the new style is

int* test()
{
   double x, y, z;
   var<int*> a, b;
   ...
}

struct A
{
   var<Node*> first, last;
   size_t size;
};

I will thinking on this approach...



Peter

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

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

<div dir=3D"ltr"><br><br><blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>=
<br></div><div>I&#39;m yet to see your paper formally proposed to the commi=
ttee.</div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></=
blockquote></div></blockquote><div>Do you think I should create a proposal =
on this topic?</div><div><br></div><div>I think the original C style variab=
le declaration is flawed.</div><div><div class=3D"prettyprint" style=3D"bac=
kground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border=
-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pr=
ettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> b</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span></div></c=
ode></div></div><div>should declare<br></div><div><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;"><co=
de class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color=
: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> a</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>int</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> b</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">;</span></div></code></=
div>but it creates</div><div class=3D"prettyprint" style=3D"background-colo=
r: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: soli=
d; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><=
div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">int</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> a</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> b</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><div><br></div>This s=
emantic is confusing enough so there is a large supporters of the declare o=
nly one variable per line group.<div><br></div><div>So the current proposal=
 is to deprecate this old style type split declaration.</div><div>We should=
 introduce a helper=C2=A0alias template in global namespace.</div><div><div=
><br></div><div></div></div><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"prettyprin=
t"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">template</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">class</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">using</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">var</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span></div></code></div><div><br></div><div>so the new style is</=
div><div><br></div><div><div class=3D"prettyprint" style=3D"background-colo=
r: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: soli=
d; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><=
div class=3D"subprettyprint"><font color=3D"#660066"><span style=3D"color: =
#008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> test</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 =C2=A0</span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
double</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> y</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</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 style=3D"color: #000;" class=3D=
"styled-by-prettify"><br>=C2=A0 =C2=A0</span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">var</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">int</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">*&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> b</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0</span><span s=
tyle=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><br></span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> A<br></span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br>=C2=A0 =C2=A0</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">var</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">&lt;</span><span style=3D"color: #606;" class=3D"styled-by-prett=
ify">Node</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*=
&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> first=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">last</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0size_t size</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">};</span></font></div></code></div><div>=
<br></div>I will thinking on this approach...<br><br></div><div><br></div><=
div><div><br></div><div>Peter=C2=A0</div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ab0efbac-6081-4143-a65c-ec77e20e01e5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ab0efbac-6081-4143-a65c-ec77e20e01e5=
%40isocpp.org</a>.<br />

------=_Part_2621_403828231.1491338291973--

------=_Part_2620_145881722.1491338291972--

.

------=_Part_2891_2042516975.1491338552200
Content-Type: multipart/alternative;
 boundary="----=_Part_2892_547528479.1491338552200"

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



On Tuesday, April 4, 2017 at 10:33:43 PM UTC+2, Micha=C5=82 Dominiak wrote:
>
> Let's be blunt: which part of "there's no chance in hell this ever passes=
=20
> EWG, not to even talk about getting voted on by the entire committee" do=
=20
> you not understand?
>
> Perhaps you'll understand it better if you write an actual proposal and=
=20
> get rejected by EWG explicitly.
>
>>
>>
I have no idea who is who and what the roles are here. I have to use thing=
=20
language and I have to teach it and I have to work with it. This is my job.=
=20
I saw weakness in the language that is why I want to improve it.
The problem is given and I think this is the right forum to move things=20
forward.

Peter=20

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2ab9507a-8982-44f0-8daa-1b5504b5a4f0%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Tuesday, April 4, 2017 at 10:33:43 PM UTC+2, Mi=
cha=C5=82 Dominiak wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p di=
r=3D"ltr">Let&#39;s be blunt: which part of &quot;there&#39;s no chance in =
hell this ever passes EWG, not to even talk about getting voted on by the e=
ntire committee&quot; do you not understand?</p>
<p dir=3D"ltr">Perhaps you&#39;ll understand it better if you write an actu=
al proposal and get rejected by EWG explicitly.</p>
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote>=
</div></blockquote><div><br></div><div>I have no idea who is who and what t=
he roles are here. I have to use thing language and I have to teach it and =
I have to work with it. This is my job. I saw weakness in the language that=
 is why I want to improve it.</div><div>The problem is given and I think th=
is is the right forum to move things forward.</div><div><br></div><div>Pete=
r=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2ab9507a-8982-44f0-8daa-1b5504b5a4f0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2ab9507a-8982-44f0-8daa-1b5504b5a4f0=
%40isocpp.org</a>.<br />

------=_Part_2892_547528479.1491338552200--

------=_Part_2891_2042516975.1491338552200--

.

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

There's literally an entire section of the isocpp.org website dedicated to
the process. https://isocpp.org/std.

One would think you'd check that out before posting on isocpp's forums
related to that particular process.

On Tue, Apr 4, 2017 at 10:42 PM <hun.nemethpeter@gmail.com> wrote:

>
>
> On Tuesday, April 4, 2017 at 10:33:43 PM UTC+2, Micha=C5=82 Dominiak wrot=
e:
>
> Let's be blunt: which part of "there's no chance in hell this ever passes
> EWG, not to even talk about getting voted on by the entire committee" do
> you not understand?
>
> Perhaps you'll understand it better if you write an actual proposal and
> get rejected by EWG explicitly.
>
>
>
> I have no idea who is who and what the roles are here. I have to use thin=
g
> language and I have to teach it and I have to work with it. This is my jo=
b.
> I saw weakness in the language that is why I want to improve it.
> The problem is given and I think this is the right forum to move things
> forward.
>
> Peter
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2ab9507a-898=
2-44f0-8daa-1b5504b5a4f0%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2ab9507a-89=
82-44f0-8daa-1b5504b5a4f0%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

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

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

<div dir=3D"ltr">There&#39;s literally an entire section of the <a href=3D"=
http://isocpp.org">isocpp.org</a> website dedicated to the process.=C2=A0<a=
 href=3D"https://isocpp.org/std">https://isocpp.org/std</a>.<div><br></div>=
<div>One would think you&#39;d check that out before posting on isocpp&#39;=
s forums related to that particular process.</div></div><br><div class=3D"g=
mail_quote"><div dir=3D"ltr">On Tue, Apr 4, 2017 at 10:42 PM &lt;<a href=3D=
"mailto:hun.nemethpeter@gmail.com">hun.nemethpeter@gmail.com</a>&gt; wrote:=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr" class=3D"gmail_ms=
g"><br class=3D"gmail_msg"><br class=3D"gmail_msg">On Tuesday, April 4, 201=
7 at 10:33:43 PM UTC+2, Micha=C5=82 Dominiak wrote:<blockquote class=3D"gma=
il_quote gmail_msg" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><p dir=3D"ltr" class=3D"gmail_msg">Let&#39;s be b=
lunt: which part of &quot;there&#39;s no chance in hell this ever passes EW=
G, not to even talk about getting voted on by the entire committee&quot; do=
 you not understand?</p>
<p dir=3D"ltr" class=3D"gmail_msg">Perhaps you&#39;ll understand it better =
if you write an actual proposal and get rejected by EWG explicitly.</p>
<div class=3D"gmail_quote gmail_msg"><blockquote class=3D"gmail_quote gmail=
_msg" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><br class=3D"gmail_msg"></blockquote></div></blockquote><div class=3D"gm=
ail_msg"><br class=3D"gmail_msg"></div></div><div dir=3D"ltr" class=3D"gmai=
l_msg"><div class=3D"gmail_msg">I have no idea who is who and what the role=
s are here. I have to use thing language and I have to teach it and I have =
to work with it. This is my job. I saw weakness in the language that is why=
 I want to improve it.</div><div class=3D"gmail_msg">The problem is given a=
nd I think this is the right forum to move things forward.</div><div class=
=3D"gmail_msg"><br class=3D"gmail_msg"></div><div class=3D"gmail_msg">Peter=
=C2=A0</div></div>

<p class=3D"gmail_msg"></p>

-- <br class=3D"gmail_msg">
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br class=3D"gmail_msg=
">
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" class=3D"gm=
ail_msg" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br cla=
ss=3D"gmail_msg">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"gmail_msg" target=3D"_blank">std-proposals@isocpp.org</a>.<b=
r class=3D"gmail_msg">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2ab9507a-8982-44f0-8daa-1b5504b5a4f0%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" class=3D"gmail_msg=
" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-prop=
osals/2ab9507a-8982-44f0-8daa-1b5504b5a4f0%40isocpp.org</a>.<br class=3D"gm=
ail_msg">
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdSptn4DtNORRtL4gTR154BzkT69BrQN=
cjK-Snp457xE%2Bw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdSptn4DtN=
ORRtL4gTR154BzkT69BrQNcjK-Snp457xE%2Bw%40mail.gmail.com</a>.<br />

--94eb2c1abc028f0d19054c5d6716--

.

------=_Part_2412_1847746654.1491339464440
Content-Type: multipart/alternative;
 boundary="----=_Part_2413_2011413835.1491339464440"

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



On Tuesday, April 4, 2017 at 10:48:58 PM UTC+2, Micha=C5=82 Dominiak wrote:
>
> There's literally an entire section of the isocpp.org website dedicated=
=20
> to the process. https://isocpp.org/std.
>
> One would think you'd check that out before posting on isocpp's forums=20
> related to that particular process.
>
>>
>> I read it some years ago so this list was in my bookmark. Maybe I should=
=20
post this idea to ISO C++ Standard - Discussion first or something like=20
that.
But I don't want to spend more time with this if this kind of change is=20
impossible.

Peter=20

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/d7a46ce0-8f25-4619-a7af-6e267c1b17eb%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Tuesday, April 4, 2017 at 10:48:58 PM UTC+2, Mi=
cha=C5=82 Dominiak wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr">There&#39;s literally an entire section of the <a href=3D"http:=
//isocpp.org" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fisocpp.org\x26sa\x3dD\x=
26sntz\x3d1\x26usg\x3dAFQjCNHaIcX84r8AUHgx9Q4pR00LZ1llsQ&#39;;return true;"=
 onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fis=
ocpp.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHaIcX84r8AUHgx9Q4pR00LZ1ll=
sQ&#39;;return true;">isocpp.org</a> website dedicated to the process.=C2=
=A0<a href=3D"https://isocpp.org/std" target=3D"_blank" rel=3D"nofollow" on=
mousedown=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2=
Fisocpp.org%2Fstd\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHk1B411tqugQYwD7A=
lC4KH1SCc4g&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.goog=
le.com/url?q\x3dhttps%3A%2F%2Fisocpp.org%2Fstd\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNHk1B411tqugQYwD7AlC4KH1SCc4g&#39;;return true;">https://isocpp.=
org/<wbr>std</a>.<div><br></div><div>One would think you&#39;d check that o=
ut before posting on isocpp&#39;s forums related to that particular process=
..</div></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>=
</blockquote></div></blockquote><div>I read it some years ago so this list =
was in my bookmark. Maybe I should post this idea to ISO C++ Standard - Dis=
cussion first or something like that.</div><div>But I don&#39;t want to spe=
nd more time with this if this kind of change is impossible.</div><div><br>=
</div><div>Peter=C2=A0<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d7a46ce0-8f25-4619-a7af-6e267c1b17eb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d7a46ce0-8f25-4619-a7af-6e267c1b17eb=
%40isocpp.org</a>.<br />

------=_Part_2413_2011413835.1491339464440--

------=_Part_2412_1847746654.1491339464440--

.

------=_Part_7478_1886694799.1491352395997
Content-Type: multipart/alternative;
 boundary="----=_Part_7479_923367.1491352395997"

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

On Tuesday, April 4, 2017 at 4:57:44 PM UTC-4, hun.nem...@gmail.com wrote:
>
> On Tuesday, April 4, 2017 at 10:48:58 PM UTC+2, Micha=C5=82 Dominiak wrot=
e:
>>
>> There's literally an entire section of the isocpp.org website dedicated=
=20
>> to the process. https://isocpp.org/std.
>>
>> One would think you'd check that out before posting on isocpp's forums=
=20
>> related to that particular process.
>>
>>>
>>> I read it some years ago so this list was in my bookmark. Maybe I shoul=
d=20
> post this idea to ISO C++ Standard - Discussion first or something like=
=20
> that.
>

No, that forum is for discussion of the existing standard.  This forum is=
=20
for discussion of proposals for changes, so you found the right forum for=
=20
your discussion. The next step in a change is writing up a formal proposal=
=20
as described on the linked website.  However, as various people have=20
described, this type of change would be unlikely to even be considered.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/9f878f84-6027-474c-a47d-7cedabef56fb%40isocpp.or=
g.

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

<div dir=3D"ltr">On Tuesday, April 4, 2017 at 4:57:44 PM UTC-4, hun.nem...@=
gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">On Tuesday, April 4, 2017 at 10:48:58 PM UTC+2, Micha=C5=82 Dominiak wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">There&#39;s lit=
erally an entire section of the <a href=3D"http://isocpp.org" rel=3D"nofoll=
ow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;http://www.google.com=
/url?q\x3dhttp%3A%2F%2Fisocpp.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
aIcX84r8AUHgx9Q4pR00LZ1llsQ&#39;;return true;" onclick=3D"this.href=3D&#39;=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fisocpp.org\x26sa\x3dD\x26sntz\x=
3d1\x26usg\x3dAFQjCNHaIcX84r8AUHgx9Q4pR00LZ1llsQ&#39;;return true;">isocpp.=
org</a> website dedicated to the process.=C2=A0<a href=3D"https://isocpp.or=
g/std" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;h=
ttps://www.google.com/url?q\x3dhttps%3A%2F%2Fisocpp.org%2Fstd\x26sa\x3dD\x2=
6sntz\x3d1\x26usg\x3dAFQjCNHk1B411tqugQYwD7AlC4KH1SCc4g&#39;;return true;" =
onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fi=
socpp.org%2Fstd\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHk1B411tqugQYwD7AlC=
4KH1SCc4g&#39;;return true;">https://isocpp.org/<wbr>std</a>.<div><br></div=
><div>One would think you&#39;d check that out before posting on isocpp&#39=
;s forums related to that particular process.</div></div><div class=3D"gmai=
l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><br></blockquote></div></blockquote=
><div>I read it some years ago so this list was in my bookmark. Maybe I sho=
uld post this idea to ISO C++ Standard - Discussion first or something like=
 that.</div></div></blockquote><div><br></div><div>No, that forum is for di=
scussion of the existing standard. =C2=A0This forum is for discussion of pr=
oposals for changes, so you found the right forum for your discussion. The =
next step in a change is writing up a formal proposal as described on the l=
inked website. =C2=A0However, as various people have described, this type o=
f change would be unlikely to even be considered.</div><div><br></div></div=
>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9f878f84-6027-474c-a47d-7cedabef56fb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9f878f84-6027-474c-a47d-7cedabef56fb=
%40isocpp.org</a>.<br />

------=_Part_7479_923367.1491352395997--

------=_Part_7478_1886694799.1491352395997--

.

------=_Part_1389_309708122.1491398956213
Content-Type: multipart/alternative;
 boundary="----=_Part_1390_1732530440.1491398956213"

------=_Part_1390_1732530440.1491398956213
Content-Type: text/plain; charset=UTF-8


>
> No, that forum is for discussion of the existing standard.  This forum is
> for discussion of proposals for changes, so you found the right forum for
> your discussion. The next step in a change is writing up a formal proposal
> as described on the linked website.  However, as various people have
> described, this type of change would be unlikely to even be considered.
>
>
As this kind of change is unlikely to even be considered in this form I
won't write a formal proposal.

But I am not sure what part of the problem can be improved in some way.

I think the original C syntax for variable declaration is flawed. It is a
trap for programmers. But changing such a core mechanism is cause extreme
amount of code change.

I accept that a proposal for an extreme amount of code change cause extreme
resistance.

Now we have two competing coding style to resolve this flaw but none of
them is good enough. The two competing half solution cause headache. I
think talking about this problem and proposing some changes at least worth
this topic.


Peter

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b50316aa-9af7-497e-8c51-7ee8c1d4e808%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>No, that forum is for discussion of the existing standard. =C2=A0T=
his forum is for discussion of proposals for changes, so you found the righ=
t forum for your discussion. The next step in a change is writing up a form=
al proposal as described on the linked website. =C2=A0However, as various p=
eople have described, this type of change would be unlikely to even be cons=
idered.</div><div><br></div></div></blockquote><div><br></div><div>As this =
kind of change is unlikely to even be considered in this form I won&#39;t w=
rite a formal proposal.</div><div><br></div><div>But I am not sure what par=
t of the problem can be improved in some way.</div><div><br></div><div>I th=
ink the original C syntax for variable declaration is flawed. It is a trap =
for programmers. But changing such a core mechanism is cause extreme amount=
 of code change.</div><div><br></div><div>I accept that a proposal for an e=
xtreme amount of code change cause extreme resistance.</div><div><br></div>=
<div>Now we have two competing coding style to resolve this flaw but none o=
f them is good enough. The two competing half solution cause headache. I th=
ink talking about this problem and proposing some changes at least worth th=
is topic.</div><div><br></div><div><br></div><div>Peter=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b50316aa-9af7-497e-8c51-7ee8c1d4e808%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b50316aa-9af7-497e-8c51-7ee8c1d4e808=
%40isocpp.org</a>.<br />

------=_Part_1390_1732530440.1491398956213--

------=_Part_1389_309708122.1491398956213--

.