------=_Part_166_698795764.1418582231344
Content-Type: multipart/alternative;
 boundary="----=_Part_167_72340105.1418582231344"

------=_Part_167_72340105.1418582231344
Content-Type: text/plain; charset=UTF-8

So I decided to write a proposal for the committee about this
<https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/1z0uI7LCQAI>.
Take a look at it (an very early draft, just to draw the basis)
<https://docs.google.com/document/d/16Lt2G4Gm_RmT6lwLlBxqT9EtGS8Qdhy4XN6tsspVZ6A/edit>
..

--

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

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

<div dir=3D"ltr">So I decided to write a proposal for the committee about <=
a href=3D"https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposal=
s/1z0uI7LCQAI">this</a>. Take a look at it <a href=3D"https://docs.google.c=
om/document/d/16Lt2G4Gm_RmT6lwLlBxqT9EtGS8Qdhy4XN6tsspVZ6A/edit">(an very e=
arly draft, just to draw the basis)</a>.</div>

<p></p>

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

------=_Part_167_72340105.1418582231344--
------=_Part_166_698795764.1418582231344--

.

On 14 December 2014 at 20:37, sasho648 <sasho648@mail.bg> wrote:
> So I decided to write a proposal for the committee about this. Take a look
> at it (an very early draft, just to draw the basis).

This proposal claims that it will "fix" the vexing parse, but it truly creates
yet-another-way to avoid it, when there's already three other ways
(extra parens,
using names of previously declared variables, using braces).

It makes implementations consider things that currently are expressions
to potentially be declarations, and parse, semantic-analyze and
error-handle accordingly.

It provides no rationale for the

"(auto Tmp1)(Func()), (auto Tmp1)(Func1()); //error, 'Tmp1' is
re-declared within the same control flow"

part nor for the

"A memory will be created for all named variables created in
expressions, even if they won't get initialized."

part. You can currently have different types in a ternary operator if
they have a common type.

The overall motivation and rationale for the proposal seems weak.

I am fairly certain that this proposal will be rejected outright, and
sending it to EWG will
be a waste of time.

--

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

.

I agree with Ville.  If no-one has agreed with you on this forum, what
makes you think you'll fare better with EWG?

On 12/14/14, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> On 14 December 2014 at 20:37, sasho648 <sasho648@mail.bg> wrote:
>> So I decided to write a proposal for the committee about this. Take a
>> look
>> at it (an very early draft, just to draw the basis).
>
> This proposal claims that it will "fix" the vexing parse, but it truly
> creates
> yet-another-way to avoid it, when there's already three other ways
> (extra parens,
> using names of previously declared variables, using braces).
>
> It makes implementations consider things that currently are expressions
> to potentially be declarations, and parse, semantic-analyze and
> error-handle accordingly.
>
> It provides no rationale for the
>
> "(auto Tmp1)(Func()), (auto Tmp1)(Func1()); //error, 'Tmp1' is
> re-declared within the same control flow"
>
> part nor for the
>
> "A memory will be created for all named variables created in
> expressions, even if they won't get initialized."
>
> part. You can currently have different types in a ternary operator if
> they have a common type.
>
> The overall motivation and rationale for the proposal seems weak.
>
> I am fairly certain that this proposal will be rejected outright, and
> sending it to EWG will
> be a waste of time.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

.