------=_Part_4942_13677245.1371024652385
Content-Type: text/plain; charset=ISO-8859-1

Hi,


template <class X> void f() {}
template <> void f<int>() {}
COMPILES


struct S {
    template <class X> void f() {}
    template <> void f<int>() {}
};
--> error: explicit specialization of 'f' in class scope
FUCKING RETARDED
WOW IT REALLY MAKES SENSE THAT THIS WORKS AT GLOBAL SCOPE BUT NOT IN-CLASS


struct S {
    template <class X> struct Inner {};
    template <> struct Inner<int> {};
};
--> error: explicit specialization of 'Inner' in class scope
FUCKING RETARDED


struct S {
    template <class X, class = void> struct Inner {};
    template <class bullshit> struct Inner<int, bullshit> {};
};
WOW, RETARDS, WORKS WITH A STUPID-RETARDED WORKAROUND


struct S {
    template <class X, class=void> void f() {}
    template <class bullshit> void f<int, bullshit>() {}
};
--> function template partial specialization is not allowed
FUCKING RETARDED
WOW THE RETARDED WORKAROUND DOESN'T WORK FOR FUNCTIONS


template <class X> void f(X x) {}
template <class X> void f(X* x) {}
OH, OK THIS GOOD


template <class X, class Y> void f() {}
template <class Y> void f<int, Y>() {}
--> function template partial specialization is not allowed
FUCKING RETARDED.


I don't even want to hear 1 piece of bullshit out of a single one of you
people's mouths about this one.
If you give me one piece of bullshit, you're a fucking n00b.

Every one of these things is used for metaprogramming.

After 15 years of awareness about these problems, nothing was fixed.
And now with C++14, yet another oversight release, we're heading for 20
years of fucking retardation.

Thank you standards body people for your retarded level of awareness, you
fucking retards.
Can you fix the holes you fucking retards?

--

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



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

<div>Hi,</div><div><br></div><div><br></div><div>template &lt;class X&gt; v=
oid f() {}</div><div>template &lt;&gt; void f&lt;int&gt;() {}</div><div>COM=
PILES</div><div><br></div><div><br></div><div>struct S {</div><div>&nbsp; &=
nbsp; template &lt;class X&gt; void f() {}</div><div>&nbsp; &nbsp; template=
 &lt;&gt; void f&lt;int&gt;() {}</div><div>};</div><div>--&gt; error: expli=
cit specialization of 'f' in class scope</div><div>FUCKING RETARDED</div><d=
iv>WOW IT REALLY MAKES SENSE THAT THIS WORKS AT GLOBAL SCOPE BUT NOT IN-CLA=
SS</div><div><br></div><div><br></div><div>struct S {</div><div>&nbsp; &nbs=
p; template &lt;class X&gt; struct Inner {};</div><div>&nbsp; &nbsp; templa=
te &lt;&gt; struct Inner&lt;int&gt; {};</div><div>};</div><div>--&gt; error=
: explicit specialization of 'Inner' in class scope</div><div>FUCKING RETAR=
DED</div><div><br></div><div><br></div><div>struct S {</div><div>&nbsp; &nb=
sp; template &lt;class X, class =3D void&gt; struct Inner {};</div><div>&nb=
sp; &nbsp; template &lt;class bullshit&gt; struct Inner&lt;int, bullshit&gt=
; {};</div><div>};</div><div>WOW, RETARDS, WORKS WITH A STUPID-RETARDED WOR=
KAROUND</div><div><br></div><div><br></div><div>struct S {</div><div>&nbsp;=
 &nbsp; template &lt;class X, class=3Dvoid&gt; void f() {}</div><div>&nbsp;=
 &nbsp; template &lt;class bullshit&gt; void f&lt;int, bullshit&gt;() {}</d=
iv><div>};</div><div>--&gt; function template partial specialization is not=
 allowed</div><div>FUCKING RETARDED</div><div>WOW THE RETARDED WORKAROUND D=
OESN'T WORK FOR FUNCTIONS</div><div><br></div><div><br></div><div>template =
&lt;class X&gt; void f(X x) {}</div><div>template &lt;class X&gt; void f(X*=
 x) {}</div><div>OH, OK THIS GOOD</div><div><br></div><div><br></div><div>t=
emplate &lt;class X, class Y&gt; void f() {}</div><div>template &lt;class Y=
&gt; void f&lt;int, Y&gt;() {}</div><div>--&gt; function template partial s=
pecialization is not allowed</div><div>FUCKING RETARDED.</div><div><br></di=
v><div><br></div><div>I don't even want to hear 1 piece of bullshit out of =
a single one of you people's mouths about this one.</div><div>If you give m=
e one piece of bullshit, you're a fucking n00b.</div><div><br></div><div>Ev=
ery one of these things is used for metaprogramming.</div><div><br></div><d=
iv>After 15 years of awareness about these problems, nothing was fixed.</di=
v><div>And now with C++14, yet another oversight release, we're heading for=
 20 years of fucking retardation.</div><div><br></div><div>Thank you standa=
rds body people for your retarded level of awareness, you fucking retards.<=
br></div><div>Can you fix the holes you fucking retards?</div><div><br></di=
v>

<p></p>

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

------=_Part_4942_13677245.1371024652385--

.

------=_Part_279_1015847.1371026386268
Content-Type: text/plain; charset=ISO-8859-1

I seem to have missed your paper about changing these things.

--

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



------=_Part_279_1015847.1371026386268
Content-Type: text/html; charset=ISO-8859-1

I seem to have missed your paper about changing these things.

<p></p>

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

------=_Part_279_1015847.1371026386268--

.

--001a11c2337acd837004def157b9
Content-Type: text/plain; charset=ISO-8859-1

On 12 June 2013 11:39, DeadMG <wolfeinstein@gmail.com> wrote:

> I seem to have missed your paper about changing these things.
>
>
>
>
Luckily, there have been proposals by sane people to change some of those
things.
Such changes have thus far been of low priority. I don't expect lunatic
raving to have
an improving effect on that.

--

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



--001a11c2337acd837004def157b9
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 12 June 2013 11:39, DeadMG <span dir="ltr">&lt;<a href="mailto:wolfeinstein@gmail.com" target="_blank">wolfeinstein@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I seem to have missed your paper about changing these things.

<div class="HOEnZb"><div class="h5"><p></p>

<br><br></div></div></blockquote><div><br></div><div>Luckily, there have been proposals by sane people to change some of those things.<br></div><div>Such changes have thus far been of low priority. I don&#39;t expect lunatic raving to have<br>
an improving effect on that.<br></div></div></div></div>

<p></p>

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

--001a11c2337acd837004def157b9--

.

------=_Part_4900_16905552.1371028720901
Content-Type: text/plain; charset=ISO-8859-1

VOTE ON IT AND FIX IT YOU FUCKING N00BS

--

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



------=_Part_4900_16905552.1371028720901
Content-Type: text/html; charset=ISO-8859-1

VOTE ON IT AND FIX IT YOU FUCKING N00BS<div><div><br></div></div>

<p></p>

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

------=_Part_4900_16905552.1371028720901--

.

------=_Part_533_30868959.1371031702684
Content-Type: text/plain; charset=ISO-8859-1

BESIDES THE FACT THAT IT'S SO FUCKING RETARDED THAT C++ CAN'T DO **ALL** OF
THIS SHIT,

ONE OF THEM,
IN-CLASS-EXPLICIT-SPECIAL,
*WORKS* ON FUCKING MICROSOFT VISUAL STUDIO
FOR A LONG-ASSED NOW TIME NOW.

SO WE HAVE A BUNCH OF FUCKING INCONSISTENT CODE
BECAUSE PEOPLE USE THE SHIT IN VISUAL STUDIO
AND IT DOESN'T GIVE A SINGLE FUCKING WARNING

AND IT DOESN'T WORK ON GCC OR CLANG

CAN YOU GUYS FUCKING VOTE ON IT AND FIX IT?
DUH?

ARE YOU RETARDED?

--

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



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

BESIDES THE FACT THAT IT'S SO FUCKING RETARDED THAT C++ CAN'T DO **ALL** OF=
 THIS SHIT,<div><div><br></div><div>ONE OF THEM,</div><div>IN-CLASS-EXPLICI=
T-SPECIAL,</div><div>*WORKS* ON FUCKING MICROSOFT VISUAL STUDIO</div><div>F=
OR A LONG-ASSED NOW TIME NOW.</div><div><br></div><div>SO WE HAVE A BUNCH O=
F FUCKING INCONSISTENT CODE</div><div>BECAUSE PEOPLE USE THE SHIT IN VISUAL=
 STUDIO</div><div>AND IT DOESN'T GIVE A SINGLE FUCKING WARNING</div><div><b=
r></div><div>AND IT DOESN'T WORK ON GCC OR CLANG</div><div><br></div><div>C=
AN YOU GUYS FUCKING VOTE ON IT AND FIX IT?<br></div><div>DUH?<br></div><div=
><br></div><div>ARE YOU RETARDED?</div><div><br></div></div>

<p></p>

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

------=_Part_533_30868959.1371031702684--

.

------=_Part_2603_11175423.1371031768482
Content-Type: text/plain; charset=ISO-8859-1

BESIDES THE FACT THAT IT'S SO FUCKING RETARDED THAT C++ CAN'T DO **ALL** OF
THIS SHIT,

ONE OF THEM,
IN-CLASS-EXPLICIT-SPECIAL,
*WORKS* ON FUCKING MICROSOFT VISUAL STUDIO
FOR A LONG-ASSED TIME NOW.

SO WE HAVE A BUNCH OF FUCKING INCONSISTENT CODE
BECAUSE PEOPLE USE THE SHIT IN VISUAL STUDIO
AND IT DOESN'T GIVE A SINGLE FUCKING WARNING

AND IT DOESN'T WORK ON GCC OR CLANG

CAN YOU GUYS FUCKING VOTE ON IT AND FIX IT?
DUH?

ARE YOU RETARDED?

--

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



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

BESIDES THE FACT THAT IT'S SO FUCKING RETARDED THAT C++ CAN'T DO **ALL** OF=
 THIS SHIT,<div><div><br></div><div>ONE OF THEM,</div><div>IN-CLASS-EXPLICI=
T-SPECIAL,</div><div>*WORKS* ON FUCKING MICROSOFT VISUAL STUDIO</div><div>F=
OR A LONG-ASSED TIME NOW.</div><div><br></div><div>SO WE HAVE A BUNCH OF FU=
CKING INCONSISTENT CODE</div><div>BECAUSE PEOPLE USE THE SHIT IN VISUAL STU=
DIO</div><div>AND IT DOESN'T GIVE A SINGLE FUCKING WARNING</div><div><br></=
div><div>AND IT DOESN'T WORK ON GCC OR CLANG</div><div><br></div><div>CAN Y=
OU GUYS FUCKING VOTE ON IT AND FIX IT?<br></div><div>DUH?<br></div><div><br=
></div><div>ARE YOU RETARDED?</div></div><div><br></div>

<p></p>

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

------=_Part_2603_11175423.1371031768482--

.

------=_Part_193_1166776.1371032630697
Content-Type: text/plain; charset=ISO-8859-1

And by the way

Just because I brought up Microsoft

Doesn't mean you can fix fucking 1 of them

You need to fix all of 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_193_1166776.1371032630697
Content-Type: text/html; charset=ISO-8859-1

And by the way<div><br></div><div>Just because I brought up Microsoft</div><div><br></div><div>Doesn't mean you can fix fucking 1 of them</div><div><br></div><div>You need to fix all of them</div><div><br></div>

<p></p>

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

------=_Part_193_1166776.1371032630697--

.

------=_Part_4587_28377131.1371034401993
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, June 12, 2013 11:23:50 AM UTC+1, looseont...@gmail.com wrote:
>
> And by the way
>
> Just because I brought up Microsoft
>
> Doesn't mean you can fix fucking 1 of them
>
> You need to fix all of them
>
>
Got it.  I'll start right away.

Anything else I can do for you, since you asked so nicely?



--

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



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

<br><br>On Wednesday, June 12, 2013 11:23:50 AM UTC+1, looseont...@gmail.co=
m wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">And by the way<div><br=
></div><div>Just because I brought up Microsoft</div><div><br></div><div>Do=
esn't mean you can fix fucking 1 of them</div><div><br></div><div>You need =
to fix all of them</div><div><br></div></blockquote><div><br>Got it.&nbsp; =
I'll start right away.<br><br>Anything else I can do for you, since you ask=
ed so nicely?<br><br>&nbsp;<br></div>

<p></p>

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

------=_Part_4587_28377131.1371034401993--

.

--f46d04463252cbc44f04def2dfd4
Content-Type: text/plain; charset=ISO-8859-1

On 12 June 2013 13:53, Jonathan Wakely <cxx@kayari.org> wrote:

> Got it.  I'll start right away.
>
>
>
Indeed. This was an excellent heads-up. It's not like volunteers were
already working their asses off for
no compensation, spending massive amounts of their waking hours on the
committee work.

We could also, of course, take the things mentioned and put them at the
very end of the queue, just
out of spite, since it seems people don't deserve those to be fixed. Just a
thought.

--

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



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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 12 June 2013 13:53, Jonathan Wakely <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:cxx@kayari.org" target=3D"_blank">cxx@kayari.org</a>&gt;</span>=
 wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Got it.=A0 I&#39;ll start right away.<br><di=
v><br><br></div></blockquote><div><br></div><div>Indeed. This was an excell=
ent heads-up. It&#39;s not like volunteers were already working their asses=
 off for<br>
no compensation, spending massive amounts of their waking hours on the comm=
ittee work. <br></div></div><br></div><div class=3D"gmail_extra">We could a=
lso, of course, take the things mentioned and put them at the very end of t=
he queue, just<br>
out of spite, since it seems people don&#39;t deserve those to be fixed. Ju=
st a thought.<br></div></div>

<p></p>

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

--f46d04463252cbc44f04def2dfd4--

.

------=_Part_2624_24265778.1371034761903
Content-Type: text/plain; charset=ISO-8859-1

YOU WANT ME TO WRITE THE PROPOSAL?
I'M NOT EVEN FUCKING SANE
YOU THINK I KNOW HOW TO WRITE A PROPOSAL
YOU PEOPLE ARE SUPPOSEDLY SANE
AND YOU CAN'T EVEN DO IT

WHY DO YOU HAVE TO WASTE SO MUCH TIME ON THE RETARDED PROPOSALS WITH ALL
THE PRETTY PRINT?
DO YOU THINK I HAVE FUCKING TIME FOR A BUNCH OF FUCKING PRETTY PRINT
WHY DONT YOU READ MY FUCKING POST WHERE I SAID IT'S FUCKING RETARDED AND BE
HAPPY WITH THAT AS THE PROPOSAL
AND THEN WRITE THE GODDAMN STANDARD WORDING TO IT AND USE WHAT I SAID ABOUT
RETARDATION AS THE LITERAL PRESENTATION
YOU DON'T NEED A BUNCH OF FUCKING HIGH-WORDING LITERARY C++ DOCUMENTARIAN
TPS-REPORT MAGIC FOR WEIRD FUCKING FREAK BEARDED MEN WHO ARE GONNA VOTE NO
BECAUSE IT WASNT WORDED RIGHT TO FIGURE THIS SHIT OUT, OK?
WHY YOU THINK C++ IS SO FUCKING SLOW? BECAUSE ALL YOU FUCKING RETARDS NEED
A BUNCH OF FUCKING POWERPOINT DIAGRAMS TO UNDERSTAND ANYTHING
FIX THE GODDAMN WORDING AND THEN JUST DO IT, WHO HAS TIME TO FUCK AROUND
WITH DOCUMENT INDENTATION BULL-CRAP AND A BIG FUCKING PRETEXT WHERE I TRY
TO SOUND ALL NICE AND SANE FOR CRAZY PEOPLE JUST TO MAKE YOU UNDERSTAND THE
CONCEPT
THAT YOU NEED TO FIX THE BASIC FUCKING TEMPLATE FEATURES

--

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



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

<div>YOU WANT ME TO WRITE THE PROPOSAL?</div><div>I'M NOT EVEN FUCKING SANE=
</div><div>YOU THINK I KNOW HOW TO WRITE A PROPOSAL</div><div>YOU PEOPLE AR=
E SUPPOSEDLY SANE</div><div>AND YOU CAN'T EVEN DO IT</div><div><br></div><d=
iv>WHY DO YOU HAVE TO WASTE SO MUCH TIME ON THE RETARDED PROPOSALS WITH ALL=
 THE PRETTY PRINT?</div><div>DO YOU THINK I HAVE FUCKING TIME FOR A BUNCH O=
F FUCKING PRETTY PRINT</div><div>WHY DONT YOU READ MY FUCKING POST WHERE I =
SAID IT'S FUCKING RETARDED AND BE HAPPY WITH THAT AS THE PROPOSAL</div><div=
>AND THEN WRITE THE GODDAMN STANDARD WORDING TO IT AND USE WHAT I SAID ABOU=
T RETARDATION AS THE LITERAL PRESENTATION</div><div>YOU DON'T NEED A BUNCH =
OF FUCKING HIGH-WORDING LITERARY C++ DOCUMENTARIAN TPS-REPORT MAGIC FOR WEI=
RD FUCKING FREAK BEARDED MEN WHO ARE GONNA VOTE NO BECAUSE IT WASNT WORDED =
RIGHT TO FIGURE THIS SHIT OUT, OK?</div><div>WHY YOU THINK C++ IS SO FUCKIN=
G SLOW? BECAUSE ALL YOU FUCKING RETARDS NEED A BUNCH OF FUCKING POWERPOINT =
DIAGRAMS TO UNDERSTAND ANYTHING</div><div>FIX THE GODDAMN WORDING AND THEN =
JUST DO IT, WHO HAS TIME TO FUCK AROUND WITH DOCUMENT INDENTATION BULL-CRAP=
 AND A BIG FUCKING PRETEXT WHERE I TRY TO SOUND ALL NICE AND SANE FOR CRAZY=
 PEOPLE JUST TO MAKE YOU UNDERSTAND THE CONCEPT</div><div>THAT YOU NEED TO =
FIX THE BASIC FUCKING TEMPLATE FEATURES</div><div><br></div>

<p></p>

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

------=_Part_2624_24265778.1371034761903--

.

--20cf3074d676f362d904def36891
Content-Type: text/plain; charset=ISO-8859-1

On 12 June 2013 13:59, <looseonthestreet@gmail.com> wrote:

> YOU WANT ME TO WRITE THE PROPOSAL?
>

No thanks, we're fine without your proposals.



THAT YOU NEED TO FIX THE BASIC FUCKING TEMPLATE FEATURES
>
>
>
Interesting. I knew we had class templates and function templates, and
alias templates (since c++11), and
as of late, variable templates (as of c++14, likely), but I have completely
missed these fucking templates.

--

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



--20cf3074d676f362d904def36891
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 12 June 2013 13:59,  <span dir=3D"ltr">&lt;<a href=3D"mailto:loo=
seonthestreet@gmail.com" target=3D"_blank">looseonthestreet@gmail.com</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>YOU WANT ME TO WRITE THE PROPOSAL?</div=
></blockquote><div><br></div><div>No thanks, we&#39;re fine without your pr=
oposals.<br>
<br><br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div>THAT YOU NEED TO FIX =
THE BASIC FUCKING TEMPLATE FEATURES</div><div class=3D"HOEnZb"><div class=
=3D"h5">
<div><br><br></div></div></div></blockquote><div><br></div><div>Interesting=
.. I knew we had class templates and function templates, and alias templates=
 (since c++11), and<br></div><div>as of late, variable templates (as of c++=
14, likely), but I have completely missed these fucking templates. <br>
</div></div><br></div></div>

<p></p>

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

--20cf3074d676f362d904def36891--

.

------=_Part_291_26614063.1371036976112
Content-Type: text/plain; charset=ISO-8859-1

Oh, yeah. You can instantiate them to fuck a class, a function, or even
some kinds of values.

--

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



------=_Part_291_26614063.1371036976112
Content-Type: text/html; charset=ISO-8859-1

Oh, yeah. You can instantiate them to fuck a class, a function, or even some kinds of values.

<p></p>

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

------=_Part_291_26614063.1371036976112--

.

--14dae9d24e446e803604def432e9
Content-Type: text/plain; charset=ISO-8859-1

Wow, this thread totally beats me.

I always thought, and maybe I still think, that there was something about
being a programmer, and a C++ one more specially, that highly relates with
having very effective comunication skills and focused problem solving
skills applied to comunciation (i.e. don't complain, as it does nothing,
but point and colaborate, etc). After all, a program boils down to a
written expression of intent very carefully crafted out to produce a
precise result. So I find it very very unusual to see a programmer failing
so misserably at comunication something that is intended to have a
specific, positive outcome.

His approach is of a totally unproductive, comunicationally ignorant and
socially broken kind. One that I often see in other "technical" areas, most
notably in physics, where everyone seems to believe is a genious and all
others are retarded, just as in this case.

I know there are lots of forums with equally uneducated programmers, but
IME they are often much, much less "sophisticated" than std-proposals.  So
like I said, I still can't believe I'm really reading this here.



--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

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



--14dae9d24e446e803604def432e9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Wow, this thread totally beats me.<br><br>I always th=
ought, and maybe I still think, that there was something about being a prog=
rammer, and a C++ one more specially, that highly relates with having very =
effective comunication skills and focused problem solving skills applied to=
 comunciation (i.e. don&#39;t complain, as it does nothing, but point and c=
olaborate, etc). After all, a program boils down to a written expression of=
 intent very carefully crafted out to produce a precise result. So I find i=
t very very unusual to see a programmer failing so misserably at comunicati=
on something that is intended to have a specific, positive outcome.<br>

<br>His approach is of a totally unproductive, comunicationally ignorant an=
d socially broken kind. One that I often see in other &quot;technical&quot;=
 areas, most notably in physics, where everyone seems to believe is a genio=
us and all others are retarded, just as in this case.<br>

<br></div><div class=3D"gmail_extra">I know there are lots of forums with e=
qually uneducated programmers, but IME they are often much, much less &quot=
;sophisticated&quot; than std-proposals.=A0 So like I said, I still can&#39=
;t believe I&#39;m really reading this here.<br>

<br><br clear=3D"all"><br>-- <br>Fernando Cacciola<br>SciSoft Consulting, F=
ounder<br><a href=3D"http://www.scisoft-consulting.com">http://www.scisoft-=
consulting.com</a>
</div></div>

<p></p>

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

--14dae9d24e446e803604def432e9--

.

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

Le mercredi 12 juin 2013 11:07:28 UTC+2, Ville Voutilainen a =E9crit :
>
>
> On 12 June 2013 11:39, DeadMG <wolfei...@gmail.com <javascript:>> wrote:
>
>> I seem to have missed your paper about changing these things.
>
>
> Luckily, there have been proposals by sane people to change some of those=
=20
> things.
> Such changes have thus far been of low priority. I don't expect lunatic=
=20
> raving to have
> an improving effect on that.
>

I thought partial function specialization was added already?=20

--=20

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



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

Le mercredi 12 juin 2013 11:07:28 UTC+2, Ville Voutilainen a =E9crit&nbsp;:=
<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><br><div=
 class=3D"gmail_quote">On 12 June 2013 11:39, DeadMG <span dir=3D"ltr">&lt;=
<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Rj5RWVS2=
v04J">wolfei...@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">I seem to have missed your paper about chang=
ing these things.</blockquote><div><br></div><div>Luckily, there have been =
proposals by sane people to change some of those things.<br></div><div>Such=
 changes have thus far been of low priority. I don't expect lunatic raving =
to have<br>
an improving effect on that.<br></div></div></div></div></blockquote><div><=
br></div><div>I thought partial function specialization was added already?&=
nbsp;</div>

<p></p>

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

------=_Part_111_6495977.1371043585260--

.

2013/6/12  <loufoque@gmail.com>:
> Le mercredi 12 juin 2013 11:07:28 UTC+2, Ville Voutilainen a =E9crit :
> I thought partial function specialization was added already?

You are misinformed.

- Daniel

--=20

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



.

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

With type_traits and SFINAE you can easily emulate partial specialization=
=20
with no fundamental problem :
-------------------------------------------------------
#include <iostream>
#include <type_traits>
struct S {
    template <class X, class =3D typename std::enable_if<!std::is_same<X,=
=20
int>::value>::type> void f()=20
    {std::cout<<"not int"<<std::endl;}
    template <class X, class =3D typename std::enable_if<std::is_same<X,=20
int>::value>::type, class =3D void> void f()
    {std::cout<<"int"<<std::endl;}
};

int main()
{
    S s;
    s.f<double>();
    s.f<int>();
    return 0;
}
-------------------------------------------------------

But as it was already said, standardization is a long peer-review process=
=20
to satisfy hundreds of thousands of programmers. So if you have a=20
proposition to make, write a clear proposal in order to have a basis for=20
further discussions.

Vincent

Le mercredi 12 juin 2013 15:26:25 UTC+2, louf...@gmail.com a =E9crit :
>
> Le mercredi 12 juin 2013 11:07:28 UTC+2, Ville Voutilainen a =E9crit :
>>
>>
>> On 12 June 2013 11:39, DeadMG <wolfei...@gmail.com> wrote:
>>
>>> I seem to have missed your paper about changing these things.
>>
>>
>> Luckily, there have been proposals by sane people to change some of thos=
e=20
>> things.
>> Such changes have thus far been of low priority. I don't expect lunatic=
=20
>> raving to have
>> an improving effect on that.
>>
>
> I thought partial function specialization was added already?=20
>

--=20

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



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

With type_traits and SFINAE you can easily emulate partial specialization w=
ith no fundamental problem :<br>-------------------------------------------=
------------<br>#include &lt;iostream&gt;<br>#include &lt;type_traits&gt;<b=
r>struct S {<br>&nbsp;&nbsp;&nbsp; template &lt;class X, class =3D typename=
 std::enable_if&lt;!std::is_same&lt;X, int&gt;::value&gt;::type&gt; void f(=
) <br>&nbsp;&nbsp;&nbsp; {std::cout&lt;&lt;"not int"&lt;&lt;std::endl;}<br>=
&nbsp;&nbsp;&nbsp; template &lt;class X, class =3D typename std::enable_if&=
lt;std::is_same&lt;X, int&gt;::value&gt;::type, class =3D void&gt; void f()=
<br>&nbsp;&nbsp;&nbsp; {std::cout&lt;&lt;"int"&lt;&lt;std::endl;}<br>};<br>=
<br>int main()<br>{<br>&nbsp;&nbsp;&nbsp; S s;<br>&nbsp;&nbsp;&nbsp; s.f&lt=
;double&gt;();<br>&nbsp;&nbsp;&nbsp; s.f&lt;int&gt;();<br>&nbsp;&nbsp;&nbsp=
; return 0;<br>}<br>-------------------------------------------------------=
<br><br>But as it was already said, standardization is a long peer-review p=
rocess to satisfy hundreds of thousands of programmers. So if you have a pr=
oposition to make, write a clear proposal in order to have a basis for furt=
her discussions.<br><br>Vincent<br><br>Le mercredi 12 juin 2013 15:26:25 UT=
C+2, louf...@gmail.com a =E9crit&nbsp;:<blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;">Le mercredi 12 juin 2013 11:07:28 UTC+2, Ville Voutilainen a =E9cr=
it&nbsp;:<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><br>=
<div class=3D"gmail_quote">On 12 June 2013 11:39, DeadMG <span dir=3D"ltr">=
&lt;<a>wolfei...@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">I seem to have missed your paper about chang=
ing these things.</blockquote><div><br></div><div>Luckily, there have been =
proposals by sane people to change some of those things.<br></div><div>Such=
 changes have thus far been of low priority. I don't expect lunatic raving =
to have<br>
an improving effect on that.<br></div></div></div></div></blockquote><div><=
br></div><div>I thought partial function specialization was added already?&=
nbsp;</div></blockquote>

<p></p>

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

------=_Part_1186_3773231.1371055025012--

.

------=_Part_5413_26944504.1371062148256
Content-Type: text/plain; charset=ISO-8859-1

In an attempt to salvage something of value from this thread, what exactly
is the problem with doing explicit, full specialization of types and
functions that are declared within a class? Was this just an oversight, or
was there some real problem with just allowing it to work as expected?

--

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



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

In an attempt to salvage something of value from this thread, what exactly =
is the problem with doing explicit, full specialization of types and functi=
ons that are declared within a class? Was this just an oversight, or was th=
ere some real problem with just allowing it to work as expected?<br>

<p></p>

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

------=_Part_5413_26944504.1371062148256--

.

--047d7b5da8a76863a004def963da
Content-Type: text/plain; charset=ISO-8859-1

I can not comment on whether it was originally an oversight, but having
proposed it to be changed, and being in the room when EWG approved the
change this past meeting - (and assuming my memory is serving me well), I
can tell you no one who was present had a good reason for why it was as it
was.  Let us see what happens in core.


Faisal Vali



On Wed, Jun 12, 2013 at 1:35 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> In an attempt to salvage something of value from this thread, what exactly
> is the problem with doing explicit, full specialization of types and
> functions that are declared within a class? Was this just an oversight, or
> was there some real problem with just allowing it to work as expected?
>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>
>
>

--

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



--047d7b5da8a76863a004def963da
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I can not comment on whether it was originally an oversigh=
t, but having proposed it to be changed, and being in the room when EWG app=
roved the change this past meeting - (and assuming my memory is serving me =
well), I can tell you no one who was present had a good reason for why it w=
as as it was.=A0 Let us see what happens in core.<br>
<br></div><div class=3D"gmail_extra"><br clear=3D"all"><div>Faisal Vali<br>=
<br></div>
<br><br><div class=3D"gmail_quote">On Wed, Jun 12, 2013 at 1:35 PM, Nicol B=
olas <span dir=3D"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D=
"_blank">jmckesson@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">
In an attempt to salvage something of value from this thread, what exactly =
is the problem with doing explicit, full specialization of types and functi=
ons that are declared within a class? Was this just an oversight, or was th=
ere some real problem with just allowing it to work as expected?<div class=
=3D"HOEnZb">
<div class=3D"h5"><br>

<p></p>

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

<p></p>

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

--047d7b5da8a76863a004def963da--

.

On Wed, Jun 12, 2013 at 11:43 AM, Faisal Vali <faisalv@gmail.com> wrote:
> I can not comment on whether it was originally an oversight, but having
> proposed it to be changed, and being in the room when EWG approved the
> change this past meeting - (and assuming my memory is serving me well), I
> can tell you no one who was present had a good reason for why it was as it
> was.  Let us see what happens in core.

For those following along at home, the "explicit class template
specialization at class scope" part is core issue 727, and was
proposed in
c++std-ext-13746.

> On Wed, Jun 12, 2013 at 1:35 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>>
>> In an attempt to salvage something of value from this thread, what exactly
>> is the problem with doing explicit, full specialization of types and
>> functions that are declared within a class? Was this just an oversight, or
>> was there some real problem with just allowing it to work as expected?
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>>
>>
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>
>

--

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



.

------=_Part_5449_28311026.1371064397618
Content-Type: text/plain; charset=ISO-8859-1

On Wednesday, June 12, 2013 11:43:22 AM UTC-7, faisalv wrote:
>
> I can not comment on whether it was originally an oversight, but having
> proposed it to be changed, and being in the room when EWG approved the
> change this past meeting - (and assuming my memory is serving me well), I
> can tell you no one who was present had a good reason for why it was as it
> was.  Let us see what happens in core.
>
>
> Faisal Vali
>

So... this has already been fixed for C++14 (modulo not being able to do
partial specialization on functions, which would be a far less trivial
request).

That's my fault for assuming a guy who named his thread "TOTAL RETARDATION"
knew what he was talking about.

--

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



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

On Wednesday, June 12, 2013 11:43:22 AM UTC-7, faisalv wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I can not comment on whethe=
r it was originally an oversight, but having proposed it to be changed, and=
 being in the room when EWG approved the change this past meeting - (and as=
suming my memory is serving me well), I can tell you no one who was present=
 had a good reason for why it was as it was.&nbsp; Let us see what happens =
in core.<br>
<br></div><div><br clear=3D"all"><div>Faisal Vali<br></div></div></blockquo=
te><div><br>So... this has already been fixed for C++14 (modulo not being a=
ble to do partial specialization on functions, which would be a far less tr=
ivial request).<br><br>That's my fault for assuming a guy who named his thr=
ead "TOTAL RETARDATION" knew what he was talking about.</div><br>

<p></p>

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

------=_Part_5449_28311026.1371064397618--

.

------=_Part_1937_32807291.1376265138378
Content-Type: text/plain; charset=ISO-8859-1

I'm usually against trolling but aside from the shocking verbal abuse this
guy has leveled at a bunch of hard-working and well-meaning people, I think
he has some good arguments which should be considered separately from the
ravings that accompanied them.

Also, you spelled "genius" wrong.

On Wednesday, 12 June 2013 08:31:06 UTC-4, Fernando Cacciola wrote:
>
> Wow, this thread totally beats me.
>
> I always thought, and maybe I still think, that there was something about
> being a programmer, and a C++ one more specially, that highly relates with
> having very effective comunication skills and focused problem solving
> skills applied to comunciation (i.e. don't complain, as it does nothing,
> but point and colaborate, etc). After all, a program boils down to a
> written expression of intent very carefully crafted out to produce a
> precise result. So I find it very very unusual to see a programmer failing
> so misserably at comunication something that is intended to have a
> specific, positive outcome.
>
> His approach is of a totally unproductive, comunicationally ignorant and
> socially broken kind. One that I often see in other "technical" areas, most
> notably in physics, where everyone seems to believe is a genious and all
> others are retarded, just as in this case.
>
> I know there are lots of forums with equally uneducated programmers, but
> IME they are often much, much less "sophisticated" than std-proposals.  So
> like I said, I still can't believe I'm really reading this here.
>
>
>
> --
> Fernando Cacciola
> SciSoft Consulting, Founder
> http://www.scisoft-consulting.com
>

--

---
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_1937_32807291.1376265138378
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I'm usually against trolling but aside from the shock=
ing verbal abuse this guy has leveled at a bunch of hard-working and well-m=
eaning people, I think he has some good arguments which should be considere=
d separately from the ravings that accompanied them.<br></div><div><br></di=
v>Also, you spelled "genius" wrong.<br><br>On Wednesday, 12 June 2013 08:31=
:06 UTC-4, Fernando Cacciola  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>Wow, this thread totally beats me.<br><br>I alw=
ays thought, and maybe I still think, that there was something about being =
a programmer, and a C++ one more specially, that highly relates with having=
 very effective comunication skills and focused problem solving skills appl=
ied to comunciation (i.e. don't complain, as it does nothing, but point and=
 colaborate, etc). After all, a program boils down to a written expression =
of intent very carefully crafted out to produce a precise result. So I find=
 it very very unusual to see a programmer failing so misserably at comunica=
tion something that is intended to have a specific, positive outcome.<br>

<br>His approach is of a totally unproductive, comunicationally ignorant an=
d socially broken kind. One that I often see in other "technical" areas, mo=
st notably in physics, where everyone seems to believe is a genious and all=
 others are retarded, just as in this case.<br>

<br></div><div>I know there are lots of forums with equally uneducated prog=
rammers, but IME they are often much, much less "sophisticated" than std-pr=
oposals.&nbsp; So like I said, I still can't believe I'm really reading thi=
s here.<br>

<br><br clear=3D"all"><br>-- <br>Fernando Cacciola<br>SciSoft Consulting, F=
ounder<br><a href=3D"http://www.scisoft-consulting.com" target=3D"_blank">h=
ttp://www.scisoft-consulting.<wbr>com</a>
</div></div>
</blockquote></div>

<p></p>

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

------=_Part_1937_32807291.1376265138378--

.

------=_Part_2076_1719942261.1425799210926
Content-Type: multipart/alternative;
 boundary="----=_Part_2077_1601800189.1425799210926"

------=_Part_2077_1601800189.1425799210926
Content-Type: text/plain; charset=UTF-8



On Sunday, August 11, 2013 at 5:52:18 PM UTC-6, stevenaw...@gmail.com wrote:
>
> I'm usually against trolling but aside from the shocking verbal abuse this
> guy has leveled at a bunch of hard-working and well-meaning people, I think
> he has some good arguments which should be considered separately from the
> ravings that accompanied them.
>
> Also, you spelled "genius" wrong.
>
>
Not to mention "miserably" only has one 's'.

Sorry. These things just stand out while I'm reading.  Spell-checkers are
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>On Sunday, August 11, 2013 at 5:52:18 PM UTC-6, st=
evenaw...@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"ltr"><div>I'm usually against trolling but aside from the shocking =
verbal abuse this guy has leveled at a bunch of hard-working and well-meani=
ng people, I think he has some good arguments which should be considered se=
parately from the ravings that accompanied them.<br></div><div><br></div>Al=
so, you spelled "genius" wrong.<br><br></div></blockquote><div dir=3D"ltr">=
&nbsp;<br>Not to mention "miserably" only has one 's'.<br></div><div><br>So=
rry. These things just stand out while I'm reading.&nbsp; Spell-checkers ar=
e available.<br><br></div></div>

<p></p>

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

------=_Part_2077_1601800189.1425799210926--
------=_Part_2076_1719942261.1425799210926--

.

------=_Part_235_693891808.1470920544572
Content-Type: multipart/alternative;
 boundary="----=_Part_236_1247885016.1470920544572"

------=_Part_236_1247885016.1470920544572
Content-Type: text/plain; charset=UTF-8

Is even ANY of this retardation fixed in C++17?

On Wednesday, June 12, 2013 at 1:10:52 AM UTC-7, looseont...@gmail.com
wrote:
>
> Hi,
>
>
> template <class X> void f() {}
> template <> void f<int>() {}
> COMPILES
>
>
> struct S {
>     template <class X> void f() {}
>     template <> void f<int>() {}
> };
> --> error: explicit specialization of 'f' in class scope
> FUCKING RETARDED
> WOW IT REALLY MAKES SENSE THAT THIS WORKS AT GLOBAL SCOPE BUT NOT IN-CLASS
>
>
> struct S {
>     template <class X> struct Inner {};
>     template <> struct Inner<int> {};
> };
> --> error: explicit specialization of 'Inner' in class scope
> FUCKING RETARDED
>
>
> struct S {
>     template <class X, class = void> struct Inner {};
>     template <class bullshit> struct Inner<int, bullshit> {};
> };
> WOW, RETARDS, WORKS WITH A STUPID-RETARDED WORKAROUND
>
>
> struct S {
>     template <class X, class=void> void f() {}
>     template <class bullshit> void f<int, bullshit>() {}
> };
> --> function template partial specialization is not allowed
> FUCKING RETARDED
> WOW THE RETARDED WORKAROUND DOESN'T WORK FOR FUNCTIONS
>
>
> template <class X> void f(X x) {}
> template <class X> void f(X* x) {}
> OH, OK THIS GOOD
>
>
> template <class X, class Y> void f() {}
> template <class Y> void f<int, Y>() {}
> --> function template partial specialization is not allowed
> FUCKING RETARDED.
>
>
> I don't even want to hear 1 piece of bullshit out of a single one of you
> people's mouths about this one.
> If you give me one piece of bullshit, you're a fucking n00b.
>
> Every one of these things is used for metaprogramming.
>
> After 15 years of awareness about these problems, nothing was fixed.
> And now with C++14, yet another oversight release, we're heading for 20
> years of fucking retardation.
>
> Thank you standards body people for your retarded level of awareness, you
> fucking retards.
> Can you fix the holes you fucking retards?
>
>

--
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/76e37e62-147b-4bec-8ab5-15f0051787b3%40isocpp.org.

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

<div dir=3D"ltr">Is even ANY of this retardation fixed in C++17?<br><br>On =
Wednesday, June 12, 2013 at 1:10:52 AM UTC-7, looseont...@gmail.com wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div>Hi,</div><div><br></div><d=
iv><br></div><div>template &lt;class X&gt; void f() {}</div><div>template &=
lt;&gt; void f&lt;int&gt;() {}</div><div>COMPILES</div><div><br></div><div>=
<br></div><div>struct S {</div><div>=C2=A0 =C2=A0 template &lt;class X&gt; =
void f() {}</div><div>=C2=A0 =C2=A0 template &lt;&gt; void f&lt;int&gt;() {=
}</div><div>};</div><div>--&gt; error: explicit specialization of &#39;f&#3=
9; in class scope</div><div>FUCKING RETARDED</div><div>WOW IT REALLY MAKES =
SENSE THAT THIS WORKS AT GLOBAL SCOPE BUT NOT IN-CLASS</div><div><br></div>=
<div><br></div><div>struct S {</div><div>=C2=A0 =C2=A0 template &lt;class X=
&gt; struct Inner {};</div><div>=C2=A0 =C2=A0 template &lt;&gt; struct Inne=
r&lt;int&gt; {};</div><div>};</div><div>--&gt; error: explicit specializati=
on of &#39;Inner&#39; in class scope</div><div>FUCKING RETARDED</div><div><=
br></div><div><br></div><div>struct S {</div><div>=C2=A0 =C2=A0 template &l=
t;class X, class =3D void&gt; struct Inner {};</div><div>=C2=A0 =C2=A0 temp=
late &lt;class bullshit&gt; struct Inner&lt;int, bullshit&gt; {};</div><div=
>};</div><div>WOW, RETARDS, WORKS WITH A STUPID-RETARDED WORKAROUND</div><d=
iv><br></div><div><br></div><div>struct S {</div><div>=C2=A0 =C2=A0 templat=
e &lt;class X, class=3Dvoid&gt; void f() {}</div><div>=C2=A0 =C2=A0 templat=
e &lt;class bullshit&gt; void f&lt;int, bullshit&gt;() {}</div><div>};</div=
><div>--&gt; function template partial specialization is not allowed</div><=
div>FUCKING RETARDED</div><div>WOW THE RETARDED WORKAROUND DOESN&#39;T WORK=
 FOR FUNCTIONS</div><div><br></div><div><br></div><div>template &lt;class X=
&gt; void f(X x) {}</div><div>template &lt;class X&gt; void f(X* x) {}</div=
><div>OH, OK THIS GOOD</div><div><br></div><div><br></div><div>template &lt=
;class X, class Y&gt; void f() {}</div><div>template &lt;class Y&gt; void f=
&lt;int, Y&gt;() {}</div><div>--&gt; function template partial specializati=
on is not allowed</div><div>FUCKING RETARDED.</div><div><br></div><div><br>=
</div><div>I don&#39;t even want to hear 1 piece of bullshit out of a singl=
e one of you people&#39;s mouths about this one.</div><div>If you give me o=
ne piece of bullshit, you&#39;re a fucking n00b.</div><div><br></div><div>E=
very one of these things is used for metaprogramming.</div><div><br></div><=
div>After 15 years of awareness about these problems, nothing was fixed.</d=
iv><div>And now with C++14, yet another oversight release, we&#39;re headin=
g for 20 years of fucking retardation.</div><div><br></div><div>Thank you s=
tandards body people for your retarded level of awareness, you fucking reta=
rds.<br></div><div>Can you fix the holes you fucking retards?</div><div><br=
></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/76e37e62-147b-4bec-8ab5-15f0051787b3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/76e37e62-147b-4bec-8ab5-15f0051787b3=
%40isocpp.org</a>.<br />

------=_Part_236_1247885016.1470920544572--

------=_Part_235_693891808.1470920544572--

.

On 11 August 2016 at 16:02,  <looseonthestreet@gmail.com> wrote:
> Is even ANY of this retardation fixed in C++17?

No.

--
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/CAFk2RUZcVMJzVOY-dU5wQKorzDPRjXrwsjK9tC_uBPG0sB6nVQ%40mail.gmail.com.

.

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

Get a load of this guy, who somehow thinks repeatedly insulting people
somehow makes them *more* likely to listen to him.

Recommend immediate address and IP block. No point even responding.

--
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/CACGiwhGgTBqH6i3i0APBud9_1V39Ca0FdfiFEkwgq19V0iXgSw%40mail.gmail.com.

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

<div dir=3D"ltr"><div>Get a load of this guy, who somehow thinks repeatedly=
 insulting people somehow makes them <i>more</i> likely to listen to him.<b=
r><br></div>Recommend immediate address and IP block. No point even respond=
ing.<br><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/CACGiwhGgTBqH6i3i0APBud9_1V39Ca0FdfiF=
Ekwgq19V0iXgSw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhGgTBqH6i3i=
0APBud9_1V39Ca0FdfiFEkwgq19V0iXgSw%40mail.gmail.com</a>.<br />

--001a11443eac8f3cc80539cb797f--

.

On Thu, Aug 11, 2016 at 8:08 AM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 11 August 2016 at 16:02,  <looseonthestreet@gmail.com> wrote:
>> Is even ANY of this retardation fixed in C++17?
>
> No.

I can't speak for when the specification will be updated, but I've
been meaning to merge (refactor and clean up) my patch of the agreed
upon resolutions for cwg727 & cwg1755 (https://reviews.llvm.org/D3445
- which should address the OP's frustrations) into clang trunk - but
sadly I haven't gotten around to it (given that it's been hard finding
time to get caught up on some of the more pressing issues).

And I'm not entirely sure that the OP's insulting tone is the right
way to motivate us (I tend to find that it usually has the opposite
effect on me - but I could be wrong ;)

Also please don't view the act of my response as accepting of the
notion that such abusive language on these reflectors should be
rewarded by any sort of response - but rather view it as seizing an
opportunity to inform the wider community that progress might be just
around the corner ...(especially if given the right push)




>
> --
> 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/CAFk2RUZcVMJzVOY-dU5wQKorzDPRjXrwsjK9tC_uBPG0sB6nVQ%40mail.gmail.com.

--
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/CABsSThp5YqaYX6-DYpjFZ%3Didei7UJJXYq1WKmMw9jkZA5sSkdQ%40mail.gmail.com.

.

------=_Part_1445_401009458.1470988462277
Content-Type: multipart/alternative;
 boundary="----=_Part_1446_1141256716.1470988462278"

------=_Part_1446_1141256716.1470988462278
Content-Type: text/plain; charset=UTF-8

And one more confusing thing for me.

In C++98 local classes can't be used as template arguments. But with
emergence of lambdas in C++11 this was fixed. In C++14 we got generic
lambdas but member templates in local classes still aren't allowed? WTF? Is
it just mistake( like "nobody has proposed this") or there are some real
difficulties to implement this as compared to generic lambdas?

(I am invoking the spirits of compiler writers ;-)

--
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/b146c590-1782-48e3-9c8e-30a1549e04e9%40isocpp.org.

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

<div dir=3D"ltr">And one more confusing thing for me.<br><br>In C++98 local=
 classes can&#39;t be used as template arguments. But with emergence of lam=
bdas in C++11 this was fixed. In C++14 we got generic lambdas but member te=
mplates in local classes still aren&#39;t allowed? WTF? Is it just mistake(=
 like &quot;nobody has proposed this&quot;) or there are some real difficul=
ties to implement this as compared to generic lambdas?<br><br>(I am invokin=
g the spirits of compiler writers ;-)<br><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/b146c590-1782-48e3-9c8e-30a1549e04e9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b146c590-1782-48e3-9c8e-30a1549e04e9=
%40isocpp.org</a>.<br />

------=_Part_1446_1141256716.1470988462278--

------=_Part_1445_401009458.1470988462277--

.

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

On Fri, Aug 12, 2016 at 12:54 AM, Victor Dyachenko <
victor.dyachenko@gmail.com> wrote:

> And one more confusing thing for me.
>
> In C++98 local classes can't be used as template arguments. But with
> emergence of lambdas in C++11 this was fixed. In C++14 we got generic
> lambdas but member templates in local classes still aren't allowed? WTF? Is
> it just mistake( like "nobody has proposed this") or there are some real
> difficulties to implement this as compared to generic lambdas?
>
> (I am invoking the spirits of compiler writers ;-)
>

There are real difficulties here, particularly if the member template is
inside a local class in a function template. In the implementation I'm
familiar with, a key problem is that the lexical scopes used while
processing a function definition are fundamentally transient, which means
that delaying instantiation of some portion of a function template
definition is hard to support. Generic lambdas don't suffer from a problem
here, because the body of the generic lambda is instantiated with the
enclosing function template, but presumably the instantiation model for a
member template within a local class of a function template would be that
the member template is not instantiated at all until a complete set of
template arguments for it are known, which may not happen until after the
instantiation of the enclosing template has finished and the lexical scope
information is gone.

--
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/CAOfiQqnCg-gx8ifWpe1fpe7dEtxPmk6crwOpyAFZeJ%2BuwRJngQ%40mail.gmail.com.

--001a1147f56aa856800539e44831
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 F=
ri, Aug 12, 2016 at 12:54 AM, Victor Dyachenko <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:victor.dyachenko@gmail.com" target=3D"_blank">victor.dyachenko@=
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"><div dir=
=3D"ltr">And one more confusing thing for me.<br><br>In C++98 local classes=
 can&#39;t be used as template arguments. But with emergence of lambdas in =
C++11 this was fixed. In C++14 we got generic lambdas but member templates =
in local classes still aren&#39;t allowed? WTF? Is it just mistake( like &q=
uot;nobody has proposed this&quot;) or there are some real difficulties to =
implement this as compared to generic lambdas?<br><br>(I am invoking the sp=
irits of compiler writers ;-)</div></blockquote><div><br></div><div>There a=
re real difficulties here, particularly if the member template is inside a =
local class in a function template. In the implementation I&#39;m familiar =
with, a key problem is that the lexical scopes used while processing a func=
tion definition are fundamentally transient, which means that delaying inst=
antiation of some portion of a function template definition is hard to supp=
ort. Generic lambdas don&#39;t suffer from a problem here, because the body=
 of the generic lambda is instantiated with the enclosing function template=
, but presumably the instantiation model for a member template within a loc=
al class of a function template would be that the member template is not in=
stantiated at all until a complete set of template arguments for it are kno=
wn, which may not happen until after the instantiation of the enclosing tem=
plate has finished and the lexical scope information is gone.</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/CAOfiQqnCg-gx8ifWpe1fpe7dEtxPmk6crwOp=
yAFZeJ%2BuwRJngQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqnCg-gx8i=
fWpe1fpe7dEtxPmk6crwOpyAFZeJ%2BuwRJngQ%40mail.gmail.com</a>.<br />

--001a1147f56aa856800539e44831--

.

------=_Part_512_1709882878.1471030469195
Content-Type: multipart/alternative;
 boundary="----=_Part_513_1517913398.1471030469196"

------=_Part_513_1517913398.1471030469196
Content-Type: text/plain; charset=UTF-8

On Friday, August 12, 2016 at 9:45:19 PM UTC+3, Richard Smith wrote:
>
> Generic lambdas don't suffer from a problem here, because the body of the
> generic lambda is instantiated with the enclosing function template, but
> presumably the instantiation model for a member template within a local
> class of a function template would be that the member template is not
> instantiated at all until a complete set of template arguments for it are
> known, which may not happen until after the instantiation of the enclosing
> template has finished and the lexical scope information is gone.
>

Richard, thank you for your response. But could you, please, clarify what
is the difference between this particular code snippets:

void f(const std::variant<int, char, double> &v)
{
    std::visit([](auto &v) { std::cout << v; }, v);
}

and

void f(const std::variant<int, char, double> &v)
{
    struct visitor
    {
        template<class T>
        void operator()(const T &v) const { std::cout << v; }
    };
    std::visit(visitor{} , v);
}

Why the former doesn't compile?

--
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/c18e8d92-4650-43b9-9e24-826a154a8e28%40isocpp.org.

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

<div dir=3D"ltr">On Friday, August 12, 2016 at 9:45:19 PM UTC+3, Richard Sm=
ith 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"><di=
v><div class=3D"gmail_quote">Generic lambdas don&#39;t suffer from a proble=
m here, because the body of the generic lambda is instantiated with the enc=
losing function template, but presumably the instantiation model for a memb=
er template within a local class of a function template would be that the m=
ember template is not instantiated at all until a complete set of template =
arguments for it are known, which may not happen until after the instantiat=
ion of the enclosing template has finished and the lexical scope informatio=
n is gone.</div></div></div></blockquote><div><br>Richard, thank you for yo=
ur response. But could you, please, clarify what is the difference between =
this particular code snippets:<br><br><div class=3D"prettyprint" style=3D"b=
ackground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bord=
er-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"=
prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> f</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">const</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> s=
td</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">variant</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span st=
yle=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: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">char</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>double</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">v</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><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>=C2=A0 =C2=A0 std</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">visit</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">([](</span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&a=
mp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">v</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">cout </span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">&lt;&lt;</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> v</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">},</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> v</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><br>and<br><br><div clas=
s=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-col=
or: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: =
break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> f</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">const</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">variant</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">int</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">char</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">double</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">v</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> visitor<br>=C2=A0 =C2=
=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">template</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
class</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">operator</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">()(</span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> T </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">v</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-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">cout </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">&lt;&lt;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> v</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"><br>=C2=A0 =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>=C2=A0 =C2=A0 std</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">visit</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">visi=
tor</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{}</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> v</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" cla=
ss=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><br>Why the former doesn&#39;t com=
pile?<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/c18e8d92-4650-43b9-9e24-826a154a8e28%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c18e8d92-4650-43b9-9e24-826a154a8e28=
%40isocpp.org</a>.<br />

------=_Part_513_1517913398.1471030469196--

------=_Part_512_1709882878.1471030469195--

.

On Fri, Aug 12, 2016 at 2:54 AM, Victor Dyachenko
<victor.dyachenko@gmail.com> wrote:
> And one more confusing thing for me.
>
> In C++98 local classes can't be used as template arguments. But with
> emergence of lambdas in C++11 this was fixed. In C++14 we got generic
> lambdas but member templates in local classes still aren't allowed? WTF? Is
> it just mistake( like "nobody has proposed this") or there are some real
> difficulties to implement this as compared to generic lambdas?
>
> (I am invoking the spirits of compiler writers ;-)
>

Richard is right as usual - local templates and member templates of
local classes are not necessarily trivial to implement in (or add to)
an implementation - just because that  implementation has generic
lambdas already implemented - but that doesn't mean they can't be
reasonably implemented - or that they should never be considered for a
future C++.

So if you have a compelling use case and well thought out design for
local templates that enough seasoned folks are willing to rally around
- commit to the cause, be brave and co-author a paper with those folks
-- and following an EWG presentation, you might just arrive at the
pleasant (or tragic ;) realization that the only reason C++ lacked
local templates was because you hadn't chosen to articulate a well
reasoned case for their design sooner ...


> --
> 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/b146c590-1782-48e3-9c8e-30a1549e04e9%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/CABsSThrv4REwtgxwT%3DchhSf%2B43f8cwhzL7%3Do8E6M7_YfWAG4tg%40mail.gmail.com.

.

On Fri, Aug 12, 2016 at 2:34 PM, Victor Dyachenko
<victor.dyachenko@gmail.com> wrote:
> On Friday, August 12, 2016 at 9:45:19 PM UTC+3, Richard Smith wrote:
>>
>> Generic lambdas don't suffer from a problem here, because the body of the
>> generic lambda is instantiated with the enclosing function template, but
>> presumably the instantiation model for a member template within a local
>> class of a function template would be that the member template is not
>> instantiated at all until a complete set of template arguments for it are
>> known, which may not happen until after the instantiation of the enclosing
>> template has finished and the lexical scope information is gone.
>
>
> Richard, thank you for your response. But could you, please, clarify what is
> the difference between this particular code snippets:
>
> void f(const std::variant<int, char, double> &v)
> {
>     std::visit([](auto &v) { std::cout << v; }, v);
> }
>
> and
>
> void f(const std::variant<int, char, double> &v)
> {
>     struct visitor
>     {
>         template<class T>
>         void operator()(const T &v) const { std::cout << v; }
>     };
>     std::visit(visitor{} , v);
> }
>
> Why the former doesn't compile?
>

The latter doesn't compile for the simple reason that the standard
prohibits member templates in local classes.

And if you're asking why would it be hard for a compiler to compile
the latter when it has no problem compiling the former - it wouldn't
(if the standard allowed it) - but then again this is not the
'partial-instantiation' case Richard was referring to above.




> --
> 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/c18e8d92-4650-43b9-9e24-826a154a8e28%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/CABsSThqybyADY7rZK8wcu3J_bLyizmft4bB08-YLZZhdjkc-oQ%40mail.gmail.com.

.

------=_Part_558_374933109.1471248773015
Content-Type: multipart/alternative;
 boundary="----=_Part_559_1150888113.1471248773015"

------=_Part_559_1150888113.1471248773015
Content-Type: text/plain; charset=UTF-8

Here is use case of the latter that explains why it can't replaced by
generic lambda:

void f(const std::variant<T1, T2, ...> &v)
{
    struct visitor
    {
        context ctx;
        visitor(...) : ctx(...) {}

        void operator()(const T1 &v) const; // some specific action for T1
        void operator()(const T2 &v) const; // some specific action for T2
        template<class T>
        void operator()(const T &v) const; // some 'default' action for all
other types
    };
    std::visit(visitor{...} , v);
}

One can argue that in this case you can build the visitor using lambdas +
overload()
<http://martinecker.com/martincodes/lambda-expression-overloading/>. But in
this case context must be embedded to each lambda.

On Friday, August 12, 2016 at 10:34:29 PM UTC+3, Victor Dyachenko wrote:
>
> On Friday, August 12, 2016 at 9:45:19 PM UTC+3, Richard Smith wrote:
>>
>> Generic lambdas don't suffer from a problem here, because the body of the
>> generic lambda is instantiated with the enclosing function template, but
>> presumably the instantiation model for a member template within a local
>> class of a function template would be that the member template is not
>> instantiated at all until a complete set of template arguments for it are
>> known, which may not happen until after the instantiation of the enclosing
>> template has finished and the lexical scope information is gone.
>>
>
> Richard, thank you for your response. But could you, please, clarify what
> is the difference between this particular code snippets:
>
> void f(const std::variant<int, char, double> &v)
> {
>     std::visit([](auto &v) { std::cout << v; }, v);
> }
>
> and
>
> void f(const std::variant<int, char, double> &v)
> {
>     struct visitor
>     {
>         template<class T>
>         void operator()(const T &v) const { std::cout << v; }
>     };
>     std::visit(visitor{} , v);
> }
>
> Why the former doesn't compile?
>

--
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/ee65239e-c2ba-463b-be7f-fd08a494c5ea%40isocpp.org.

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

<div dir=3D"ltr">Here is use case of the latter that explains why it can&#3=
9;t replaced by generic lambda:<br><span style=3D"color:#008"></span><br><s=
pan style=3D"color:#008"></span><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 st=
yle=3D"color:#000"> f</span><span style=3D"color:#660">(</span><span style=
=3D"color:#008">const</span><span style=3D"color:#000"> std</span><span sty=
le=3D"color:#660">::</span><span style=3D"color:#000">variant</span><span s=
tyle=3D"color:#660">&lt;T1, T2, ...</span><span style=3D"color:#008"></span=
><span style=3D"color:#660">&gt;</span><span style=3D"color:#000"> </span><=
span style=3D"color:#660">&amp;</span><span style=3D"color:#000">v</span><s=
pan style=3D"color:#660">)</span><span style=3D"color:#000"><br></span><spa=
n style=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0=
 </span><span style=3D"color:#008">struct</span><span style=3D"color:#000">=
 visitor<br>=C2=A0 =C2=A0 </span><span style=3D"color:#660">{</span><span s=
tyle=3D"color:#000"><br></span><span style=3D"color:#000"><code><span style=
=3D"color:#000"><code><span style=3D"color:#000"><code><span style=3D"color=
:#000">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 context ctx;<br>=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 visitor(...) : ctx(...) {}<br><br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#008">void</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#008">operator</span><span s=
tyle=3D"color:#660">()(</span><span style=3D"color:#008">const</span><span =
style=3D"color:#000"> T1 </span><span style=3D"color:#660">&amp;</span><spa=
n style=3D"color:#000">v</span><span style=3D"color:#660">)</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#008">const; // some specifi=
c action for T1</span><span style=3D"color:#000"><br></span></code></span><=
/code></span></code></span><span style=3D"color:#000"><code><span style=3D"=
color:#000"><code><span style=3D"color:#000"><code><span style=3D"color:#00=
0"><code><span style=3D"color:#000"><code><span style=3D"color:#000">=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#008">void</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#008">operator</span><span =
style=3D"color:#660">()(</span><span style=3D"color:#008">const</span><span=
 style=3D"color:#000"> T2 </span><span style=3D"color:#660">&amp;</span><sp=
an style=3D"color:#000">v</span><span style=3D"color:#660">)</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#008">const; // some specif=
ic action for T2</span><span style=3D"color:#000"><br></span></code></span>=
</code></span></code></span></code></span><span style=3D"color:#000"></span=
></code>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#008">templ=
ate</span><span style=3D"color:#660">&lt;</span><span style=3D"color:#008">=
class</span><span style=3D"color:#000"> T</span><span style=3D"color:#660">=
&gt;</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </spa=
n><span style=3D"color:#008">void</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#008">operator</span><span style=3D"color:#660">()(</s=
pan><span style=3D"color:#008">const</span><span style=3D"color:#000"> T </=
span><span style=3D"color:#660">&amp;</span><span style=3D"color:#000">v</s=
pan><span style=3D"color:#660">)</span><span style=3D"color:#000"> </span><=
span style=3D"color:#008">const</span><span style=3D"color:#000">; // some =
&#39;default</span><span style=3D"color:#000">&#39; action for all other ty=
pes<br>=C2=A0 =C2=A0 </span><span style=3D"color:#660">};</span><span style=
=3D"color:#000"><br>=C2=A0 =C2=A0 std</span><span style=3D"color:#660">::</=
span><span style=3D"color:#000">visit</span><span style=3D"color:#660">(</s=
pan><span style=3D"color:#000">visitor</span><span style=3D"color:#660">{..=
..}</span><span style=3D"color:#000"> </span><span style=3D"color:#660">,</s=
pan><span style=3D"color:#000"> v</span><span style=3D"color:#660">);</span=
><span style=3D"color:#000"><br></span><span style=3D"color:#660">}<br></sp=
an><span style=3D"color:#000"></span></div></code></div><br>One can argue t=
hat in this case you can build the visitor using lambdas + <a href=3D"http:=
//martinecker.com/martincodes/lambda-expression-overloading/">overload()</a=
>. But in this case <code><span style=3D"color:#000"><code><span style=3D"c=
olor:#000"><code><span style=3D"color:#000"><code><span style=3D"color:#000=
">context<span style=3D"font-family: arial,sans-serif;"> must be embedded t=
o each lambda.</span></span></code></span></code></span></code></span></cod=
e><br><br>On Friday, August 12, 2016 at 10:34:29 PM UTC+3, Victor Dyachenko=
 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 Fri=
day, August 12, 2016 at 9:45:19 PM UTC+3, Richard Smith wrote:<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><div class=3D"gmail_quote"=
>Generic lambdas don&#39;t suffer from a problem here, because the body of =
the generic lambda is instantiated with the enclosing function template, bu=
t presumably the instantiation model for a member template within a local c=
lass of a function template would be that the member template is not instan=
tiated at all until a complete set of template arguments for it are known, =
which may not happen until after the instantiation of the enclosing templat=
e has finished and the lexical scope information is gone.</div></div></div>=
</blockquote><div><br>Richard, thank you for your response. But could you, =
please, clarify what is the difference between this particular code snippet=
s:<br><br><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">void</span><span style=3D"color:#000"> f<=
/span><span style=3D"color:#660">(</span><span style=3D"color:#008">const</=
span><span style=3D"color:#000"> std</span><span style=3D"color:#660">::</s=
pan><span style=3D"color:#000">variant</span><span style=3D"color:#660">&lt=
;</span><span style=3D"color:#008">int</span><span style=3D"color:#660">,</=
span><span style=3D"color:#000"> </span><span style=3D"color:#008">char</sp=
an><span style=3D"color:#660">,</span><span style=3D"color:#000"> </span><s=
pan style=3D"color:#008">double</span><span style=3D"color:#660">&gt;</span=
><span style=3D"color:#000"> </span><span style=3D"color:#660">&amp;</span>=
<span style=3D"color:#000">v</span><span style=3D"color:#660">)</span><span=
 style=3D"color:#000"><br></span><span style=3D"color:#660">{</span><span s=
tyle=3D"color:#000"><br>=C2=A0 =C2=A0 std</span><span style=3D"color:#660">=
::</span><span style=3D"color:#000">visit</span><span style=3D"color:#660">=
([](</span><span style=3D"color:#008">auto</span><span style=3D"color:#000"=
> </span><span style=3D"color:#660">&amp;</span><span style=3D"color:#000">=
v</span><span style=3D"color:#660">)</span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#660">{</span><span style=3D"color:#000"> std</span=
><span style=3D"color:#660">::</span><span style=3D"color:#000">cout </span=
><span style=3D"color:#660">&lt;&lt;</span><span style=3D"color:#000"> v</s=
pan><span style=3D"color:#660">;</span><span style=3D"color:#000"> </span><=
span style=3D"color:#660">},</span><span style=3D"color:#000"> v</span><spa=
n style=3D"color:#660">);</span><span style=3D"color:#000"><br></span><span=
 style=3D"color:#660">}</span><span style=3D"color:#000"><br></span></div><=
/code></div><br>and<br><br><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"> f</span><span style=3D"color:#660">(</span><span style=3D"=
color:#008">const</span><span style=3D"color:#000"> std</span><span style=
=3D"color:#660">::</span><span style=3D"color:#000">variant</span><span sty=
le=3D"color:#660">&lt;</span><span style=3D"color:#008">int</span><span sty=
le=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=3D=
"color:#008">char</span><span style=3D"color:#660">,</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#008">double</span><span style=3D"c=
olor:#660">&gt;</span><span style=3D"color:#000"> </span><span style=3D"col=
or:#660">&amp;</span><span style=3D"color:#000">v</span><span style=3D"colo=
r:#660">)</span><span style=3D"color:#000"><br></span><span style=3D"color:=
#660">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span sty=
le=3D"color:#008">struct</span><span style=3D"color:#000"> visitor<br>=C2=
=A0 =C2=A0 </span><span style=3D"color:#660">{</span><span style=3D"color:#=
000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#008">temp=
late</span><span style=3D"color:#660">&lt;</span><span style=3D"color:#008"=
>class</span><span style=3D"color:#000"> T</span><span style=3D"color:#660"=
>&gt;</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </sp=
an><span style=3D"color:#008">void</span><span style=3D"color:#000"> </span=
><span style=3D"color:#008">operator</span><span style=3D"color:#660">()(</=
span><span style=3D"color:#008">const</span><span style=3D"color:#000"> T <=
/span><span style=3D"color:#660">&amp;</span><span style=3D"color:#000">v</=
span><span style=3D"color:#660">)</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#008">const</span><span style=3D"color:#000"> </span><=
span style=3D"color:#660">{</span><span style=3D"color:#000"> std</span><sp=
an style=3D"color:#660">::</span><span style=3D"color:#000">cout </span><sp=
an style=3D"color:#660">&lt;&lt;</span><span style=3D"color:#000"> v</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>=C2=A0 =C2=A0 =
</span><span style=3D"color:#660">};</span><span style=3D"color:#000"><br>=
=C2=A0 =C2=A0 std</span><span style=3D"color:#660">::</span><span style=3D"=
color:#000">visit</span><span style=3D"color:#660">(</span><span style=3D"c=
olor:#000">visitor</span><span style=3D"color:#660">{}</span><span style=3D=
"color:#000"> </span><span style=3D"color:#660">,</span><span style=3D"colo=
r:#000"> v</span><span style=3D"color:#660">);</span><span style=3D"color:#=
000"><br></span><span style=3D"color:#660">}</span><span style=3D"color:#00=
0"><br></span></div></code></div><br>Why the former doesn&#39;t compile?</d=
iv></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/ee65239e-c2ba-463b-be7f-fd08a494c5ea%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ee65239e-c2ba-463b-be7f-fd08a494c5ea=
%40isocpp.org</a>.<br />

------=_Part_559_1150888113.1471248773015--

------=_Part_558_374933109.1471248773015--

.

------=_Part_8346_17062099.1471328024429
Content-Type: multipart/alternative;
 boundary="----=_Part_8347_583537366.1471328024430"

------=_Part_8347_583537366.1471328024430
Content-Type: text/plain; charset=UTF-8

On Monday, August 15, 2016 at 1:12:53 AM UTC-7, Victor Dyachenko wrote:
>
> Here is use case of the latter that explains why it can't replaced by
> generic lambda:
>
> void f(const std::variant<T1, T2, ...> &v)
> {
>     struct visitor
>     {
>         context ctx;
>         visitor(...) : ctx(...) {}
>
>         void operator()(const T1 &v) const; // some specific action for T1
>         void operator()(const T2 &v) const; // some specific action for T2
>         template<class T>
>         void operator()(const T &v) const; // some 'default' action for
> all other types
>     };
>     std::visit(visitor{...} , v);
> }
>
> One can argue that in this case you can build the visitor using lambdas +
> overload()
> <http://martinecker.com/martincodes/lambda-expression-overloading/>. But
> in this case context must be embedded to each lambda.
>

void f(const std::variant<T1, T2, ...> &v)
{
    struct visitor
    {
        context ctx;
        visitor(...) : ctx(...) {}

        void operator()(const T1 &v) const; // some specific action for T1
        void operator()(const T2 &v) const; // some specific action for T2
        template<class T>
        void operator()(const T &v) const; // some 'default' action for all
other types
    };
    std::visit([ctx = context{...}](const auto& v) {
        if constexpr(is_same_v<const T1&, decltype(v)>) {

        } else if constexpr(is_same_v<const T2&, decltype(v)>) {
        } else {
        }
    }, v);
}

--
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/fdf23923-5497-4a67-9f6b-cc1ebac08d48%40isocpp.org.

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

<div dir=3D"ltr">On Monday, August 15, 2016 at 1:12:53 AM UTC-7, Victor Dya=
chenko 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">=
Here is use case of the latter that explains why it can&#39;t replaced by g=
eneric lambda:<br><span style=3D"color:#008"></span><br><span style=3D"colo=
r:#008"></span><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=
"> f</span><span style=3D"color:#660">(</span><span style=3D"color:#008">co=
nst</span><span style=3D"color:#000"> std</span><span style=3D"color:#660">=
::</span><span style=3D"color:#000">variant</span><span style=3D"color:#660=
">&lt;T1, T2, ...</span><span style=3D"color:#008"></span><span style=3D"co=
lor:#660">&gt;</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#660">&amp;</span><span style=3D"color:#000">v</span><span style=3D"color=
:#660">)</span><span style=3D"color:#000"><br></span><span style=3D"color:#=
660">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span styl=
e=3D"color:#008">struct</span><span style=3D"color:#000"> visitor<br>=C2=A0=
 =C2=A0 </span><span style=3D"color:#660">{</span><span style=3D"color:#000=
"><br></span><span style=3D"color:#000"><code><span style=3D"color:#000"><c=
ode><span style=3D"color:#000"><code><span style=3D"color:#000">=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 context ctx;<br>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 visitor(...) : ctx(...) {}<br><br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 </span><span style=3D"color:#008">void</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#008">operator</span><span style=3D"color:=
#660">()(</span><span style=3D"color:#008">const</span><span style=3D"color=
:#000"> T1 </span><span style=3D"color:#660">&amp;</span><span style=3D"col=
or:#000">v</span><span style=3D"color:#660">)</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#008">const; // some specific action for T=
1</span><span style=3D"color:#000"><br></span></code></span></code></span><=
/code></span><span style=3D"color:#000"><code><span style=3D"color:#000"><c=
ode><span style=3D"color:#000"><code><span style=3D"color:#000"><code><span=
 style=3D"color:#000"><code><span style=3D"color:#000">=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 </span><span style=3D"color:#008">void</span><span style=3D"color:#=
000"> </span><span style=3D"color:#008">operator</span><span style=3D"color=
:#660">()(</span><span style=3D"color:#008">const</span><span style=3D"colo=
r:#000"> T2 </span><span style=3D"color:#660">&amp;</span><span style=3D"co=
lor:#000">v</span><span style=3D"color:#660">)</span><span style=3D"color:#=
000"> </span><span style=3D"color:#008">const; // some specific action for =
T2</span><span style=3D"color:#000"><br></span></code></span></code></span>=
</code></span></code></span><span style=3D"color:#000"></span></code>=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#008">template</span><spa=
n style=3D"color:#660">&lt;</span><span style=3D"color:#008">class</span><s=
pan style=3D"color:#000"> T</span><span style=3D"color:#660">&gt;</span><sp=
an style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=
=3D"color:#008">void</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">operator</span><span style=3D"color:#660">()(</span><span s=
tyle=3D"color:#008">const</span><span style=3D"color:#000"> T </span><span =
style=3D"color:#660">&amp;</span><span style=3D"color:#000">v</span><span s=
tyle=3D"color:#660">)</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">const</span><span style=3D"color:#000">; // some &#39;defau=
lt</span><span style=3D"color:#000">&#39; action for all other types<br>=C2=
=A0 =C2=A0 </span><span style=3D"color:#660">};</span><span style=3D"color:=
#000"><br>=C2=A0 =C2=A0 std</span><span style=3D"color:#660">::</span><span=
 style=3D"color:#000">visit</span><span style=3D"color:#660">(</span><span =
style=3D"color:#000">visitor</span><span style=3D"color:#660">{...}</span><=
span style=3D"color:#000"> </span><span style=3D"color:#660">,</span><span =
style=3D"color:#000"> v</span><span style=3D"color:#660">);</span><span sty=
le=3D"color:#000"><br></span><span style=3D"color:#660">}<br></span><span s=
tyle=3D"color:#000"></span></div></code></div><br>One can argue that in thi=
s case you can build the visitor using lambdas + <a href=3D"http://martinec=
ker.com/martincodes/lambda-expression-overloading/" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x=
3dhttp%3A%2F%2Fmartinecker.com%2Fmartincodes%2Flambda-expression-overloadin=
g%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGSDKoXIuCy6EdNYp4YG9EeSj5FIg&#=
39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x=
3dhttp%3A%2F%2Fmartinecker.com%2Fmartincodes%2Flambda-expression-overloadin=
g%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGSDKoXIuCy6EdNYp4YG9EeSj5FIg&#=
39;;return true;">overload()</a>. But in this case <code><span style=3D"col=
or:#000"><code><span style=3D"color:#000"><code><span style=3D"color:#000">=
<code><span style=3D"color:#000">context<span style=3D"font-family:arial,sa=
ns-serif"> must be embedded to each lambda.</span></span></code></span></co=
de></span></code></span></code></div></blockquote><div><br></div><div><span=
 style=3D"font-family: monospace; color: rgb(0, 0, 136); background-color: =
rgb(250, 250, 250);">void</span><span style=3D"font-family: monospace; colo=
r: rgb(0, 0, 0); background-color: rgb(250, 250, 250);">=C2=A0f</span><span=
 style=3D"font-family: monospace; color: rgb(102, 102, 0); background-color=
: rgb(250, 250, 250);">(</span><span style=3D"font-family: monospace; color=
: rgb(0, 0, 136); background-color: rgb(250, 250, 250);">const</span><span =
style=3D"font-family: monospace; color: rgb(0, 0, 0); background-color: rgb=
(250, 250, 250);">=C2=A0std</span><span style=3D"font-family: monospace; co=
lor: rgb(102, 102, 0); background-color: rgb(250, 250, 250);">::</span><spa=
n style=3D"font-family: monospace; color: rgb(0, 0, 0); background-color: r=
gb(250, 250, 250);">variant</span><span style=3D"font-family: monospace; co=
lor: rgb(102, 102, 0); background-color: rgb(250, 250, 250);">&lt;T1, T2, .=
...</span><span style=3D"font-family: monospace; color: rgb(0, 0, 136); back=
ground-color: rgb(250, 250, 250);"></span><span style=3D"font-family: monos=
pace; color: rgb(102, 102, 0); background-color: rgb(250, 250, 250);">&gt;<=
/span><span style=3D"font-family: monospace; color: rgb(0, 0, 0); backgroun=
d-color: rgb(250, 250, 250);">=C2=A0</span><span style=3D"font-family: mono=
space; color: rgb(102, 102, 0); background-color: rgb(250, 250, 250);">&amp=
;</span><span style=3D"font-family: monospace; color: rgb(0, 0, 0); backgro=
und-color: rgb(250, 250, 250);">v</span><span style=3D"font-family: monospa=
ce; color: rgb(102, 102, 0); background-color: rgb(250, 250, 250);">)</span=
><span style=3D"font-family: monospace; color: rgb(0, 0, 0); background-col=
or: rgb(250, 250, 250);"><br></span><span style=3D"font-family: monospace; =
color: rgb(102, 102, 0); background-color: rgb(250, 250, 250);">{</span><sp=
an style=3D"font-family: monospace; color: rgb(0, 0, 0); background-color: =
rgb(250, 250, 250);"><br></span><span style=3D"font-family: monospace; colo=
r: rgb(0, 0, 0); background-color: rgb(250, 250, 250);">=C2=A0 =C2=A0=C2=A0=
</span><span style=3D"font-family: monospace; color: rgb(0, 0, 136); backgr=
ound-color: rgb(250, 250, 250);">struct</span><span style=3D"font-family: m=
onospace; color: rgb(0, 0, 0); background-color: rgb(250, 250, 250);">=C2=
=A0visitor</span><span style=3D"font-family: monospace; color: rgb(0, 0, 0)=
; background-color: rgb(250, 250, 250);"><br></span></div><div><span style=
=3D"font-family: monospace; color: rgb(0, 0, 0); background-color: rgb(250,=
 250, 250);">=C2=A0 =C2=A0=C2=A0</span><span style=3D"font-family: monospac=
e; color: rgb(102, 102, 0); background-color: rgb(250, 250, 250);">{</span>=
<span style=3D"font-family: monospace; color: rgb(0, 0, 0); background-colo=
r: rgb(250, 250, 250);"><br></span><span style=3D"font-family: monospace; c=
olor: rgb(0, 0, 0); background-color: rgb(250, 250, 250);"><code><code>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 context ctx;<br>=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 visitor(...) : ctx(...) {}<br><br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0=C2=A0<span style=3D"color: rgb(0, 0, 136);">void</span>=C2=A0=
<span style=3D"color: rgb(0, 0, 136);">operator</span><span style=3D"color:=
 rgb(102, 102, 0);">()(</span><span style=3D"color: rgb(0, 0, 136);">const<=
/span>=C2=A0T1=C2=A0<span style=3D"color: rgb(102, 102, 0);">&amp;</span>v<=
span style=3D"color: rgb(102, 102, 0);">)</span>=C2=A0<span style=3D"color:=
 rgb(0, 0, 136);">const; // some specific action for T1</span><br></code></=
code></span><span style=3D"font-family: monospace; color: rgb(0, 0, 0); bac=
kground-color: rgb(250, 250, 250);"><code><code>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0<span style=3D"color: rgb(0, 0, 136);">void</span>=C2=A0<span style=
=3D"color: rgb(0, 0, 136);">operator</span><span style=3D"color: rgb(102, 1=
02, 0);">()(</span><span style=3D"color: rgb(0, 0, 136);">const</span>=C2=
=A0T2=C2=A0<span style=3D"color: rgb(102, 102, 0);">&amp;</span>v<span styl=
e=3D"color: rgb(102, 102, 0);">)</span>=C2=A0<span style=3D"color: rgb(0, 0=
, 136);">const; // some specific action for T2</span><br></code></code>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0</span><span style=3D"font-family: monospace;=
 color: rgb(0, 0, 136); background-color: rgb(250, 250, 250);">template</sp=
an><span style=3D"font-family: monospace; color: rgb(102, 102, 0); backgrou=
nd-color: rgb(250, 250, 250);">&lt;</span><span style=3D"font-family: monos=
pace; color: rgb(0, 0, 136); background-color: rgb(250, 250, 250);">class</=
span><span style=3D"font-family: monospace; color: rgb(0, 0, 0); background=
-color: rgb(250, 250, 250);">=C2=A0T</span><span style=3D"font-family: mono=
space; color: rgb(102, 102, 0); background-color: rgb(250, 250, 250);">&gt;=
</span><span style=3D"font-family: monospace; color: rgb(0, 0, 0); backgrou=
nd-color: rgb(250, 250, 250);"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0</span>=
<span style=3D"font-family: monospace; color: rgb(0, 0, 136); background-co=
lor: rgb(250, 250, 250);">void</span><span style=3D"font-family: monospace;=
 color: rgb(0, 0, 0); background-color: rgb(250, 250, 250);">=C2=A0</span><=
span style=3D"font-family: monospace; color: rgb(0, 0, 136); background-col=
or: rgb(250, 250, 250);">operator</span><span style=3D"font-family: monospa=
ce; color: rgb(102, 102, 0); background-color: rgb(250, 250, 250);">()(</sp=
an><span style=3D"font-family: monospace; color: rgb(0, 0, 136); background=
-color: rgb(250, 250, 250);">const</span><span style=3D"font-family: monosp=
ace; color: rgb(0, 0, 0); background-color: rgb(250, 250, 250);">=C2=A0T=C2=
=A0</span><span style=3D"font-family: monospace; color: rgb(102, 102, 0); b=
ackground-color: rgb(250, 250, 250);">&amp;</span><span style=3D"font-famil=
y: monospace; color: rgb(0, 0, 0); background-color: rgb(250, 250, 250);">v=
</span><span style=3D"font-family: monospace; color: rgb(102, 102, 0); back=
ground-color: rgb(250, 250, 250);">)</span><span style=3D"font-family: mono=
space; color: rgb(0, 0, 0); background-color: rgb(250, 250, 250);">=C2=A0</=
span><span style=3D"font-family: monospace; color: rgb(0, 0, 136); backgrou=
nd-color: rgb(250, 250, 250);">const</span><span style=3D"font-family: mono=
space; color: rgb(0, 0, 0); background-color: rgb(250, 250, 250);">; // som=
e &#39;default</span><span style=3D"font-family: monospace; color: rgb(0, 0=
, 0); background-color: rgb(250, 250, 250);">&#39; action for all other typ=
es<br>=C2=A0 =C2=A0=C2=A0</span><span style=3D"font-family: monospace; colo=
r: rgb(102, 102, 0); background-color: rgb(250, 250, 250);">};</span><span =
style=3D"font-family: monospace; color: rgb(0, 0, 0); background-color: rgb=
(250, 250, 250);"><br>=C2=A0 =C2=A0 std</span><span style=3D"font-family: m=
onospace; color: rgb(102, 102, 0); background-color: rgb(250, 250, 250);">:=
:</span><span style=3D"font-family: monospace; color: rgb(0, 0, 0); backgro=
und-color: rgb(250, 250, 250);">visit</span><span style=3D"font-family: mon=
ospace; color: rgb(102, 102, 0); background-color: rgb(250, 250, 250);">([c=
tx =3D context{...}]</span><span style=3D"font-family: monospace; backgroun=
d-color: rgb(250, 250, 250);"><font color=3D"#000000">(const auto&amp; v) {=
</font></span></div><div><span style=3D"font-family: monospace; background-=
color: rgb(250, 250, 250);"><font color=3D"#000000">=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 if constexpr(is_same_v&lt;const T1&amp;, decltype(v)&gt;) {</font></=
span></div><div><span style=3D"font-family: monospace; background-color: rg=
b(250, 250, 250);"><font color=3D"#000000"><br></font></span></div><div><sp=
an style=3D"font-family: monospace; background-color: rgb(250, 250, 250);">=
<font color=3D"#000000">=C2=A0 =C2=A0 =C2=A0 =C2=A0 } else if constexpr(is_=
same_v&lt;const T2&amp;, decltype(v)&gt;) {</font></span></div><div><span s=
tyle=3D"font-family: monospace; background-color: rgb(250, 250, 250);"><fon=
t color=3D"#000000">=C2=A0 =C2=A0 =C2=A0 =C2=A0 } else {</font></span></div=
><div><span style=3D"font-family: monospace; background-color: rgb(250, 250=
, 250);"><font color=3D"#000000">=C2=A0 =C2=A0 =C2=A0 =C2=A0 }</font></span=
></div><div><span style=3D"font-family: monospace; color: rgb(102, 102, 0);=
 background-color: rgb(250, 250, 250);">=C2=A0 =C2=A0 },</span><span style=
=3D"font-family: monospace; color: rgb(0, 0, 0); background-color: rgb(250,=
 250, 250);">=C2=A0v</span><span style=3D"font-family: monospace; color: rg=
b(102, 102, 0); background-color: rgb(250, 250, 250);">);</span><span style=
=3D"font-family: monospace; color: rgb(0, 0, 0); background-color: rgb(250,=
 250, 250);"><br></span><span style=3D"font-family: monospace; color: rgb(1=
02, 102, 0); background-color: rgb(250, 250, 250);">}</span><br></div><div>=
<span style=3D"font-family: monospace; color: rgb(102, 102, 0); background-=
color: rgb(250, 250, 250);"><br></span></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/fdf23923-5497-4a67-9f6b-cc1ebac08d48%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fdf23923-5497-4a67-9f6b-cc1ebac08d48=
%40isocpp.org</a>.<br />

------=_Part_8347_583537366.1471328024430--

------=_Part_8346_17062099.1471328024429--

.

------=_Part_8178_933702556.1471328257395
Content-Type: multipart/alternative;
 boundary="----=_Part_8179_2145753620.1471328257396"

------=_Part_8179_2145753620.1471328257396
Content-Type: text/plain; charset=UTF-8

On Monday, August 15, 2016 at 11:13:44 PM UTC-7, Casey Carter wrote:
>
> On Monday, August 15, 2016 at 1:12:53 AM UTC-7, Victor Dyachenko wrote:
>>
>> Here is use case of the latter that explains why it can't replaced by
>> generic lambda:
>>
>> void f(const std::variant<T1, T2, ...> &v)
>> {
>>     struct visitor
>>     {
>>         context ctx;
>>         visitor(...) : ctx(...) {}
>>
>>         void operator()(const T1 &v) const; // some specific action for
>> T1
>>         void operator()(const T2 &v) const; // some specific action for
>> T2
>>         template<class T>
>>         void operator()(const T &v) const; // some 'default' action for
>> all other types
>>     };
>>     std::visit(visitor{...} , v);
>> }
>>
>> One can argue that in this case you can build the visitor using lambdas +
>> overload()
>> <http://martinecker.com/martincodes/lambda-expression-overloading/>. But
>> in this case context must be embedded to each lambda.
>>
>
> void f(const std::variant<T1, T2, ...> &v)
> {
>     struct visitor
>     {
>         context ctx;
>         visitor(...) : ctx(...) {}
>
>         void operator()(const T1 &v) const; // some specific action for T1
>         void operator()(const T2 &v) const; // some specific action for T2
>         template<class T>
>         void operator()(const T &v) const; // some 'default' action for
> all other types
>     };
>     std::visit([ctx = context{...}](const auto& v) {
>         if constexpr(is_same_v<const T1&, decltype(v)>) {
>
>         } else if constexpr(is_same_v<const T2&, decltype(v)>) {
>         } else {
>         }
>     }, v);
> }
>

*sigh* Sorry, early post. but the idea is fairly clear: "some specific
action for T1" in the first branch, etc.

Althought it's not precisely equivalent, since e.g. the struct version is
ill-formed if T1 and T2 are the same type, whereas the if constexpr version
is not.

--
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/4fa7a57b-4ffe-4633-aeba-e6f09d892eb4%40isocpp.org.

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

<div dir=3D"ltr">On Monday, August 15, 2016 at 11:13:44 PM UTC-7, Casey Car=
ter 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, August 15, 2016 at 1:12:53 AM UTC-7, Victor Dyachenko wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Here is use case of the l=
atter that explains why it can&#39;t replaced by generic lambda:<br><span s=
tyle=3D"color:#008"></span><br><span style=3D"color:#008"></span><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"> f</span><span style=
=3D"color:#660">(</span><span style=3D"color:#008">const</span><span style=
=3D"color:#000"> std</span><span style=3D"color:#660">::</span><span style=
=3D"color:#000">variant</span><span style=3D"color:#660">&lt;T1, T2, ...</s=
pan><span style=3D"color:#008"></span><span style=3D"color:#660">&gt;</span=
><span style=3D"color:#000"> </span><span style=3D"color:#660">&amp;</span>=
<span style=3D"color:#000">v</span><span style=3D"color:#660">)</span><span=
 style=3D"color:#000"><br></span><span style=3D"color:#660">{</span><span s=
tyle=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">str=
uct</span><span style=3D"color:#000"> visitor<br>=C2=A0 =C2=A0 </span><span=
 style=3D"color:#660">{</span><span style=3D"color:#000"><br></span><span s=
tyle=3D"color:#000"><code><span style=3D"color:#000"><code><span style=3D"c=
olor:#000"><code><span style=3D"color:#000">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 context ctx;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 vis=
itor(...) : ctx(...) {}<br><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span sty=
le=3D"color:#008">void</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">operator</span><span style=3D"color:#660">()(</span><span s=
tyle=3D"color:#008">const</span><span style=3D"color:#000"> T1 </span><span=
 style=3D"color:#660">&amp;</span><span style=3D"color:#000">v</span><span =
style=3D"color:#660">)</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">const; // some specific action for T1</span><span style=3D"=
color:#000"><br></span></code></span></code></span></code></span><span styl=
e=3D"color:#000"><code><span style=3D"color:#000"><code><span style=3D"colo=
r:#000"><code><span style=3D"color:#000"><code><span style=3D"color:#000"><=
code><span style=3D"color:#000">=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span st=
yle=3D"color:#008">void</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#008">operator</span><span style=3D"color:#660">()(</span><span =
style=3D"color:#008">const</span><span style=3D"color:#000"> T2 </span><spa=
n style=3D"color:#660">&amp;</span><span style=3D"color:#000">v</span><span=
 style=3D"color:#660">)</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#008">const; // some specific action for T2</span><span style=3D=
"color:#000"><br></span></code></span></code></span></code></span></code></=
span><span style=3D"color:#000"></span></code>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <=
/span><span style=3D"color:#008">template</span><span style=3D"color:#660">=
&lt;</span><span style=3D"color:#008">class</span><span style=3D"color:#000=
"> T</span><span style=3D"color:#660">&gt;</span><span style=3D"color:#000"=
><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#008">void</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#008">operator</=
span><span style=3D"color:#660">()(</span><span style=3D"color:#008">const<=
/span><span style=3D"color:#000"> T </span><span style=3D"color:#660">&amp;=
</span><span style=3D"color:#000">v</span><span style=3D"color:#660">)</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#008">const</span=
><span style=3D"color:#000">; // some &#39;default</span><span style=3D"col=
or:#000">&#39; action for all other types<br>=C2=A0 =C2=A0 </span><span sty=
le=3D"color:#660">};</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 std=
</span><span style=3D"color:#660">::</span><span style=3D"color:#000">visit=
</span><span style=3D"color:#660">(</span><span style=3D"color:#000">visito=
r</span><span style=3D"color:#660">{...}</span><span style=3D"color:#000"> =
</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> v</sp=
an><span style=3D"color:#660">);</span><span style=3D"color:#000"><br></spa=
n><span style=3D"color:#660">}<br></span><span style=3D"color:#000"></span>=
</div></code></div><br>One can argue that in this case you can build the vi=
sitor using lambdas + <a href=3D"http://martinecker.com/martincodes/lambda-=
expression-overloading/" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"=
this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmartinecker.co=
m%2Fmartincodes%2Flambda-expression-overloading%2F\x26sa\x3dD\x26sntz\x3d1\=
x26usg\x3dAFQjCNGSDKoXIuCy6EdNYp4YG9EeSj5FIg&#39;;return true;" onclick=3D"=
this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmartinecker.co=
m%2Fmartincodes%2Flambda-expression-overloading%2F\x26sa\x3dD\x26sntz\x3d1\=
x26usg\x3dAFQjCNGSDKoXIuCy6EdNYp4YG9EeSj5FIg&#39;;return true;">overload()<=
/a>. But in this case <code><span style=3D"color:#000"><code><span style=3D=
"color:#000"><code><span style=3D"color:#000"><code><span style=3D"color:#0=
00">context<span style=3D"font-family:arial,sans-serif"> must be embedded t=
o each lambda.</span></span></code></span></code></span></code></span></cod=
e></div></blockquote><div><br></div><div><span style=3D"font-family:monospa=
ce;color:rgb(0,0,136);background-color:rgb(250,250,250)">void</span><span s=
tyle=3D"font-family:monospace;color:rgb(0,0,0);background-color:rgb(250,250=
,250)">=C2=A0f</span><span style=3D"font-family:monospace;color:rgb(102,102=
,0);background-color:rgb(250,250,250)">(</span><span style=3D"font-family:m=
onospace;color:rgb(0,0,136);background-color:rgb(250,250,250)">const</span>=
<span style=3D"font-family:monospace;color:rgb(0,0,0);background-color:rgb(=
250,250,250)">=C2=A0std</span><span style=3D"font-family:monospace;color:rg=
b(102,102,0);background-color:rgb(250,250,250)">::</span><span style=3D"fon=
t-family:monospace;color:rgb(0,0,0);background-color:rgb(250,250,250)">vari=
ant</span><span style=3D"font-family:monospace;color:rgb(102,102,0);backgro=
und-color:rgb(250,250,250)">&lt;T1, T2, ...</span><span style=3D"font-famil=
y:monospace;color:rgb(0,0,136);background-color:rgb(250,250,250)"></span><s=
pan style=3D"font-family:monospace;color:rgb(102,102,0);background-color:rg=
b(250,250,250)">&gt;</span><span style=3D"font-family:monospace;color:rgb(0=
,0,0);background-color:rgb(250,250,250)">=C2=A0</span><span style=3D"font-f=
amily:monospace;color:rgb(102,102,0);background-color:rgb(250,250,250)">&am=
p;</span><span style=3D"font-family:monospace;color:rgb(0,0,0);background-c=
olor:rgb(250,250,250)">v</span><span style=3D"font-family:monospace;color:r=
gb(102,102,0);background-color:rgb(250,250,250)">)</span><span style=3D"fon=
t-family:monospace;color:rgb(0,0,0);background-color:rgb(250,250,250)"><br>=
</span><span style=3D"font-family:monospace;color:rgb(102,102,0);background=
-color:rgb(250,250,250)">{</span><span style=3D"font-family:monospace;color=
:rgb(0,0,0);background-color:rgb(250,250,250)"><br></span><span style=3D"fo=
nt-family:monospace;color:rgb(0,0,0);background-color:rgb(250,250,250)">=C2=
=A0 =C2=A0=C2=A0</span><span style=3D"font-family:monospace;color:rgb(0,0,1=
36);background-color:rgb(250,250,250)">struct</span><span style=3D"font-fam=
ily:monospace;color:rgb(0,0,0);background-color:rgb(250,250,250)">=C2=A0vis=
itor</span><span style=3D"font-family:monospace;color:rgb(0,0,0);background=
-color:rgb(250,250,250)"><br></span></div><div><span style=3D"font-family:m=
onospace;color:rgb(0,0,0);background-color:rgb(250,250,250)">=C2=A0 =C2=A0=
=C2=A0</span><span style=3D"font-family:monospace;color:rgb(102,102,0);back=
ground-color:rgb(250,250,250)">{</span><span style=3D"font-family:monospace=
;color:rgb(0,0,0);background-color:rgb(250,250,250)"><br></span><span style=
=3D"font-family:monospace;color:rgb(0,0,0);background-color:rgb(250,250,250=
)"><code><code>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 context ctx;<br>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 visitor(...) : ctx(...) {}<br><b=
r>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0<span style=3D"color:rgb(0,0,136)">void<=
/span>=C2=A0<span style=3D"color:rgb(0,0,136)">operator</span><span style=
=3D"color:rgb(102,102,0)">()(</span><span style=3D"color:rgb(0,0,136)">cons=
t</span>=C2=A0T1=C2=A0<span style=3D"color:rgb(102,102,0)">&amp;</span>v<sp=
an style=3D"color:rgb(102,102,0)">)</span><wbr>=C2=A0<span style=3D"color:r=
gb(0,0,136)">const; // some specific action for T1</span><br></code></code>=
</span><span style=3D"font-family:monospace;color:rgb(0,0,0);background-col=
or:rgb(250,250,250)"><code><code>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0<span sty=
le=3D"color:rgb(0,0,136)">void</span>=C2=A0<span style=3D"color:rgb(0,0,136=
)">operator</span><span style=3D"color:rgb(102,102,0)">()(</span><span styl=
e=3D"color:rgb(0,0,136)">const</span>=C2=A0T2=C2=A0<span style=3D"color:rgb=
(102,102,0)">&amp;</span>v<span style=3D"color:rgb(102,102,0)">)</span><wbr=
>=C2=A0<span style=3D"color:rgb(0,0,136)">const; // some specific action fo=
r T2</span><br></code></code>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0</span><span =
style=3D"font-family:monospace;color:rgb(0,0,136);background-color:rgb(250,=
250,250)">template</span><span style=3D"font-family:monospace;color:rgb(102=
,102,0);background-color:rgb(250,250,250)">&lt;</span><span style=3D"font-f=
amily:monospace;color:rgb(0,0,136);background-color:rgb(250,250,250)">class=
</span><span style=3D"font-family:monospace;color:rgb(0,0,0);background-col=
or:rgb(250,250,250)">=C2=A0T</span><span style=3D"font-family:monospace;col=
or:rgb(102,102,0);background-color:rgb(250,250,250)">&gt;</span><span style=
=3D"font-family:monospace;color:rgb(0,0,0);background-color:rgb(250,250,250=
)"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0</span><span style=3D"font-family:m=
onospace;color:rgb(0,0,136);background-color:rgb(250,250,250)">void</span><=
span style=3D"font-family:monospace;color:rgb(0,0,0);background-color:rgb(2=
50,250,250)">=C2=A0</span><span style=3D"font-family:monospace;color:rgb(0,=
0,136);background-color:rgb(250,250,250)">operator</span><span style=3D"fon=
t-family:monospace;color:rgb(102,102,0);background-color:rgb(250,250,250)">=
()(</span><span style=3D"font-family:monospace;color:rgb(0,0,136);backgroun=
d-color:rgb(250,250,250)">const</span><span style=3D"font-family:monospace;=
color:rgb(0,0,0);background-color:rgb(250,250,250)">=C2=A0T=C2=A0</span><sp=
an style=3D"font-family:monospace;color:rgb(102,102,0);background-color:rgb=
(250,250,250)">&amp;</span><span style=3D"font-family:monospace;color:rgb(0=
,0,0);background-color:rgb(250,250,250)">v</span><span style=3D"font-family=
:monospace;color:rgb(102,102,0);background-color:rgb(250,250,250)">)</span>=
<span style=3D"font-family:monospace;color:rgb(0,0,0);background-color:rgb(=
250,250,250)">=C2=A0</span><span style=3D"font-family:monospace;color:rgb(0=
,0,136);background-color:rgb(250,250,250)"><wbr>const</span><span style=3D"=
font-family:monospace;color:rgb(0,0,0);background-color:rgb(250,250,250)">;=
 // some &#39;default</span><span style=3D"font-family:monospace;color:rgb(=
0,0,0);background-color:rgb(250,250,250)">&#39; action for all other types<=
br>=C2=A0 =C2=A0=C2=A0</span><span style=3D"font-family:monospace;color:rgb=
(102,102,0);background-color:rgb(250,250,250)">};</span><span style=3D"font=
-family:monospace;color:rgb(0,0,0);background-color:rgb(250,250,250)"><br>=
=C2=A0 =C2=A0 std</span><span style=3D"font-family:monospace;color:rgb(102,=
102,0);background-color:rgb(250,250,250)">::</span><span style=3D"font-fami=
ly:monospace;color:rgb(0,0,0);background-color:rgb(250,250,250)">visit</spa=
n><span style=3D"font-family:monospace;color:rgb(102,102,0);background-colo=
r:rgb(250,250,250)">([ctx =3D context{...}]</span><span style=3D"font-famil=
y:monospace;background-color:rgb(250,250,250)"><font color=3D"#000000">(con=
st auto&amp; v) {</font></span></div><div><span style=3D"font-family:monosp=
ace;background-color:rgb(250,250,250)"><font color=3D"#000000">=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 if constexpr(is_same_v&lt;const T1&amp;, decltype(v)&gt;)=
 {</font></span></div><div><span style=3D"font-family:monospace;background-=
color:rgb(250,250,250)"><font color=3D"#000000"><br></font></span></div><di=
v><span style=3D"font-family:monospace;background-color:rgb(250,250,250)"><=
font color=3D"#000000">=C2=A0 =C2=A0 =C2=A0 =C2=A0 } else if constexpr(is_s=
ame_v&lt;const T2&amp;, decltype(v)&gt;) {</font></span></div><div><span st=
yle=3D"font-family:monospace;background-color:rgb(250,250,250)"><font color=
=3D"#000000">=C2=A0 =C2=A0 =C2=A0 =C2=A0 } else {</font></span></div><div><=
span style=3D"font-family:monospace;background-color:rgb(250,250,250)"><fon=
t color=3D"#000000">=C2=A0 =C2=A0 =C2=A0 =C2=A0 }</font></span></div><div><=
span style=3D"font-family:monospace;color:rgb(102,102,0);background-color:r=
gb(250,250,250)">=C2=A0 =C2=A0 },</span><span style=3D"font-family:monospac=
e;color:rgb(0,0,0);background-color:rgb(250,250,250)">=C2=A0v</span><span s=
tyle=3D"font-family:monospace;color:rgb(102,102,0);background-color:rgb(250=
,250,250)">);</span><span style=3D"font-family:monospace;color:rgb(0,0,0);b=
ackground-color:rgb(250,250,250)"><br></span><span style=3D"font-family:mon=
ospace;color:rgb(102,102,0);background-color:rgb(250,250,250)">}</span></di=
v></div></blockquote><div><br></div><div>*sigh* Sorry, early post. but the =
idea is fairly clear: &quot;some specific action for T1&quot; in the first =
branch, etc.</div><div><br></div><div>Althought it&#39;s not precisely equi=
valent, since e.g. the struct version is ill-formed if T1 and T2 are the sa=
me type, whereas the if constexpr version is not.</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/4fa7a57b-4ffe-4633-aeba-e6f09d892eb4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4fa7a57b-4ffe-4633-aeba-e6f09d892eb4=
%40isocpp.org</a>.<br />

------=_Part_8179_2145753620.1471328257396--

------=_Part_8178_933702556.1471328257395--

.

------=_Part_65_668689120.1471332653166
Content-Type: multipart/alternative;
 boundary="----=_Part_66_1764274342.1471332653166"

------=_Part_66_1764274342.1471332653166
Content-Type: text/plain; charset=UTF-8

On Tuesday, August 16, 2016 at 9:13:44 AM UTC+3, Casey Carter wrote:
>
> void f(const std::variant<T1, T2, ...> &v)
> {
>     struct visitor
>     {
>         context ctx;
>         visitor(...) : ctx(...) {}
>
>         void operator()(const T1 &v) const; // some specific action for T1
>         void operator()(const T2 &v) const; // some specific action for T2
>         template<class T>
>         void operator()(const T &v) const; // some 'default' action for
> all other types
>     };
>     std::visit([ctx = context{...}](const auto& v) {
>         if constexpr(is_same_v<const T1&, decltype(v)>) {
>
>         } else if constexpr(is_same_v<const T2&, decltype(v)>) {
>         } else {
>         }
>     }, v);
> }
>
Hmm... Great idea! But we have to wait for the new Standard.

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

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

<div dir=3D"ltr">On Tuesday, August 16, 2016 at 9:13:44 AM UTC+3, Casey Car=
ter 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"><sp=
an style=3D"font-family:monospace;color:rgb(0,0,136);background-color:rgb(2=
50,250,250)">void</span><span style=3D"font-family:monospace;color:rgb(0,0,=
0);background-color:rgb(250,250,250)">=C2=A0f</span><span style=3D"font-fam=
ily:monospace;color:rgb(102,102,0);background-color:rgb(250,250,250)">(</sp=
an><span style=3D"font-family:monospace;color:rgb(0,0,136);background-color=
:rgb(250,250,250)">const</span><span style=3D"font-family:monospace;color:r=
gb(0,0,0);background-color:rgb(250,250,250)">=C2=A0std</span><span style=3D=
"font-family:monospace;color:rgb(102,102,0);background-color:rgb(250,250,25=
0)">::</span><span style=3D"font-family:monospace;color:rgb(0,0,0);backgrou=
nd-color:rgb(250,250,250)">variant</span><span style=3D"font-family:monospa=
ce;color:rgb(102,102,0);background-color:rgb(250,250,250)">&lt;T1, T2, ...<=
/span><span style=3D"font-family:monospace;color:rgb(0,0,136);background-co=
lor:rgb(250,250,250)"></span><span style=3D"font-family:monospace;color:rgb=
(102,102,0);background-color:rgb(250,250,250)">&gt;</span><span style=3D"fo=
nt-family:monospace;color:rgb(0,0,0);background-color:rgb(250,250,250)">=C2=
=A0</span><span style=3D"font-family:monospace;color:rgb(102,102,0);backgro=
und-color:rgb(250,250,250)">&amp;</span><span style=3D"font-family:monospac=
e;color:rgb(0,0,0);background-color:rgb(250,250,250)">v</span><span style=
=3D"font-family:monospace;color:rgb(102,102,0);background-color:rgb(250,250=
,250)">)</span><span style=3D"font-family:monospace;color:rgb(0,0,0);backgr=
ound-color:rgb(250,250,250)"></span><br><span style=3D"font-family:monospac=
e;color:rgb(0,0,0);background-color:rgb(250,250,250)"></span><div><span sty=
le=3D"font-family:monospace;color:rgb(102,102,0);background-color:rgb(250,2=
50,250)">{</span><span style=3D"font-family:monospace;color:rgb(0,0,0);back=
ground-color:rgb(250,250,250)"><br></span><span style=3D"font-family:monosp=
ace;color:rgb(0,0,0);background-color:rgb(250,250,250)">=C2=A0 =C2=A0=C2=A0=
</span><span style=3D"font-family:monospace;color:rgb(0,0,136);background-c=
olor:rgb(250,250,250)">struct</span><span style=3D"font-family:monospace;co=
lor:rgb(0,0,0);background-color:rgb(250,250,250)">=C2=A0visitor</span><span=
 style=3D"font-family:monospace;color:rgb(0,0,0);background-color:rgb(250,2=
50,250)"><br></span></div><div><span style=3D"font-family:monospace;color:r=
gb(0,0,0);background-color:rgb(250,250,250)">=C2=A0 =C2=A0=C2=A0</span><spa=
n style=3D"font-family:monospace;color:rgb(102,102,0);background-color:rgb(=
250,250,250)">{</span><span style=3D"font-family:monospace;color:rgb(0,0,0)=
;background-color:rgb(250,250,250)"><br></span><span style=3D"font-family:m=
onospace;color:rgb(0,0,0);background-color:rgb(250,250,250)"><code><code>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 context ctx;<br>=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 visitor(...) : ctx(...) {}<br><br>=C2=A0 =C2=A0=
 =C2=A0 =C2=A0=C2=A0<span style=3D"color:rgb(0,0,136)">void</span>=C2=A0<sp=
an style=3D"color:rgb(0,0,136)">operator</span><span style=3D"color:rgb(102=
,102,0)">()(</span><span style=3D"color:rgb(0,0,136)">const</span>=C2=A0T1=
=C2=A0<span style=3D"color:rgb(102,102,0)">&amp;</span>v<span style=3D"colo=
r:rgb(102,102,0)">)</span><wbr>=C2=A0<span style=3D"color:rgb(0,0,136)">con=
st; // some specific action for T1</span><br></code></code></span><span sty=
le=3D"font-family:monospace;color:rgb(0,0,0);background-color:rgb(250,250,2=
50)"><code><code>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0<span style=3D"color:rgb(=
0,0,136)">void</span>=C2=A0<span style=3D"color:rgb(0,0,136)">operator</spa=
n><span style=3D"color:rgb(102,102,0)">()(</span><span style=3D"color:rgb(0=
,0,136)">const</span>=C2=A0T2=C2=A0<span style=3D"color:rgb(102,102,0)">&am=
p;</span>v<span style=3D"color:rgb(102,102,0)">)</span><wbr>=C2=A0<span sty=
le=3D"color:rgb(0,0,136)">const; // some specific action for T2</span><br><=
/code></code>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0</span><span style=3D"font-fa=
mily:monospace;color:rgb(0,0,136);background-color:rgb(250,250,250)">templa=
te</span><span style=3D"font-family:monospace;color:rgb(102,102,0);backgrou=
nd-color:rgb(250,250,250)">&lt;</span><span style=3D"font-family:monospace;=
color:rgb(0,0,136);background-color:rgb(250,250,250)">class</span><span sty=
le=3D"font-family:monospace;color:rgb(0,0,0);background-color:rgb(250,250,2=
50)">=C2=A0T</span><span style=3D"font-family:monospace;color:rgb(102,102,0=
);background-color:rgb(250,250,250)">&gt;</span><span style=3D"font-family:=
monospace;color:rgb(0,0,0);background-color:rgb(250,250,250)"><br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0=C2=A0</span><span style=3D"font-family:monospace;color=
:rgb(0,0,136);background-color:rgb(250,250,250)">void</span><span style=3D"=
font-family:monospace;color:rgb(0,0,0);background-color:rgb(250,250,250)">=
=C2=A0</span><span style=3D"font-family:monospace;color:rgb(0,0,136);backgr=
ound-color:rgb(250,250,250)">operator</span><span style=3D"font-family:mono=
space;color:rgb(102,102,0);background-color:rgb(250,250,250)">()(</span><sp=
an style=3D"font-family:monospace;color:rgb(0,0,136);background-color:rgb(2=
50,250,250)">const</span><span style=3D"font-family:monospace;color:rgb(0,0=
,0);background-color:rgb(250,250,250)">=C2=A0T=C2=A0</span><span style=3D"f=
ont-family:monospace;color:rgb(102,102,0);background-color:rgb(250,250,250)=
">&amp;</span><span style=3D"font-family:monospace;color:rgb(0,0,0);backgro=
und-color:rgb(250,250,250)">v</span><span style=3D"font-family:monospace;co=
lor:rgb(102,102,0);background-color:rgb(250,250,250)">)</span><span style=
=3D"font-family:monospace;color:rgb(0,0,0);background-color:rgb(250,250,250=
)">=C2=A0</span><span style=3D"font-family:monospace;color:rgb(0,0,136);bac=
kground-color:rgb(250,250,250)"><wbr>const</span><span style=3D"font-family=
:monospace;color:rgb(0,0,0);background-color:rgb(250,250,250)">; // some &#=
39;default</span><span style=3D"font-family:monospace;color:rgb(0,0,0);back=
ground-color:rgb(250,250,250)">&#39; action for all other types<br>=C2=A0 =
=C2=A0=C2=A0</span><span style=3D"font-family:monospace;color:rgb(102,102,0=
);background-color:rgb(250,250,250)">};</span><span style=3D"font-family:mo=
nospace;color:rgb(0,0,0);background-color:rgb(250,250,250)"><br>=C2=A0 =C2=
=A0 std</span><span style=3D"font-family:monospace;color:rgb(102,102,0);bac=
kground-color:rgb(250,250,250)">::</span><span style=3D"font-family:monospa=
ce;color:rgb(0,0,0);background-color:rgb(250,250,250)">visit</span><span st=
yle=3D"font-family:monospace;color:rgb(102,102,0);background-color:rgb(250,=
250,250)">([ctx =3D context{...}]</span><span style=3D"font-family:monospac=
e;background-color:rgb(250,250,250)"><font color=3D"#000000">(const auto&am=
p; v) {</font></span></div><div><span style=3D"font-family:monospace;backgr=
ound-color:rgb(250,250,250)"><font color=3D"#000000">=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 if constexpr(is_same_v&lt;const T1&amp;, decltype(v)&gt;) {</font></=
span></div><div><span style=3D"font-family:monospace;background-color:rgb(2=
50,250,250)"><font color=3D"#000000"><br></font></span></div><div><span sty=
le=3D"font-family:monospace;background-color:rgb(250,250,250)"><font color=
=3D"#000000">=C2=A0 =C2=A0 =C2=A0 =C2=A0 } else if constexpr(is_same_v&lt;c=
onst T2&amp;, decltype(v)&gt;) {</font></span></div><div><span style=3D"fon=
t-family:monospace;background-color:rgb(250,250,250)"><font color=3D"#00000=
0">=C2=A0 =C2=A0 =C2=A0 =C2=A0 } else {</font></span></div><div><span style=
=3D"font-family:monospace;background-color:rgb(250,250,250)"><font color=3D=
"#000000">=C2=A0 =C2=A0 =C2=A0 =C2=A0 }</font></span></div><div><span style=
=3D"font-family:monospace;color:rgb(102,102,0);background-color:rgb(250,250=
,250)">=C2=A0 =C2=A0 },</span><span style=3D"font-family:monospace;color:rg=
b(0,0,0);background-color:rgb(250,250,250)">=C2=A0v</span><span style=3D"fo=
nt-family:monospace;color:rgb(102,102,0);background-color:rgb(250,250,250)"=
>);</span><span style=3D"font-family:monospace;color:rgb(0,0,0);background-=
color:rgb(250,250,250)"><br></span><span style=3D"font-family:monospace;col=
or:rgb(102,102,0);background-color:rgb(250,250,250)">}</span><br></div><div=
><span style=3D"font-family:monospace;color:rgb(102,102,0);background-color=
:rgb(250,250,250)"></span></div></div></blockquote><div>Hmm... Great idea! =
But we have to wait for the new Standard.<br><span style=3D"font-family:mon=
ospace;color:rgb(102,102,0);background-color:rgb(250,250,250)"></span></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/138b02b5-c0b1-48e2-ae4a-15871c9003d0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/138b02b5-c0b1-48e2-ae4a-15871c9003d0=
%40isocpp.org</a>.<br />

------=_Part_66_1764274342.1471332653166--

------=_Part_65_668689120.1471332653166--

.

------=_Part_9191_292757874.1483276252934
Content-Type: multipart/alternative;
 boundary="----=_Part_9192_1207396999.1483276252935"

------=_Part_9192_1207396999.1483276252935
Content-Type: text/plain; charset=UTF-8

IS C++17 FIXING ANY OF THIS RETARDATION OR NOT?

NO?

OF COURSE NOT!

YOU FUCKING ASSHOLES, ESPECIALLY GOOGLE, MICROSOFT, AND APPLE, YOU'RE BEING
PAID TO GO TO WORK AND FIX THIS SHIT

YOU'RE TAKING A FUCKING SALARY FOR THIS SHIT

YOU ARE LITERALLY BEING PAID

AND YOU DON'T EVEN DO YOUR FUCKING JOB

LAZY ASSHOLES AT GOOGLE, MICROSOFT, APPLE DON'T GIVE A FLYING FUCK

IT'S GONNA BE THE YEAR 2033 BEFORE THIS FUCKING BULLSHIT IS FIXED

C++33

WHO GIVES A FUCK ANYMORE? JUST FORGET THE WHOLE THING

ASSHOLES....






On Wednesday, June 12, 2013 at 1:10:52 AM UTC-7, looseont...@gmail.com
wrote:
>
> Hi,
>
>
> template <class X> void f() {}
> template <> void f<int>() {}
> COMPILES
>
>
> struct S {
>     template <class X> void f() {}
>     template <> void f<int>() {}
> };
> --> error: explicit specialization of 'f' in class scope
> FUCKING RETARDED
> WOW IT REALLY MAKES SENSE THAT THIS WORKS AT GLOBAL SCOPE BUT NOT IN-CLASS
>
>
> struct S {
>     template <class X> struct Inner {};
>     template <> struct Inner<int> {};
> };
> --> error: explicit specialization of 'Inner' in class scope
> FUCKING RETARDED
>
>
> struct S {
>     template <class X, class = void> struct Inner {};
>     template <class bullshit> struct Inner<int, bullshit> {};
> };
> WOW, RETARDS, WORKS WITH A STUPID-RETARDED WORKAROUND
>
>
> struct S {
>     template <class X, class=void> void f() {}
>     template <class bullshit> void f<int, bullshit>() {}
> };
> --> function template partial specialization is not allowed
> FUCKING RETARDED
> WOW THE RETARDED WORKAROUND DOESN'T WORK FOR FUNCTIONS
>
>
> template <class X> void f(X x) {}
> template <class X> void f(X* x) {}
> OH, OK THIS GOOD
>
>
> template <class X, class Y> void f() {}
> template <class Y> void f<int, Y>() {}
> --> function template partial specialization is not allowed
> FUCKING RETARDED.
>
>
> I don't even want to hear 1 piece of bullshit out of a single one of you
> people's mouths about this one.
> If you give me one piece of bullshit, you're a fucking n00b.
>
> Every one of these things is used for metaprogramming.
>
> After 15 years of awareness about these problems, nothing was fixed.
> And now with C++14, yet another oversight release, we're heading for 20
> years of fucking retardation.
>
> Thank you standards body people for your retarded level of awareness, you
> fucking retards.
> Can you fix the holes you fucking retards?
>
>

--
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/ac4c9aa3-8064-40b1-80a6-e9c1ad032436%40isocpp.org.

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

<div dir=3D"ltr">IS C++17 FIXING ANY OF THIS RETARDATION OR NOT?<br><br>NO?=
<br><br>OF COURSE NOT!<br><br>YOU FUCKING ASSHOLES, ESPECIALLY GOOGLE, MICR=
OSOFT, AND APPLE, YOU&#39;RE BEING PAID TO GO TO WORK AND FIX THIS SHIT<br>=
<br>YOU&#39;RE TAKING A FUCKING SALARY FOR THIS SHIT<br><br>YOU ARE LITERAL=
LY BEING PAID<br><br>AND YOU DON&#39;T EVEN DO YOUR FUCKING JOB<br><br>LAZY=
 ASSHOLES AT GOOGLE, MICROSOFT, APPLE DON&#39;T GIVE A FLYING FUCK<br><br>I=
T&#39;S GONNA BE THE YEAR 2033 BEFORE THIS FUCKING BULLSHIT IS FIXED<br><br=
>C++33<br><br>WHO GIVES A FUCK ANYMORE? JUST FORGET THE WHOLE THING<br><br>=
ASSHOLES....<br><br><br><br><br><br><br>On Wednesday, June 12, 2013 at 1:10=
:52 AM UTC-7, looseont...@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>Hi,</div><div><br></div><div><br></div><div>template &lt;c=
lass X&gt; void f() {}</div><div>template &lt;&gt; void f&lt;int&gt;() {}</=
div><div>COMPILES</div><div><br></div><div><br></div><div>struct S {</div><=
div>=C2=A0 =C2=A0 template &lt;class X&gt; void f() {}</div><div>=C2=A0 =C2=
=A0 template &lt;&gt; void f&lt;int&gt;() {}</div><div>};</div><div>--&gt; =
error: explicit specialization of &#39;f&#39; in class scope</div><div>FUCK=
ING RETARDED</div><div>WOW IT REALLY MAKES SENSE THAT THIS WORKS AT GLOBAL =
SCOPE BUT NOT IN-CLASS</div><div><br></div><div><br></div><div>struct S {</=
div><div>=C2=A0 =C2=A0 template &lt;class X&gt; struct Inner {};</div><div>=
=C2=A0 =C2=A0 template &lt;&gt; struct Inner&lt;int&gt; {};</div><div>};</d=
iv><div>--&gt; error: explicit specialization of &#39;Inner&#39; in class s=
cope</div><div>FUCKING RETARDED</div><div><br></div><div><br></div><div>str=
uct S {</div><div>=C2=A0 =C2=A0 template &lt;class X, class =3D void&gt; st=
ruct Inner {};</div><div>=C2=A0 =C2=A0 template &lt;class bullshit&gt; stru=
ct Inner&lt;int, bullshit&gt; {};</div><div>};</div><div>WOW, RETARDS, WORK=
S WITH A STUPID-RETARDED WORKAROUND</div><div><br></div><div><br></div><div=
>struct S {</div><div>=C2=A0 =C2=A0 template &lt;class X, class=3Dvoid&gt; =
void f() {}</div><div>=C2=A0 =C2=A0 template &lt;class bullshit&gt; void f&=
lt;int, bullshit&gt;() {}</div><div>};</div><div>--&gt; function template p=
artial specialization is not allowed</div><div>FUCKING RETARDED</div><div>W=
OW THE RETARDED WORKAROUND DOESN&#39;T WORK FOR FUNCTIONS</div><div><br></d=
iv><div><br></div><div>template &lt;class X&gt; void f(X x) {}</div><div>te=
mplate &lt;class X&gt; void f(X* x) {}</div><div>OH, OK THIS GOOD</div><div=
><br></div><div><br></div><div>template &lt;class X, class Y&gt; void f() {=
}</div><div>template &lt;class Y&gt; void f&lt;int, Y&gt;() {}</div><div>--=
&gt; function template partial specialization is not allowed</div><div>FUCK=
ING RETARDED.</div><div><br></div><div><br></div><div>I don&#39;t even want=
 to hear 1 piece of bullshit out of a single one of you people&#39;s mouths=
 about this one.</div><div>If you give me one piece of bullshit, you&#39;re=
 a fucking n00b.</div><div><br></div><div>Every one of these things is used=
 for metaprogramming.</div><div><br></div><div>After 15 years of awareness =
about these problems, nothing was fixed.</div><div>And now with C++14, yet =
another oversight release, we&#39;re heading for 20 years of fucking retard=
ation.</div><div><br></div><div>Thank you standards body people for your re=
tarded level of awareness, you fucking retards.<br></div><div>Can you fix t=
he holes you fucking retards?</div><div><br></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/ac4c9aa3-8064-40b1-80a6-e9c1ad032436%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ac4c9aa3-8064-40b1-80a6-e9c1ad032436=
%40isocpp.org</a>.<br />

------=_Part_9192_1207396999.1483276252935--

------=_Part_9191_292757874.1483276252934--

.

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

@OP: Please consult a psychologist for your uncontrollable rage, and a
counsellor who can explain how your terrible way of trying to get  other
people to create your desires is completely counterproductive to your
chances of achieving them.

@mods: Please ban OP.

--
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/CACGiwhHrA99um0yisFpyXExCvMmBr7LaZye%3D%2Bw7Pa5-u_SGpvg%40mail.gmail.com.

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

<div dir=3D"ltr"><div>@OP: Please consult a psychologist for your uncontrol=
lable rage, and a counsellor who can explain how your terrible way of tryin=
g to get=C2=A0 other people to create your desires is completely counterpro=
ductive to your chances of achieving them.<br><br></div>@mods: Please ban O=
P.<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/CACGiwhHrA99um0yisFpyXExCvMmBr7LaZye%=
3D%2Bw7Pa5-u_SGpvg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhHrA99u=
m0yisFpyXExCvMmBr7LaZye%3D%2Bw7Pa5-u_SGpvg%40mail.gmail.com</a>.<br />

--047d7b86e2f8a521ac0545087a79--

.

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

As much of course as I do not approve of OP style, I can understand that
somebody could feel disappointed with C++17. It (C++17) is a mediocre (at
best) release. There was so much hope for it but at the end it ended up
being, well... not just mine thoughts:

http://mariusbancila.ro/blog/2016/03/07/c-17-standard-a-major-disappointment/

On Sun, Jan 1, 2017 at 1:33 PM, D. B. <db0451@gmail.com> wrote:

> @OP: Please consult a psychologist for your uncontrollable rage, and a
> counsellor who can explain how your terrible way of trying to get  other
> people to create your desires is completely counterproductive to your
> chances of achieving them.
>
> @mods: Please ban OP.
>
> --
> 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/CACGiwhHrA99um0yisFpyXExCvMmBr
> 7LaZye%3D%2Bw7Pa5-u_SGpvg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhHrA99um0yisFpyXExCvMmBr7LaZye%3D%2Bw7Pa5-u_SGpvg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>



--
Yours sincerely
Artur Czajkowski

--
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/CANPOWscdEp%3DSbdf9eHGQX%2BoV1ayAEQrvNZC-3ZGYcjB5p806_g%40mail.gmail.com.

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

<div dir=3D"ltr"><div>As much of course as I do not approve of OP style, I =
can understand that somebody could feel disappointed with C++17. It (C++17)=
 is a mediocre (at best) release. There was so much hope for it but at the =
end it ended up being, well... not just mine thoughts:</div><div><font size=
=3D"3"><p><a href=3D"http://mariusbancila.ro/blog/2016/03/07/c-17-standard-=
a-major-disappointment/">http://mariusbancila.ro/blog/2016/03/07/c-17-stand=
ard-a-major-disappointment/</a></p></font></div></div><div class=3D"gmail_e=
xtra"><br><div class=3D"gmail_quote">On Sun, Jan 1, 2017 at 1:33 PM, D. B. =
<span dir=3D"ltr">&lt;<a href=3D"mailto:db0451@gmail.com" target=3D"_blank"=
>db0451@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"><=
div dir=3D"ltr"><div>@OP: Please consult a psychologist for your uncontroll=
able rage, and a counsellor who can explain how your terrible way of trying=
 to get=C2=A0 other people to create your desires is completely counterprod=
uctive to your chances of achieving them.<br><br></div>@mods: Please ban OP=
..<br></div><span>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<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/CACGiwhHrA99um0yisFpyXExCvMmBr7LaZye%=
3D%2Bw7Pa5-u_SGpvg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/=
std-<wbr>proposals/<wbr>CACGiwhHrA99um0yisFpyXExCvMmBr<wbr>7LaZye%3D%2Bw7Pa=
5-u_SGpvg%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature">Yours sincerely<br>Artur Czajkow=
ski</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/CANPOWscdEp%3DSbdf9eHGQX%2BoV1ayAEQrv=
NZC-3ZGYcjB5p806_g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANPOWscdEp%3=
DSbdf9eHGQX%2BoV1ayAEQrvNZC-3ZGYcjB5p806_g%40mail.gmail.com</a>.<br />

--001a1134fc44d0dbac05451927c0--

.

On 8/11/16 6:02 AM, looseonthestreet@gmail.com wrote:
> Is even ANY of this retardation fixed in C++17?

Actually I think these are pretty good examples of the kind of
irregularities that C++ has that make much harder to use than it should be.

I also found the whole post quite hilarious.

I doubt he's trying to be funny - I'm sure he can't help himself.  And
of course he couldn't fix any of this stuff himself so it's pretty
pathetic.  I don't know if his style is a help or Independence.  It did
provoke me to respond, but that might be just me.

Don't have much more say.

Robert Ramey


--
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/fa68bbb7-38ca-107a-72ee-55078df77ffa%40rrsd.com.

.

------=_Part_810_2124877082.1483392815866
Content-Type: multipart/alternative;
 boundary="----=_Part_811_1822111921.1483392815866"

------=_Part_811_1822111921.1483392815866
Content-Type: text/plain; charset=UTF-8

On Monday, January 2, 2017 at 4:27:09 AM UTC-5, Arthur Tchaikovsky wrote:
>
> As much of course as I do not approve of OP style, I can understand that
> somebody could feel disappointed with C++17.
>

That is a completely different issue. Precisely none of the things that he
is complaining about (the ones that were not already fixed) were even
considered for C++17.


> It (C++17) is a mediocre (at best) release.
>

That is a matter of opinion. Between guaranteed elision, structured
binding, and `if constexpr`, I think we can put C++17 in the "win" column.

It's at least as much of a win as C++14.

--
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/942cd080-9c86-466b-bfcd-d2aba3354ecc%40isocpp.org.

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

<div dir=3D"ltr">On Monday, January 2, 2017 at 4:27:09 AM UTC-5, Arthur Tch=
aikovsky 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>As much of course as I do not approve of OP style, I can understand =
that somebody could feel disappointed with C++17.</div></div></blockquote><=
div><br>That is a completely different issue. Precisely none of the things =
that he is complaining about (the ones that were not already fixed) were ev=
en considered for C++17.<br>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><div>It (C++17) is a mediocre (at best) release.=
</div></div></blockquote><div><br>That is a matter of opinion. Between guar=
anteed elision, structured binding, and `if constexpr`, I think we can put =
C++17 in the &quot;win&quot; column.<br><br>It&#39;s at least as much of a =
win as C++14.</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/942cd080-9c86-466b-bfcd-d2aba3354ecc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/942cd080-9c86-466b-bfcd-d2aba3354ecc=
%40isocpp.org</a>.<br />

------=_Part_811_1822111921.1483392815866--

------=_Part_810_2124877082.1483392815866--

.

------=_Part_9072_1842281209.1483434924431
Content-Type: multipart/alternative;
 boundary="----=_Part_9073_891772320.1483434924431"

------=_Part_9073_891772320.1483434924431
Content-Type: text/plain; charset=UTF-8

It would be nice to fix this if possible (as Richard mentioned), I'll see
if I can pick it up. But surely you can solve this today by moving the
explicit instantiation outside the class. Your code should remain
unaffected otherwise, I think?

struct S {
    template <class X> void f() {}
};

template<>
void S::f<int>() {}

struct S2 {
    template <class X> struct Inner {};
};

template<>
struct S2::Inner<int> {};


On Wednesday, June 12, 2013 at 1:10:52 AM UTC-7, looseont...@gmail.com
wrote:
>
> Hi,
>
>
> template <class X> void f() {}
> template <> void f<int>() {}
> COMPILES
>
>
> struct S {
>     template <class X> void f() {}
>     template <> void f<int>() {}
> };
> --> error: explicit specialization of 'f' in class scope
> FUCKING RETARDED
> WOW IT REALLY MAKES SENSE THAT THIS WORKS AT GLOBAL SCOPE BUT NOT IN-CLASS
>
>
> struct S {
>     template <class X> struct Inner {};
>     template <> struct Inner<int> {};
> };
> --> error: explicit specialization of 'Inner' in class scope
> FUCKING RETARDED
>
>
> struct S {
>     template <class X, class = void> struct Inner {};
>     template <class bullshit> struct Inner<int, bullshit> {};
> };
> WOW, RETARDS, WORKS WITH A STUPID-RETARDED WORKAROUND
>
>
> struct S {
>     template <class X, class=void> void f() {}
>     template <class bullshit> void f<int, bullshit>() {}
> };
> --> function template partial specialization is not allowed
> FUCKING RETARDED
> WOW THE RETARDED WORKAROUND DOESN'T WORK FOR FUNCTIONS
>
>
> template <class X> void f(X x) {}
> template <class X> void f(X* x) {}
> OH, OK THIS GOOD
>
>
> template <class X, class Y> void f() {}
> template <class Y> void f<int, Y>() {}
> --> function template partial specialization is not allowed
> FUCKING RETARDED.
>
>
> I don't even want to hear 1 piece of bullshit out of a single one of you
> people's mouths about this one.
> If you give me one piece of bullshit, you're a fucking n00b.
>
> Every one of these things is used for metaprogramming.
>
> After 15 years of awareness about these problems, nothing was fixed.
> And now with C++14, yet another oversight release, we're heading for 20
> years of fucking retardation.
>
> Thank you standards body people for your retarded level of awareness, you
> fucking retards.
> Can you fix the holes you fucking retards?
>
>

--
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/30ce0e7c-6a60-41d0-a048-54bb1316bf59%40isocpp.org.

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

<div dir=3D"ltr">It would be nice to fix this if possible (as Richard menti=
oned), I&#39;ll see if I can pick it up. But surely you can solve this toda=
y by moving the explicit instantiation outside the class. Your code should =
remain unaffected otherwise, I think?=C2=A0<br><br><div>struct S {</div><di=
v>=C2=A0 =C2=A0 template &lt;class X&gt; void f() {}</div><div>};</div><div=
><br></div><div>template&lt;&gt;</div><div>void S::f&lt;int&gt;() {}</div><=
div><br></div><div>struct S2 {</div><div>=C2=A0 =C2=A0 template &lt;class X=
&gt; struct Inner {};</div><div>};<br></div><div><br></div><div>template&lt=
;&gt;</div><div>struct S2::Inner&lt;int&gt; {};</div><div><br></div><br>On =
Wednesday, June 12, 2013 at 1:10:52 AM UTC-7, looseont...@gmail.com wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div>Hi,</div><div><br></div><d=
iv><br></div><div>template &lt;class X&gt; void f() {}</div><div>template &=
lt;&gt; void f&lt;int&gt;() {}</div><div>COMPILES</div><div><br></div><div>=
<br></div><div>struct S {</div><div>=C2=A0 =C2=A0 template &lt;class X&gt; =
void f() {}</div><div>=C2=A0 =C2=A0 template &lt;&gt; void f&lt;int&gt;() {=
}</div><div>};</div><div>--&gt; error: explicit specialization of &#39;f&#3=
9; in class scope</div><div>FUCKING RETARDED</div><div>WOW IT REALLY MAKES =
SENSE THAT THIS WORKS AT GLOBAL SCOPE BUT NOT IN-CLASS</div><div><br></div>=
<div><br></div><div>struct S {</div><div>=C2=A0 =C2=A0 template &lt;class X=
&gt; struct Inner {};</div><div>=C2=A0 =C2=A0 template &lt;&gt; struct Inne=
r&lt;int&gt; {};</div><div>};</div><div>--&gt; error: explicit specializati=
on of &#39;Inner&#39; in class scope</div><div>FUCKING RETARDED</div><div><=
br></div><div><br></div><div>struct S {</div><div>=C2=A0 =C2=A0 template &l=
t;class X, class =3D void&gt; struct Inner {};</div><div>=C2=A0 =C2=A0 temp=
late &lt;class bullshit&gt; struct Inner&lt;int, bullshit&gt; {};</div><div=
>};</div><div>WOW, RETARDS, WORKS WITH A STUPID-RETARDED WORKAROUND</div><d=
iv><br></div><div><br></div><div>struct S {</div><div>=C2=A0 =C2=A0 templat=
e &lt;class X, class=3Dvoid&gt; void f() {}</div><div>=C2=A0 =C2=A0 templat=
e &lt;class bullshit&gt; void f&lt;int, bullshit&gt;() {}</div><div>};</div=
><div>--&gt; function template partial specialization is not allowed</div><=
div>FUCKING RETARDED</div><div>WOW THE RETARDED WORKAROUND DOESN&#39;T WORK=
 FOR FUNCTIONS</div><div><br></div><div><br></div><div>template &lt;class X=
&gt; void f(X x) {}</div><div>template &lt;class X&gt; void f(X* x) {}</div=
><div>OH, OK THIS GOOD</div><div><br></div><div><br></div><div>template &lt=
;class X, class Y&gt; void f() {}</div><div>template &lt;class Y&gt; void f=
&lt;int, Y&gt;() {}</div><div>--&gt; function template partial specializati=
on is not allowed</div><div>FUCKING RETARDED.</div><div><br></div><div><br>=
</div><div>I don&#39;t even want to hear 1 piece of bullshit out of a singl=
e one of you people&#39;s mouths about this one.</div><div>If you give me o=
ne piece of bullshit, you&#39;re a fucking n00b.</div><div><br></div><div>E=
very one of these things is used for metaprogramming.</div><div><br></div><=
div>After 15 years of awareness about these problems, nothing was fixed.</d=
iv><div>And now with C++14, yet another oversight release, we&#39;re headin=
g for 20 years of fucking retardation.</div><div><br></div><div>Thank you s=
tandards body people for your retarded level of awareness, you fucking reta=
rds.<br></div><div>Can you fix the holes you fucking retards?</div><div><br=
></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/30ce0e7c-6a60-41d0-a048-54bb1316bf59%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/30ce0e7c-6a60-41d0-a048-54bb1316bf59=
%40isocpp.org</a>.<br />

------=_Part_9073_891772320.1483434924431--

------=_Part_9072_1842281209.1483434924431--

.

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

@Nicol Bolas
 > Between guaranteed elision, structured binding, and `if constexpr`, I
think we can put C++17 in the "win" column.
 >It's at least as much of a win as C++14.
C++14 was a minor release and for a minor release that is a good score, but
C++17 was supposed to be a major release yet it feels either like a
weak major release or as you pointed out minor release which can be put
into 'win' column.
And of course it is a matter of a personal opinion, but the opinion is
echoed by many voices, like for example Michael Wong, who himself says in
one of his talks, that C++17 is at best OK. One can actually argue now,
that OK is a win, but one would also have to listen to that talk given by
Michael and hear the way he said the word OK.
Anyway, for me C++ for the reasons mentioned in my previous post(if one
follows the link provided) is a mediocre release with many major very
anticipated features not making into this standard.

On Mon, Jan 2, 2017 at 9:33 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Monday, January 2, 2017 at 4:27:09 AM UTC-5, Arthur Tchaikovsky wrote:
>>
>> As much of course as I do not approve of OP style, I can understand that
>> somebody could feel disappointed with C++17.
>>
>
> That is a completely different issue. Precisely none of the things that he
> is complaining about (the ones that were not already fixed) were even
> considered for C++17.
>
>
>> It (C++17) is a mediocre (at best) release.
>>
>
> That is a matter of opinion. Between guaranteed elision, structured
> binding, and `if constexpr`, I think we can put C++17 in the "win" column.
>
> It's at least as much of a win as C++14.
>
> --
> 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/942cd080-9c86-466b-
> bfcd-d2aba3354ecc%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/942cd080-9c86-466b-bfcd-d2aba3354ecc%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>



--
Yours sincerely
Artur Czajkowski

--
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/CANPOWsfhKvzvSWKwCiEhp5ofXy_95maOvdOCVgz2_2hVAPBGSg%40mail.gmail.com.

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

<div dir=3D"ltr"><div>@Nicol Bolas</div><div>=C2=A0&gt;=C2=A0Between guaran=
teed elision, structured binding, and `if constexpr`, I think we can put C+=
+17 in the &quot;win&quot; column.<br>=C2=A0&gt;It&#39;s at least as much o=
f a win as C++14.</div><div>C++14 was a minor release and for a minor relea=
se that is a good score, but C++17 was supposed to be=C2=A0a major release =
yet it feels either like=C2=A0a weak=C2=A0major release or as you pointed o=
ut minor release which can be put into &#39;win&#39; column.</div><div>And =
of course it is a matter of a personal opinion, but the opinion is echoed b=
y many voices, like for example Michael Wong, who himself says in one of hi=
s talks, that C++17 is at best=C2=A0OK. One can actually argue now, that OK=
 is a win, but one would also have to listen to that talk given by Michael =
and hear the way he said the word OK.</div><div>Anyway, for me C++ for the =
reasons mentioned in my previous post(if one follows the link provided) is =
a mediocre release with many major very anticipated features not making int=
o this standard.</div></div><div class=3D"gmail_extra"><br><div class=3D"gm=
ail_quote">On Mon, Jan 2, 2017 at 9:33 PM, Nicol Bolas <span dir=3D"ltr">&l=
t;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.=
com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><span>On Monday, January 2, 2017 at 4:27:09 AM UTC-5, Arthur Tchaikovsky =
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>As much=
 of course as I do not approve of OP style, I can understand that somebody =
could feel disappointed with C++17.</div></div></blockquote></span><div><br=
>That is a completely different issue. Precisely none of the things that he=
 is complaining about (the ones that were not already fixed) were even cons=
idered for C++17.<br>=C2=A0</div><span><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><div>It (C++17) is a mediocre (at best) release.</div>=
</div></blockquote></span><div><br>That is a matter of opinion. Between gua=
ranteed elision, structured binding, and `if constexpr`, I think we can put=
 C++17 in the &quot;win&quot; column.<br><br>It&#39;s at least as much of a=
 win as C++14.</div></div><span>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<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/942cd080-9c86-466b-bfcd-d2aba3354ecc%=
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/942c=
d080-9c86-466b-<wbr>bfcd-d2aba3354ecc%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">Yours sincerely<br>Artur Czajkow=
ski</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/CANPOWsfhKvzvSWKwCiEhp5ofXy_95maOvdOC=
Vgz2_2hVAPBGSg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANPOWsfhKvzvSWKw=
CiEhp5ofXy_95maOvdOCVgz2_2hVAPBGSg%40mail.gmail.com</a>.<br />

--001a113d5a7248f77605452d8a84--

.

 I find it difficult to agree with the original poster that C++ is a
"total retardation", but there are quirks in the language - also
quirks not inherited from C.
Fixing them would make using C++ easier, but luckily many of these
quirks occur in obscure places where you probably already is (or will
become) an expert if you go that path.
Wrt. C++17, I am also slightly disappointed, but still find it to be a
good release. constexpr if will be a great help to many of us. Also do
not forget that stuff implemented in a TS. This is much better than
having nothing.

/Peter

On Tue, Jan 3, 2017 at 10:46 AM, Arthur Tchaikovsky <atch.cpp@gmail.com> wrote:
> @Nicol Bolas
>  > Between guaranteed elision, structured binding, and `if constexpr`, I
> think we can put C++17 in the "win" column.
>  >It's at least as much of a win as C++14.
> C++14 was a minor release and for a minor release that is a good score, but
> C++17 was supposed to be a major release yet it feels either like a weak
> major release or as you pointed out minor release which can be put into
> 'win' column.
> And of course it is a matter of a personal opinion, but the opinion is
> echoed by many voices, like for example Michael Wong, who himself says in
> one of his talks, that C++17 is at best OK. One can actually argue now, that
> OK is a win, but one would also have to listen to that talk given by Michael
> and hear the way he said the word OK.
> Anyway, for me C++ for the reasons mentioned in my previous post(if one
> follows the link provided) is a mediocre release with many major very
> anticipated features not making into this standard.
>
> On Mon, Jan 2, 2017 at 9:33 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>>
>> On Monday, January 2, 2017 at 4:27:09 AM UTC-5, Arthur Tchaikovsky wrote:
>>>
>>> As much of course as I do not approve of OP style, I can understand that
>>> somebody could feel disappointed with C++17.
>>
>>
>> That is a completely different issue. Precisely none of the things that he
>> is complaining about (the ones that were not already fixed) were even
>> considered for C++17.
>>
>>>
>>> It (C++17) is a mediocre (at best) release.
>>
>>
>> That is a matter of opinion. Between guaranteed elision, structured
>> binding, and `if constexpr`, I think we can put C++17 in the "win" column.
>>
>> It's at least as much of a win as C++14.
>>
>> --
>> 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/942cd080-9c86-466b-bfcd-d2aba3354ecc%40isocpp.org.
>
>
>
>
> --
> Yours sincerely
> Artur Czajkowski
>
> --
> 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/CANPOWsfhKvzvSWKwCiEhp5ofXy_95maOvdOCVgz2_2hVAPBGSg%40mail.gmail.com.

--
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/CANPtknwsG1LQfgs8phonZ4mrZmNm%2BogczTpanRMCm0M-EkLy4A%40mail.gmail.com.

.

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

@Peter Koch Larsen
>still find it to be a
>good release. constexpr if will be a great help to many of us. Also do
>not forget that stuff implemented in a TS. This is much better than
>having nothing.

I also agree that is better to have something than nothing, but all the
above doesn't mean that this is a good release. It is mediocre, majority of
the most important features are not in C++17. This is a HUGE disappointment
and I believe those were the features that were 'defining' quality of the
C++17. Without them C++17 is yet another half baked, minor release. Big
disappointment from the point of view that so many important and awaited
for features didn't make it.
/Artur

On Tue, Jan 3, 2017 at 10:30 AM, Peter Koch Larsen <
peter.koch.larsen@gmail.com> wrote:

>  I find it difficult to agree with the original poster that C++ is a
> "total retardation", but there are quirks in the language - also
> quirks not inherited from C.
> Fixing them would make using C++ easier, but luckily many of these
> quirks occur in obscure places where you probably already is (or will
> become) an expert if you go that path.
> Wrt. C++17, I am also slightly disappointed, but still find it to be a
> good release. constexpr if will be a great help to many of us. Also do
> not forget that stuff implemented in a TS. This is much better than
> having nothing.
>
> /Peter
>
> On Tue, Jan 3, 2017 at 10:46 AM, Arthur Tchaikovsky <atch.cpp@gmail.com>
> wrote:
> > @Nicol Bolas
> >  > Between guaranteed elision, structured binding, and `if constexpr`, I
> > think we can put C++17 in the "win" column.
> >  >It's at least as much of a win as C++14.
> > C++14 was a minor release and for a minor release that is a good score,
> but
> > C++17 was supposed to be a major release yet it feels either like a weak
> > major release or as you pointed out minor release which can be put into
> > 'win' column.
> > And of course it is a matter of a personal opinion, but the opinion is
> > echoed by many voices, like for example Michael Wong, who himself says in
> > one of his talks, that C++17 is at best OK. One can actually argue now,
> that
> > OK is a win, but one would also have to listen to that talk given by
> Michael
> > and hear the way he said the word OK.
> > Anyway, for me C++ for the reasons mentioned in my previous post(if one
> > follows the link provided) is a mediocre release with many major very
> > anticipated features not making into this standard.
> >
> > On Mon, Jan 2, 2017 at 9:33 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> >>
> >> On Monday, January 2, 2017 at 4:27:09 AM UTC-5, Arthur Tchaikovsky
> wrote:
> >>>
> >>> As much of course as I do not approve of OP style, I can understand
> that
> >>> somebody could feel disappointed with C++17.
> >>
> >>
> >> That is a completely different issue. Precisely none of the things that
> he
> >> is complaining about (the ones that were not already fixed) were even
> >> considered for C++17.
> >>
> >>>
> >>> It (C++17) is a mediocre (at best) release.
> >>
> >>
> >> That is a matter of opinion. Between guaranteed elision, structured
> >> binding, and `if constexpr`, I think we can put C++17 in the "win"
> column.
> >>
> >> It's at least as much of a win as C++14.
> >>
> >> --
> >> 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/942cd080-9c86-466b-bfcd-d2aba3354ecc%40isocpp.org.
> >
> >
> >
> >
> > --
> > Yours sincerely
> > Artur Czajkowski
> >
> > --
> > 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/
> CANPOWsfhKvzvSWKwCiEhp5ofXy_95maOvdOCVgz2_2hVAPBGSg%40mail.gmail.com.
>
> --
> 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/CANPtknwsG1LQfgs8phonZ4mrZmNm%
> 2BogczTpanRMCm0M-EkLy4A%40mail.gmail.com.
>



--
Yours sincerely
Artur Czajkowski

--
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/CANPOWsd5DAgWP4d6RT838U3pdDmEDYKpc3TAkRQgyfXwo%2BQgqw%40mail.gmail.com.

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

<div dir=3D"ltr"><div>@Peter Koch Larsen</div><div>&gt;still find it to be =
a<br> &gt;good release. constexpr if will be a great help to many of us. Al=
so do<br> &gt;not forget that stuff implemented in a TS. This is much bette=
r than<br> &gt;having nothing.</div><div><br></div><div>I also agree that i=
s better to have something than nothing, but all the above doesn&#39;t mean=
 that this is a good release. It is mediocre, majority of the most importan=
t features are not in C++17. This is a HUGE disappointment and I believe th=
ose were the features that were &#39;defining&#39; quality of the C++17. Wi=
thout them C++17 is yet another half baked, minor release. Big disappointme=
nt from the point of view that so many important and awaited for features d=
idn&#39;t make it.</div><div>/Artur<br></div></div><div class=3D"gmail_extr=
a"><br><div class=3D"gmail_quote">On Tue, Jan 3, 2017 at 10:30 AM, Peter Ko=
ch Larsen <span dir=3D"ltr">&lt;<a href=3D"mailto:peter.koch.larsen@gmail.c=
om" target=3D"_blank">peter.koch.larsen@gmail.com</a>&gt;</span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">=C2=A0I find it difficult to agree with the =
original poster that C++ is a<br>
&quot;total retardation&quot;, but there are quirks in the language - also<=
br>
quirks not inherited from C.<br>
Fixing them would make using C++ easier, but luckily many of these<br>
quirks occur in obscure places where you probably already is (or will<br>
become) an expert if you go that path.<br>
Wrt. C++17, I am also slightly disappointed, but still find it to be a<br>
good release. constexpr if will be a great help to many of us. Also do<br>
not forget that stuff implemented in a TS. This is much better than<br>
having nothing.<br>
<br>
/Peter<br>
<div><div class=3D"h5"><br>
On Tue, Jan 3, 2017 at 10:46 AM, Arthur Tchaikovsky &lt;<a href=3D"mailto:a=
tch.cpp@gmail.com">atch.cpp@gmail.com</a>&gt; wrote:<br>
&gt; @Nicol Bolas<br>
&gt;=C2=A0 &gt; Between guaranteed elision, structured binding, and `if con=
stexpr`, I<br>
&gt; think we can put C++17 in the &quot;win&quot; column.<br>
&gt;=C2=A0 &gt;It&#39;s at least as much of a win as C++14.<br>
&gt; C++14 was a minor release and for a minor release that is a good score=
, but<br>
&gt; C++17 was supposed to be a major release yet it feels either like a we=
ak<br>
&gt; major release or as you pointed out minor release which can be put int=
o<br>
&gt; &#39;win&#39; column.<br>
&gt; And of course it is a matter of a personal opinion, but the opinion is=
<br>
&gt; echoed by many voices, like for example Michael Wong, who himself says=
 in<br>
&gt; one of his talks, that C++17 is at best OK. One can actually argue now=
, that<br>
&gt; OK is a win, but one would also have to listen to that talk given by M=
ichael<br>
&gt; and hear the way he said the word OK.<br>
&gt; Anyway, for me C++ for the reasons mentioned in my previous post(if on=
e<br>
&gt; follows the link provided) is a mediocre release with many major very<=
br>
&gt; anticipated features not making into this standard.<br>
&gt;<br>
&gt; On Mon, Jan 2, 2017 at 9:33 PM, Nicol Bolas &lt;<a href=3D"mailto:jmck=
esson@gmail.com">jmckesson@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On Monday, January 2, 2017 at 4:27:09 AM UTC-5, Arthur Tchaikovsky=
 wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; As much of course as I do not approve of OP style, I can under=
stand that<br>
&gt;&gt;&gt; somebody could feel disappointed with C++17.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; That is a completely different issue. Precisely none of the things=
 that he<br>
&gt;&gt; is complaining about (the ones that were not already fixed) were e=
ven<br>
&gt;&gt; considered for C++17.<br>
&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; It (C++17) is a mediocre (at best) release.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; That is a matter of opinion. Between guaranteed elision, structure=
d<br>
&gt;&gt; binding, and `if constexpr`, I think we can put C++17 in the &quot=
;win&quot; column.<br>
&gt;&gt;<br>
&gt;&gt; It&#39;s at least as much of a win as C++14.<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; You received this message because you are subscribed to the Google=
 Groups<br>
&gt;&gt; &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt;&gt; To unsubscribe from this group and stop receiving emails from it, =
send an<br>
&gt;&gt; email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org"=
>std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
&gt;&gt; To post to this group, send email to <a href=3D"mailto:std-proposa=
ls@isocpp.org">std-proposals@isocpp.org</a>.<br>
&gt;&gt; To view this discussion on the web visit<br>
&gt;&gt; <a href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-prop=
osals/942cd080-9c86-466b-bfcd-d2aba3354ecc%40isocpp.org" target=3D"_blank" =
rel=3D"noreferrer">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-=
<wbr>proposals/942cd080-9c86-466b-<wbr>bfcd-d2aba3354ecc%40isocpp.org</a><w=
br>.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Yours sincerely<br>
&gt; Artur Czajkowski<br>
&gt;<br>
&gt; --<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups<br>
&gt; &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an<br>
&gt; email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std=
-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; To view this discussion on the web visit<br>
</div></div>&gt; <a href=3D"https://groups.google.com/a/isocpp.org/d/msgid/=
std-proposals/CANPOWsfhKvzvSWKwCiEhp5ofXy_95maOvdOCVgz2_2hVAPBGSg%40mail.gm=
ail.com" target=3D"_blank" rel=3D"noreferrer">https://groups.google.com/a/<=
wbr>isocpp.org/d/msgid/std-<wbr>proposals/<wbr>CANPOWsfhKvzvSWKwCiEhp5ofXy_=
<wbr>95maOvdOCVgz2_2hVAPBGSg%<wbr>40mail.gmail.com</a>.<br>
<span><br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/CANPtknwsG1LQfgs8phonZ4mrZmNm%=
2BogczTpanRMCm0M-EkLy4A%40mail.gmail.com" target=3D"_blank" rel=3D"noreferr=
er">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/=
<wbr>CANPtknwsG1LQfgs8phonZ4mrZmNm%<wbr>2BogczTpanRMCm0M-EkLy4A%<wbr>40mail=
..gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature">Yours sincerely<br>Artur Czajkow=
ski</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/CANPOWsd5DAgWP4d6RT838U3pdDmEDYKpc3TA=
kRQgyfXwo%2BQgqw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANPOWsd5DAgWP4=
d6RT838U3pdDmEDYKpc3TAkRQgyfXwo%2BQgqw%40mail.gmail.com</a>.<br />

--001a11351b26448372054531272b--

.

On segunda-feira, 2 de janeiro de 2017 13:33:35 BRST Nicol Bolas wrote:
> That is a matter of opinion. Between guaranteed elision, structured
> binding, and `if constexpr`, I think we can put C++17 in the "win" column.

Fold expressions too.

--
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/82492644.7pBTg8DBrO%40tjmaciei-mobl1.

.

------=_Part_2413_819131802.1483454948236
Content-Type: multipart/alternative;
 boundary="----=_Part_2414_727001447.1483454948236"

------=_Part_2414_727001447.1483454948236
Content-Type: text/plain; charset=UTF-8

On Tuesday, January 3, 2017 at 9:04:59 AM UTC-5, Arthur Tchaikovsky wrote:
>
> @Peter Koch Larsen
> >still find it to be a
> >good release. constexpr if will be a great help to many of us. Also do
> >not forget that stuff implemented in a TS. This is much better than
> >having nothing.
>
> I also agree that is better to have something than nothing, but all the
> above doesn't mean that this is a good release. It is mediocre, majority of
> the most important features are not in C++17. This is a HUGE disappointment
> and I believe those were the features that were 'defining' quality of the
> C++17.
>

I think part of the problem with the "HUGE disappointment" is that people
were expecting things from C++17 that were, realistically speaking, *not
gonna happen*.

For example, in mid-2015, Bjarne posted his top-10 list of things he wanted
in C++17 <http://wg21.link/N4492>, and people instantly took that as some
kind of measuring tool to decide whether C++17 was good enough or not. But
quite frankly, Stroustrup's top-10 list was ridiculously optimistic.

Several topic he cited were things that were just *not gonna happen*, and
that should have been apparent to everyone in mid-2015. Modules and
contracts were way too early, both involving a great deal of complexity and
precisely *zero* implementation experience. Those were not going into C++17
and it should have been quite obvious in mid-2015 that this was the case.

Ranges are dependent on concepts, so when that was pushed back, ranges
clearly weren't going in.

So if you scrub out the unrealistic expectations, what's left to be
disappointed by in C++17? From my perspective, the remain basis for
disappointment would be on concepts and UCS.

The lack of unified call syntax is certainly disappointing and aggravating.
But at the same time, it didn't happen because of laziness or stupidity
from the committee (well, not just because of that). It happened in part
because C++ is really complex when it comes to functions, and the
implications of either transformation form are really complicated. Whatever
we pick has to work; we can't back it out and fix it after the fact.

UCS *needs to be right*, and if that means it takes a bit longer, so be it.
Compare this to "uniform initialization", which is a consistent and painful
thorn in our side to this day. We don't need another one of those.

And something similar goes to concepts, though personally, I feel that's as
much about certain unfortunate design decisions in Concepts TS as the
complexity of the feature. At the same time, it's important to highly just
how much implementation experience *matters* here. The Range TS represents
our first real usage of concepts, and what does it tell us?

It gives us evidence that template induction syntax is *not a good idea*;
the Ranges TS *never* uses it. It gives us evidence that having two forms
of concept definition forms is *not a useful idea*; Ranges TS picks one
form and consistently uses it.

C++ would be a poorer language if we had just accepted Concepts TS as is
for C++17. That usage experience is invaluable and hopefully will shape
Concepts TS into a much better piece of functionality.

--
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/b1bd77d8-b5d7-41b2-a457-83870c243e80%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, January 3, 2017 at 9:04:59 AM UTC-5, Arthur Tc=
haikovsky 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>@Peter Koch Larsen</div><div>&gt;still find it to be a<br> &gt;good=
 release. constexpr if will be a great help to many of us. Also do<br> &gt;=
not forget that stuff implemented in a TS. This is much better than<br> &gt=
;having nothing.</div><div><br></div><div>I also agree that is better to ha=
ve something than nothing, but all the above doesn&#39;t mean that this is =
a good release. It is mediocre, majority of the most important features are=
 not in C++17. This is a HUGE disappointment and I believe those were the f=
eatures that were &#39;defining&#39; quality of the C++17.</div></div></blo=
ckquote><div><br>I think part of the problem with the &quot;HUGE disappoint=
ment&quot; is that people were expecting things from C++17 that were, reali=
stically speaking, <i>not gonna happen</i>.<br><br>For example, in mid-2015=
, Bjarne posted his <a href=3D"http://wg21.link/N4492">top-10 list of thing=
s he wanted in C++17</a>, and people instantly took that as some kind of me=
asuring tool to decide whether C++17 was good enough or not. But quite fran=
kly, Stroustrup&#39;s top-10 list was ridiculously optimistic.<br><br>Sever=
al topic he cited were things that were just <i>not gonna happen</i>, and t=
hat should have been apparent to everyone in mid-2015. Modules and contract=
s were way too early, both involving a great deal of complexity and precise=
ly <i>zero</i> implementation experience. Those were not going into C++17 a=
nd it should have been quite obvious in mid-2015 that this was the case.<br=
><br>Ranges are dependent on concepts, so when that was pushed back, ranges=
 clearly weren&#39;t going in.<br><br>So if you scrub out the unrealistic e=
xpectations, what&#39;s left to be disappointed by in C++17? From my perspe=
ctive, the remain basis for disappointment would be on concepts and UCS.<br=
><br>The lack of unified call syntax is certainly disappointing and aggrava=
ting. But at the same time, it didn&#39;t happen because of laziness or stu=
pidity from the committee (well, not just because of that). It happened in =
part because C++ is really complex when it comes to functions, and the impl=
ications of either transformation form are really complicated. Whatever we =
pick has to work; we can&#39;t back it out and fix it after the fact.<br><b=
r>UCS <i>needs to be right</i>, and if that means it takes a bit longer, so=
 be it. Compare this to &quot;uniform initialization&quot;, which is a cons=
istent and painful thorn in our side to this day. We don&#39;t need another=
 one of those.<br><br>And something similar goes to concepts, though person=
ally, I feel that&#39;s as much about certain unfortunate design decisions =
in Concepts TS as the complexity of the feature. At the same time, it&#39;s=
 important to highly just how much implementation experience <i>matters</i>=
 here. The Range TS represents our first real usage of concepts, and what d=
oes it tell us?<br><br>It gives us evidence that template induction syntax =
is <i>not a good idea</i>; the Ranges TS <i>never</i> uses it. It gives us =
evidence that having two forms of concept definition forms is <i>not a usef=
ul idea</i>; Ranges TS picks one form and consistently uses it.<br><br>C++ =
would be a poorer language if we had just accepted Concepts TS as is for C+=
+17. That usage experience is invaluable and hopefully will shape Concepts =
TS into a much better piece of functionality.<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/b1bd77d8-b5d7-41b2-a457-83870c243e80%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b1bd77d8-b5d7-41b2-a457-83870c243e80=
%40isocpp.org</a>.<br />

------=_Part_2414_727001447.1483454948236--

------=_Part_2413_819131802.1483454948236--

.

On 2017-01-03 15:49, Nicol Bolas wrote:
> On Tuesday, January 3, 2017 at 9:04:59 AM UTC-5, Arthur Tchaikovsky wrote:
>
>     @Peter Koch Larsen
>     >still find it to be a
>     >good release. constexpr if will be a great help to many of us. Also do
>     >not forget that stuff implemented in a TS. This is much better than
>     >having nothing.
>
>     I also agree that is better to have something than nothing, but all
>     the above doesn't mean that this is a good release. It is mediocre,
>     majority of the most important features are not in C++17. This is a
>     HUGE disappointment and I believe those were the features that were
>     'defining' quality of the C++17.
>
>
> I think part of the problem with the "HUGE disappointment" is that
> people were expecting things from C++17 that were, realistically
> speaking, /not gonna happen/.
>
> For example, in mid-2015, Bjarne posted his top-10 list of things he
> wanted in C++17 <http://wg21.link/N4492>, and people instantly took that
> as some kind of measuring tool to decide whether C++17 was good enough
> or not. But quite frankly, Stroustrup's top-10 list was ridiculously
> optimistic.
>
> Several topic he cited were things that were just /not gonna happen/,
> and that should have been apparent to everyone in mid-2015. Modules and
> contracts were way too early, both involving a great deal of complexity
> and precisely /zero/ implementation experience. Those were not going
> into C++17 and it should have been quite obvious in mid-2015 that this
> was the case.
>
> Ranges are dependent on concepts, so when that was pushed back, ranges
> clearly weren't going in.
>
> So if you scrub out the unrealistic expectations, what's left to be
> disappointed by in C++17? From my perspective, the remain basis for
> disappointment would be on concepts and UCS.
>

One source of disappointment is that after the scrubbing there isn't
very much left. 1-2 out of 10 really isn't that good.

What we might have here is the same case as the expected C++08 that
turned out to be C++11.

Perhaps we now get both a smaller C++17 and the real revision as  C++20.
And we don't have to wait another 3 years for the first part.


A major problem for the future is that now the expectations for C++20
will be MEGA HUGE...



 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/o4giir%24818%241%40blaine.gmane.org.

.

------=_Part_1094_221048479.1483464153231
Content-Type: multipart/alternative;
 boundary="----=_Part_1095_616052236.1483464153231"

------=_Part_1095_616052236.1483464153231
Content-Type: text/plain; charset=UTF-8



On Tuesday, January 3, 2017 at 11:13:41 AM UTC-5, Bo Persson wrote:
>
> On 2017-01-03 15:49, Nicol Bolas wrote:
> > On Tuesday, January 3, 2017 at 9:04:59 AM UTC-5, Arthur Tchaikovsky
> wrote:
> >
> >     @Peter Koch Larsen
> >     >still find it to be a
> >     >good release. constexpr if will be a great help to many of us. Also
> do
> >     >not forget that stuff implemented in a TS. This is much better than
> >     >having nothing.
> >
> >     I also agree that is better to have something than nothing, but all
> >     the above doesn't mean that this is a good release. It is mediocre,
> >     majority of the most important features are not in C++17. This is a
> >     HUGE disappointment and I believe those were the features that were
> >     'defining' quality of the C++17.
> >
> >
> > I think part of the problem with the "HUGE disappointment" is that
> > people were expecting things from C++17 that were, realistically
> > speaking, /not gonna happen/.
> >
> > For example, in mid-2015, Bjarne posted his top-10 list of things he
> > wanted in C++17 <http://wg21.link/N4492>, and people instantly took
> that
> > as some kind of measuring tool to decide whether C++17 was good enough
> > or not. But quite frankly, Stroustrup's top-10 list was ridiculously
> > optimistic.
> >
> > Several topic he cited were things that were just /not gonna happen/,
> > and that should have been apparent to everyone in mid-2015. Modules and
> > contracts were way too early, both involving a great deal of complexity
> > and precisely /zero/ implementation experience. Those were not going
> > into C++17 and it should have been quite obvious in mid-2015 that this
> > was the case.
> >
> > Ranges are dependent on concepts, so when that was pushed back, ranges
> > clearly weren't going in.
> >
> > So if you scrub out the unrealistic expectations, what's left to be
> > disappointed by in C++17? From my perspective, the remain basis for
> > disappointment would be on concepts and UCS.
> >
>
> One source of disappointment is that after the scrubbing there isn't
> very much left. 1-2 out of 10 really isn't that good.
>

My whole point is that you shouldn't be using Stroustrup's feature set as a
benchmark *at all*. It represented unrealistic expectations.

What we might have here is the same case as the expected C++08 that
> turned out to be C++11.
>

First, nobody expected a C++08; the earliest that was being hoped for was
'09.

Second, while sure there were some who were disappointed in the lack of
concepts or modules or whatever, C++11 did reinvent large parts of C++. It
added important tools that modern C++ programmers take for granted on a
daily basis.

C++17, while not on the same scale as C++11, is still a pretty meaty
release. When reviewing something, it is important to review what we
actually got, not what we didn't get.

Disappointment is a thing of the moment; what we *actually got* is what
will matter in 2018.

Perhaps we now get both a smaller C++17 and the real revision as  C++20.
> And we don't have to wait another 3 years for the first part.
>
> A major problem for the future is that now the expectations for C++20
> will be MEGA HUGE...
>

Expectations will only be "MEGA HUGE" if people are promised specific
things.

C++'s release cadence is now in line with agile development procedures: you
have regular releases, but you release whatever is *ready* at that time.
Rather than releasing when some aggregation of features is considered "MEGA
HUGE" enough, you release on a schedule.

This is the essential essence of what was wrong with Stroustrup's post: it
gave the false impression that C++17 was a bundle of features. The product
C++17 was actually going to be was whatever features were ready for the
2017 timeframe. People were therefore given the wrong expectations.

Agile development means you can't look to releases as being big or small.
You only look to them on schedule; what you get is what you get.

Manage your own expectations, and you won't be disappointed.

--
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/e068a395-d44d-49f6-a25e-6a534d915fba%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Tuesday, January 3, 2017 at 11:13:41 AM UTC-5, =
Bo Persson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2017-01-03=
 15:49, Nicol Bolas wrote:
<br>&gt; On Tuesday, January 3, 2017 at 9:04:59 AM UTC-5, Arthur Tchaikovsk=
y wrote:
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 @Peter Koch Larsen
<br>&gt; =C2=A0 =C2=A0 &gt;still find it to be a
<br>&gt; =C2=A0 =C2=A0 &gt;good release. constexpr if will be a great help =
to many of us. Also do
<br>&gt; =C2=A0 =C2=A0 &gt;not forget that stuff implemented in a TS. This =
is much better than
<br>&gt; =C2=A0 =C2=A0 &gt;having nothing.
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 I also agree that is better to have something than n=
othing, but all
<br>&gt; =C2=A0 =C2=A0 the above doesn&#39;t mean that this is a good relea=
se. It is mediocre,
<br>&gt; =C2=A0 =C2=A0 majority of the most important features are not in C=
++17. This is a
<br>&gt; =C2=A0 =C2=A0 HUGE disappointment and I believe those were the fea=
tures that were
<br>&gt; =C2=A0 =C2=A0 &#39;defining&#39; quality of the C++17.
<br>&gt;
<br>&gt;
<br>&gt; I think part of the problem with the &quot;HUGE disappointment&quo=
t; is that
<br>&gt; people were expecting things from C++17 that were, realistically
<br>&gt; speaking, /not gonna happen/.
<br>&gt;
<br>&gt; For example, in mid-2015, Bjarne posted his top-10 list of things =
he
<br>&gt; wanted in C++17 &lt;<a href=3D"http://wg21.link/N4492" target=3D"_=
blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.c=
om/url?q\x3dhttp%3A%2F%2Fwg21.link%2FN4492\x26sa\x3dD\x26sntz\x3d1\x26usg\x=
3dAFQjCNFdcsY0IsGJQmNZZbICWRbxjx_rMw&#39;;return true;" onclick=3D"this.hre=
f=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwg21.link%2FN4492\x26s=
a\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFdcsY0IsGJQmNZZbICWRbxjx_rMw&#39;;retur=
n true;">http://wg21.link/N4492</a>&gt;, and people instantly took that
<br>&gt; as some kind of measuring tool to decide whether C++17 was good en=
ough
<br>&gt; or not. But quite frankly, Stroustrup&#39;s top-10 list was ridicu=
lously
<br>&gt; optimistic.
<br>&gt;
<br>&gt; Several topic he cited were things that were just /not gonna happe=
n/,
<br>&gt; and that should have been apparent to everyone in mid-2015. Module=
s and
<br>&gt; contracts were way too early, both involving a great deal of compl=
exity
<br>&gt; and precisely /zero/ implementation experience. Those were not goi=
ng
<br>&gt; into C++17 and it should have been quite obvious in mid-2015 that =
this
<br>&gt; was the case.
<br>&gt;
<br>&gt; Ranges are dependent on concepts, so when that was pushed back, ra=
nges
<br>&gt; clearly weren&#39;t going in.
<br>&gt;
<br>&gt; So if you scrub out the unrealistic expectations, what&#39;s left =
to be
<br>&gt; disappointed by in C++17? From my perspective, the remain basis fo=
r
<br>&gt; disappointment would be on concepts and UCS.
<br>&gt;
<br>
<br>One source of disappointment is that after the scrubbing there isn&#39;=
t=20
<br>very much left. 1-2 out of 10 really isn&#39;t that good.<br></blockquo=
te><div><br>My whole point is that you shouldn&#39;t be using Stroustrup&#3=
9;s feature set as a benchmark <i>at all</i>. It represented unrealistic ex=
pectations.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
What we might have here is the same case as the expected C++08 that=20
<br>turned out to be C++11.<br></blockquote><div><br>First, nobody expected=
 a C++08; the earliest that was being hoped for was &#39;09.<br><br>Second,=
 while sure there were some who were disappointed in the lack of concepts o=
r modules or whatever, C++11 did reinvent large parts of C++. It added impo=
rtant tools that modern C++ programmers take for granted on a daily basis.<=
br><br>C++17, while not on the same scale as C++11, is still a pretty meaty=
 release. When reviewing something, it is important to review what we actua=
lly got, not what we didn&#39;t get.<br><br>Disappointment is a thing of th=
e moment; what we <i>actually got</i> is what will matter in 2018.<br><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">Perhaps we now get both a=
 smaller C++17 and the real revision as =C2=A0C++20.=20
<br>And we don&#39;t have to wait another 3 years for the first part.
<br>

<br>A major problem for the future is that now the expectations for C++20=
=20
<br>will be MEGA HUGE...
<br></blockquote><div><br>Expectations will only be &quot;MEGA HUGE&quot; i=
f people are promised specific things.<br><br>C++&#39;s release cadence is =
now in line with agile development procedures: you have regular releases, b=
ut you release whatever is <i>ready</i> at that time. Rather than releasing=
 when some aggregation of features is considered &quot;MEGA HUGE&quot; enou=
gh, you release on a schedule.<br><br>This is the essential essence of what=
 was wrong with Stroustrup&#39;s post: it gave the false impression that C+=
+17 was a bundle of features. The product C++17 was actually going to be wa=
s whatever features were ready for the 2017 timeframe. People were therefor=
e given the wrong expectations.<br><br>Agile development means you can&#39;=
t look to releases as being big or small. You only look to them on schedule=
; what you get is what you get.<br><br>Manage your own expectations, and yo=
u won&#39;t be disappointed.<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/e068a395-d44d-49f6-a25e-6a534d915fba%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e068a395-d44d-49f6-a25e-6a534d915fba=
%40isocpp.org</a>.<br />

------=_Part_1095_616052236.1483464153231--

------=_Part_1094_221048479.1483464153231--

.

On 2017-01-03 18:22, Nicol Bolas wrote:
>
 > [...]
>
> Agile development means you can't look to releases as being big or
> small. You only look to them on schedule; what you get is what you get.

And sometimes you can be slightly disappointed at what you get. Like
getting a new tie for christmas.  :-)

>
> Manage your own expectations, and you won't be disappointed.
>

"Oh, a new tie. Didn't expect that!"  ?



    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/o4gtl2%24buj%241%40blaine.gmane.org.

.

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

On 3 January 2017 at 01:46, Arthur Tchaikovsky <atch.cpp@gmail.com> wrote:

> @Nicol Bolas
>  > Between guaranteed elision, structured binding, and `if constexpr`, I
> think we can put C++17 in the "win" column.
>  >It's at least as much of a win as C++14.
> C++14 was a minor release and for a minor release that is a good score,
> but C++17 was supposed to be a major release yet it feels either like a
> weak major release or as you pointed out minor release which can be put
> into 'win' column.
>

Sorry, that's not accurate. C++ standardization is using a ship train
model; we ship every three years, and ship whatever's ready at that point.
We briefly discussed using a major/minor model, but that would imply either
holding major features back from "minor" revisions or blocking "major"
revisions until we have something major to ship (or both), and those are
not appealing options. (That said, C++17 does have several major features,
particularly in the standard library, which is exactly where they *should*
be -- we should not be changing the fundamental nature of the language
every 6 years!)

Please stop spreading this major/minor idea; that bad messaging is what has
created a lot of the disappointment I've seen people express in C++17.
Things will ship when they're ready; not before, not after (here, we use
TSs to ship important pieces faster than the three-year cycle of the IS).
If you want certain things ready sooner, you could get involved in the
committee process and help out.

And of course it is a matter of a personal opinion, but the opinion is
> echoed by many voices, like for example Michael Wong, who himself says in
> one of his talks, that C++17 is at best OK. One can actually argue now,
> that OK is a win, but one would also have to listen to that talk given by
> Michael and hear the way he said the word OK.
> Anyway, for me C++ for the reasons mentioned in my previous post(if one
> follows the link provided) is a mediocre release with many major very
> anticipated features not making into this standard.
>
> On Mon, Jan 2, 2017 at 9:33 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>> On Monday, January 2, 2017 at 4:27:09 AM UTC-5, Arthur Tchaikovsky wrote:
>>>
>>> As much of course as I do not approve of OP style, I can understand that
>>> somebody could feel disappointed with C++17.
>>>
>>
>> That is a completely different issue. Precisely none of the things that
>> he is complaining about (the ones that were not already fixed) were even
>> considered for C++17.
>>
>>
>>> It (C++17) is a mediocre (at best) release.
>>>
>>
>> That is a matter of opinion. Between guaranteed elision, structured
>> binding, and `if constexpr`, I think we can put C++17 in the "win" column.
>>
>> It's at least as much of a win as C++14.
>>
>> --
>> 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/is
>> ocpp.org/d/msgid/std-proposals/942cd080-9c86-466b-bfcd-
>> d2aba3354ecc%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/942cd080-9c86-466b-bfcd-d2aba3354ecc%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>
>
>
> --
> Yours sincerely
> Artur Czajkowski
>
> --
> 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/CANPOWsfhKvzvSWKwCiEhp5ofXy_
> 95maOvdOCVgz2_2hVAPBGSg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANPOWsfhKvzvSWKwCiEhp5ofXy_95maOvdOCVgz2_2hVAPBGSg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

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

--001a1145bc880794bb054535ecec
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 3=
 January 2017 at 01:46, Arthur Tchaikovsky <span dir=3D"ltr">&lt;<a href=3D=
"mailto:atch.cpp@gmail.com" target=3D"_blank">atch.cpp@gmail.com</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>@Nicol =
Bolas</div><span class=3D""><div>=C2=A0&gt;=C2=A0Between guaranteed elision=
, structured binding, and `if constexpr`, I think we can put C++17 in the &=
quot;win&quot; column.<br>=C2=A0&gt;It&#39;s at least as much of a win as C=
++14.</div></span><div>C++14 was a minor release and for a minor release th=
at is a good score, but C++17 was supposed to be=C2=A0a major release yet i=
t feels either like=C2=A0a weak=C2=A0major release or as you pointed out mi=
nor release which can be put into &#39;win&#39; column.</div></div></blockq=
uote><div><br></div><div>Sorry, that&#39;s not accurate. C++ standardizatio=
n is using a ship train model; we ship every three years, and ship whatever=
&#39;s ready at that point. We briefly discussed using a major/minor model,=
 but that would imply either holding major features back from &quot;minor&q=
uot; revisions or blocking &quot;major&quot; revisions until we have someth=
ing major to ship (or both), and those are not appealing options. (That sai=
d, C++17 does have several major features, particularly in the standard lib=
rary, which is exactly where they *should* be -- we should not be changing =
the fundamental nature of the language every 6 years!)</div><div><br></div>=
<div>Please stop spreading this major/minor idea; that bad messaging is wha=
t has created a lot of the disappointment I&#39;ve seen people express in C=
++17. Things will ship when they&#39;re ready; not before, not after (here,=
 we use TSs to ship important pieces faster than the three-year cycle of th=
e IS). If you want certain things ready sooner, you could get involved in t=
he committee process and help out.</div><div><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"><div>And of course it is a matter of a personal=
 opinion, but the opinion is echoed by many voices, like for example Michae=
l Wong, who himself says in one of his talks, that C++17 is at best=C2=A0OK=
.. One can actually argue now, that OK is a win, but one would also have to =
listen to that talk given by Michael and hear the way he said the word OK.<=
/div><div>Anyway, for me C++ for the reasons mentioned in my previous post(=
if one follows the link provided) is a mediocre release with many major ver=
y anticipated features not making into this standard.</div></div><div class=
=3D"gmail_extra"><div><div class=3D"h5"><br><div class=3D"gmail_quote">On M=
on, Jan 2, 2017 at 9:33 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</sp=
an> 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"><span>On Mond=
ay, January 2, 2017 at 4:27:09 AM UTC-5, Arthur Tchaikovsky 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"><div>As much of course as I=
 do not approve of OP style, I can understand that somebody could feel disa=
ppointed with C++17.</div></div></blockquote></span><div><br>That is a comp=
letely different issue. Precisely none of the things that he is complaining=
 about (the ones that were not already fixed) were even considered for C++1=
7.<br>=C2=A0</div><span><blockquote class=3D"gmail_quote" style=3D"margin:0=
;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr"><div>It (C++17) is a mediocre (at best) release.</div></div></blockqu=
ote></span><div><br>That is a matter of opinion. Between guaranteed elision=
, structured binding, and `if constexpr`, I think we can put C++17 in the &=
quot;win&quot; column.<br><br>It&#39;s at least as much of a win as C++14.<=
/div></div><span>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isoc<wbr>pp.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/942cd080-9c86-466b-bfcd-d2aba3354ecc%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/942c=
d080-9c86-466b-bfcd-<wbr>d2aba3354ecc%40isocpp.org</a>.<br>
</blockquote></div><br><br clear=3D"all"><br></div></div><span class=3D"">-=
- <br><div class=3D"m_8823766068165771204gmail_signature" data-smartmail=3D=
"gmail_signature">Yours sincerely<br>Artur Czajkowski</div>
</span></div>

<p></p>

-- <br><span class=3D"">
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
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/CANPOWsfhKvzvSWKwCiEhp5ofXy_95maOvdOC=
Vgz2_2hVAPBGSg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-=
<wbr>proposals/<wbr>CANPOWsfhKvzvSWKwCiEhp5ofXy_<wbr>95maOvdOCVgz2_2hVAPBGS=
g%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div><br></div></div>

<p></p>

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

--001a1145bc880794bb054535ecec--

.

------=_Part_37_393026082.1483474412766
Content-Type: multipart/alternative;
 boundary="----=_Part_38_1833513052.1483474412766"

------=_Part_38_1833513052.1483474412766
Content-Type: text/plain; charset=UTF-8

On Tuesday, January 3, 2017 at 2:46:21 PM UTC-5, Richard Smith wrote:
>
> If you want certain things ready sooner, you could get involved in the
> committee process and help out.
>

I don't buy that.

Admittedly, I've never been to a meeting. But from the outside looking in,
I don't get the impression that throwing more people at the committee will
make things get resolved faster. Would throwing more people at, for
example, comparison operator generation have really allowed it to get into
C++17? Could more people have resolved the various UCS issues and allowed
us to get that in C++17?

I just don't see how throwing more people at the problem will make things
move faster. If there is someone who's fundamentally against some aspect of
UCS or comparison operators or some such, you're probably only going to
find out at an actual meeting. And those only happen 3 times a year.

--
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/08220df1-0163-4887-983e-000416181698%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, January 3, 2017 at 2:46:21 PM UTC-5, Richard S=
mith 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"><d=
iv><div class=3D"gmail_quote"><div>If you want certain things ready sooner,=
 you could get involved in the committee process and help out.<br></div></d=
iv></div></div></blockquote><div><br>I don&#39;t buy that.<br><br>Admittedl=
y, I&#39;ve never been to a meeting. But from the outside looking in, I don=
&#39;t get the impression that throwing more people at the committee will m=
ake things get resolved faster. Would throwing more people at, for example,=
 comparison operator generation have really allowed it to get into C++17? C=
ould more people have resolved the various UCS issues and allowed us to get=
 that in C++17?<br><br>I just don&#39;t see how throwing more people at the=
 problem will make things move faster. If there is someone who&#39;s fundam=
entally against some aspect of UCS or comparison operators or some such, yo=
u&#39;re probably only going to find out at an actual meeting. And those on=
ly happen 3 times a year.<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/08220df1-0163-4887-983e-000416181698%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/08220df1-0163-4887-983e-000416181698=
%40isocpp.org</a>.<br />

------=_Part_38_1833513052.1483474412766--

------=_Part_37_393026082.1483474412766--

.

--Apple-Mail-D93D6F28-71AE-402A-8F13-BCFEF1AD6D86
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



> On 3 Jan 2017, at 20:13, Nicol Bolas <jmckesson@gmail.com> wrote:
>=20
>> On Tuesday, January 3, 2017 at 2:46:21 PM UTC-5, Richard Smith wrote:
>> If you want certain things ready sooner, you could get involved in the c=
ommittee process and help out.
>=20
> I don't buy that.
>=20
> Admittedly, I've never been to a meeting. But from the outside looking in=
, I don't get the impression that throwing more people at the committee wil=
l make things get resolved faster. Would throwing more people at, for examp=
le, comparison operator generation have really allowed it to get into C++17=
? Could more people have resolved the various UCS issues and allowed us to =
get that in C++17?
>=20

Turning up to meetings is io some value. Providing implementations and usag=
e examples would be really helpful.

> I just don't see how throwing more people at the problem will make things=
 move faster. If there is someone who's fundamentally against some aspect o=
f UCS or comparison operators or some such, you're probably only going to f=
ind out at an actual meeting. And those only happen 3 times a year.
> --=20
> You received this message because you are subscribed to the Google Groups=
 "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
 email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/08220df1-0163-4887-983e-000416181698%40isocpp.=
org.

--=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/D8BC601F-8BFF-46EC-AAD3-E6E2D0F4B8A9%40gmail.com=
..

--Apple-Mail-D93D6F28-71AE-402A-8F13-BCFEF1AD6D86
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div></div><div><br></div><div><br>On 3=
 Jan 2017, at 20:13, Nicol Bolas &lt;<a href=3D"mailto:jmckesson@gmail.com"=
>jmckesson@gmail.com</a>&gt; wrote:<br><br></div><blockquote type=3D"cite">=
<div><div dir=3D"ltr">On Tuesday, January 3, 2017 at 2:46:21 PM UTC-5, Rich=
ard Smith 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><div class=3D"gmail_quote"><div>If you want certain things ready so=
oner, you could get involved in the committee process and help out.<br></di=
v></div></div></div></blockquote><div><br>I don't buy that.<br><br>Admitted=
ly, I've never been to a meeting. But from the outside looking in, I don't =
get the impression that throwing more people at the committee will make thi=
ngs get resolved faster. Would throwing more people at, for example, compar=
ison operator generation have really allowed it to get into C++17? Could mo=
re people have resolved the various UCS issues and allowed us to get that i=
n C++17?<br><br></div></div></div></blockquote><div><br></div><div>Turning =
up to meetings is io some value. Providing implementations and usage exampl=
es would be really helpful.</div><br><blockquote type=3D"cite"><div><div di=
r=3D"ltr"><div>I just don't see how throwing more people at the problem wil=
l make things move faster. If there is someone who's fundamentally against =
some aspect of UCS or comparison operators or some such, you're probably on=
ly going to find out at an actual meeting. And those only happen 3 times a =
year.<br></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/08220df1-0163-4887-983e-000416181698%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/08220df1-0163-4887-983e-00041618=
1698%40isocpp.org</a>.<br>
</div></blockquote></body></html>

<p></p>

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

--Apple-Mail-D93D6F28-71AE-402A-8F13-BCFEF1AD6D86--

.

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

On Tue, Jan 3, 2017 at 3:13 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Tuesday, January 3, 2017 at 2:46:21 PM UTC-5, Richard Smith wrote:
>>
>> If you want certain things ready sooner, you could get involved in the
>> committee process and help out.
>>
>
> I don't buy that.
>
> Admittedly, I've never been to a meeting. But from the outside looking in,
> I don't get the impression that throwing more people at the committee will
> make things get resolved faster. Would throwing more people at, for
> example, comparison operator generation have really allowed it to get into
> C++17? Could more people have resolved the various UCS issues and allowed
> us to get that in C++17?
>

It depends on how the aid takes place. I don't think that Richard
specifically means attendance at meetings -- I'd argue that the
participation of the individuals that takes place here in this forum, for
example, does have an overall positive effect, since concerns can be caught
early on before there is discussion at a meeting. You specifically as well
as others have been mentioned at meetings and in papers, and I certainly
don't think that this form of participation has unnecessarily slowed things
down. Similarly, if there is a proposal that someone is interested in
seeing sooner rather than later and they feel as though they personally
have the ability to contribute, they can contact the author of the proposal
directly with any contributions, or they can volunteer to aid as a
coauthor. For larger changes, an interested person can author their own
paper or papers in the domain (I can't really speak for those who are
deeply involved in TSs, but I don't think it's much of a stretch to imagine
that Andrew, Casey/Eric, etc. welcome [constructive] papers). An interested
developer can also implement changes proposed by someone else (whether
language or library level) -- I'd *love* for someone to volunteer to
implement my void proposal, for example, and it would certainly move things
along faster (in this case, that may imply either getting it into the
language faster or killing it off faster, either of which is useful for the
process).

While for certain things, such as bikeshedding, more people may do more
harm than good, there are also a lot of other ways to participate where
more people does not hinder the process.

--
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/CANh8DE%3DVjkg0of5_TwKji2WnhaPQtbBcM22uhB0n4SxB0qa0aw%40mail.gmail.com.

--94eb2c03bc9ca4ea39054536a3d8
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 T=
ue, Jan 3, 2017 at 3:13 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</sp=
an> 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"><span class=
=3D"">On Tuesday, January 3, 2017 at 2:46:21 PM UTC-5, Richard Smith wrote:=
<blockquote 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"><div>If you want certain things ready sooner, you could get i=
nvolved in the committee process and help out.<br></div></div></div></div><=
/blockquote></span><div><br>I don&#39;t buy that.<br><br>Admittedly, I&#39;=
ve never been to a meeting. But from the outside looking in, I don&#39;t ge=
t the impression that throwing more people at the committee will make thing=
s get resolved faster. Would throwing more people at, for example, comparis=
on operator generation have really allowed it to get into C++17? Could more=
 people have resolved the various UCS issues and allowed us to get that in =
C++17?<br></div></div></blockquote><div><br></div><div>It depends on how th=
e aid takes place. I don&#39;t think that Richard specifically means attend=
ance at meetings -- I&#39;d argue that the participation of the individuals=
 that takes place here in this forum, for example, does have an overall pos=
itive effect, since concerns can be caught early on before there is discuss=
ion at a meeting. You specifically as well as others have been mentioned at=
 meetings and in papers, and I certainly don&#39;t think that this form of =
participation has unnecessarily slowed things down. Similarly, if there is =
a proposal that someone is interested in seeing sooner rather than later an=
d they feel as though they personally have the ability to contribute, they =
can contact the author of the proposal directly with any contributions, or =
they can volunteer to aid as a coauthor. For larger changes, an interested =
person can author their own paper or papers in the domain (I can&#39;t real=
ly speak for those who are deeply involved in TSs, but I don&#39;t think it=
&#39;s much of a stretch to imagine that Andrew, Casey/Eric, etc. welcome [=
constructive] papers). An interested developer can also implement changes p=
roposed by someone else (whether language or library level) -- I&#39;d *lov=
e* for someone to volunteer to implement my void proposal, for example, and=
 it would certainly move things along faster (in this case, that may imply =
either getting it into the language faster or killing it off faster, either=
 of which is useful for the process).</div><div><br></div><div>While for ce=
rtain things, such as bikeshedding, more people may do more harm than good,=
 there are also a lot of other ways to participate where more people does n=
ot hinder the process.</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/CANh8DE%3DVjkg0of5_TwKji2WnhaPQtbBcM2=
2uhB0n4SxB0qa0aw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DE%3DVjkg0=
of5_TwKji2WnhaPQtbBcM22uhB0n4SxB0qa0aw%40mail.gmail.com</a>.<br />

--94eb2c03bc9ca4ea39054536a3d8--

.

On 01/03/2017 09:13 PM, Nicol Bolas wrote:
> Admittedly, I've never been to a meeting. But from the outside
> looking in, I don't get the impression that throwing more people at
> the committee will make things get resolved faster. Would throwing
> more people at, for example, comparison operator generation have
> really allowed it to get into C++17? Could more people have resolved
> the various UCS issues and allowed us to get that in C++17?

What's UCS?

Anyway, for comparison operators specifically, my impression is that
people have different expectations and put different emphasis on
"auto-generation" vs. "opt-in" and "how much existing code must
continue to work". As far as I can see, having someone that
modified a compiler with a specific set of default comparison
rules and ran it on a large codebase would have accelerated the
process.

Even just writing a paper summarizing the developments at the
N meetings where the topic was discussed (including seemingly
minority opinions) would have helped.

Jens

--
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/586C17A3.6070306%40gmx.net.

.

This is a multi-part message in MIME format.
--------------1E0271D78E6D8BAF6196D299
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 03/01/2017 =C3=A0 15:49, Nicol Bolas a =C3=A9crit :
> On Tuesday, January 3, 2017 at 9:04:59 AM UTC-5, Arthur Tchaikovsky=20
> wrote:
>
>     @Peter Koch Larsen
>     >still find it to be a
>     >good release. constexpr if will be a great help to many of us.
>     Also do
>     >not forget that stuff implemented in a TS. This is much better than
>     >having nothing.
>
>     I also agree that is better to have something than nothing, but
>     all the above doesn't mean that this is a good release. It is
>     mediocre, majority of the most important features are not in
>     C++17. This is a HUGE disappointment and I believe those were the
>     features that were 'defining' quality of the C++17.
>
>
Who care if it was a good or a bad release, a minor or major release.=20
This is almost already part of the past. We need to fix as much issues=20
as possible before releasing it and move on.

People that cares about having a major and good release for 2020, should=20
start now helping on the implementation of those features so that we=20
have more experience, refining/inspecting the proposals so that we are=20
able to catch most of the unavoidable issues, using them, writing blogs, ..=
..

Please stop complaining about this or that, most of the people that=20
participates on the elaboration of the standard are doing it on their=20
free time, and they work on the feature they consider they could help=20
the most.
> I think part of the problem with the "HUGE disappointment" is that=20
> people were expecting things from C++17 that were, realistically=20
> speaking, /not gonna happen/.
>
> For example, in mid-2015, Bjarne posted his top-10 list of things he=20
> wanted in C++17 <http://wg21.link/N4492>, and people instantly took=20
> that as some kind of measuring tool to decide whether C++17 was good=20
> enough or not. But quite frankly, Stroustrup's top-10 list was=20
> ridiculously optimistic.
>
> Several topic he cited were things that were just /not gonna happen/,=20
> and that should have been apparent to everyone in mid-2015. Modules=20
> and contracts were way too early, both involving a great deal of=20
> complexity and precisely /zero/ implementation experience. Those were=20
> not going into C++17 and it should have been quite obvious in mid-2015=20
> that this was the case.
IMHO, it was obvious in mid-2015 not all of these features could be on=20
C++17. Remind that the door was closed in Oulu (Jun 2016), only one year=20
later this announce was done. Please check the state of the proposal in=20
this list in mid-2015.

The train model doesn't consists in a minor a major release. It consists=20
in releases that are delivered every 3 years. A feature is part of a=20
release when it is ready, not before.

We have not done a bad release, and the release 2020 can start just now.

Vicente

P.S. This post is not a response to this specif post in the thread, but=20
about the global thread.

--=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/ce821fcc-d2ea-aee0-480d-8604b8f71d3e%40wanadoo.f=
r.

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 03/01/2017 =C3=A0 15:49, Nicol Bolas =
a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:b1bd77d8-b5d7-41b2-a457-83870c243e80@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">On Tuesday, January 3, 2017 at 9:04:59 AM UTC-5,
        Arthur Tchaikovsky 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>@Peter Koch Larsen</div>
            <div>&gt;still find it to be a<br>
              &gt;good release. constexpr if will be a great help to
              many of us. Also do<br>
              &gt;not forget that stuff implemented in a TS. This is
              much better than<br>
              &gt;having nothing.</div>
            <div><br>
            </div>
            <div>I also agree that is better to have something than
              nothing, but all the above doesn't mean that this is a
              good release. It is mediocre, majority of the most
              important features are not in C++17. This is a HUGE
              disappointment and I believe those were the features that
              were 'defining' quality of the C++17.</div>
          </div>
        </blockquote>
        <div><br>
        </div>
      </div>
    </blockquote>
    Who care if it was a good or a bad release, a minor or major
    release. This is almost already part of the past. We need to fix as
    much issues as possible before releasing it and move on.<br>
    <br>
    People that cares about having a major and good release for 2020,
    should start now helping on the implementation of those features so
    that we have more experience, refining/inspecting the proposals so
    that we are able to catch most of the unavoidable issues, using
    them, writing blogs, ...<br>
    <br>
    Please stop complaining about this or that, most of the people that
    participates on the elaboration of the standard are doing it on
    their free time, and they work on the feature they consider they
    could help the most. <br>
    <blockquote
      cite=3D"mid:b1bd77d8-b5d7-41b2-a457-83870c243e80@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>I think part of the problem with the "HUGE disappointment"
          is that people were expecting things from C++17 that were,
          realistically speaking, <i>not gonna happen</i>.<br>
          <br>
          For example, in mid-2015, Bjarne posted his <a
            moz-do-not-send=3D"true" href=3D"http://wg21.link/N4492">top-10
            list of things he wanted in C++17</a>, and people instantly
          took that as some kind of measuring tool to decide whether
          C++17 was good enough or not. But quite frankly, Stroustrup's
          top-10 list was ridiculously optimistic.<br>
          <br>
        </div>
      </div>
    </blockquote>
    <blockquote
      cite=3D"mid:b1bd77d8-b5d7-41b2-a457-83870c243e80@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>Several topic he cited were things that were just <i>not
            gonna happen</i>, and that should have been apparent to
          everyone in mid-2015. Modules and contracts were way too
          early, both involving a great deal of complexity and precisely
          <i>zero</i> implementation experience. Those were not going
          into C++17 and it should have been quite obvious in mid-2015
          that this was the case.<br>
        </div>
      </div>
    </blockquote>
    IMHO, it was obvious in mid-2015 not all of these features could be
    on C++17. Remind that the door was closed in Oulu (Jun 2016), only
    one year later this announce was done. Please check the state of the
    proposal in this list in mid-2015.<br>
    <br>
    The train model doesn't consists in a minor a major release. It
    consists in releases that are delivered every 3 years. A feature is
    part of a release when it is ready, not before.<br>
    <br>
    We have not done a bad release, and the release 2020 can start just
    now.<br>
    <br>
    Vicente<br>
    <br>
    P.S. This post is not a response to this specif post in the thread,
    but about the global thread.<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/ce821fcc-d2ea-aee0-480d-8604b8f71d3e%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ce821fcc-d2ea-aee0-480d-8604b8f71d3e=
%40wanadoo.fr</a>.<br />

--------------1E0271D78E6D8BAF6196D299--

.

------=_Part_1702_2046578116.1483487858219
Content-Type: multipart/alternative;
 boundary="----=_Part_1703_1795731550.1483487858219"

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

I don't think any of us, in our day jobs, appreciate managers who seem to=
=20
only put pressure on developers to release exciting and earthshaking new=20
features on arbitrary time scales based only on unwarranted expectations=20
and perceptions of promises the developers never made.  Especially when the=
=20
manager's timetables take no account of actual technical details with which=
=20
only the most active developers can be familiar enough as far as making=20
sure the implementation is actually feasible, or when the manager makes=20
which no consideration of avoiding regressions, writing proper tests,=20
integrating the new features well with existing functionality, not=20
surprising customers too much, not introducing concepts that will be=20
unteachable to customers, etc., etc.  But at least in such cases the=20
developers get paid for putting up with the nonsense.

Yet here many developers are doing much the same thing to the committee,=20
proposal writers, and implementors, who as has been pointed out, in many=20
cases are not even being paid for their efforts.  I'm extremely sympathetic=
=20
to the point that if developers are dissatisfied with progress, they can=20
roll up their own sleeves.  And it's not that expressing wishes for=20
features or for solving ongoing tricky problems is useless, and it's not=20
that raising concerns or pointing out defects with extant proposals is=20
useless (far from it).  But *how* those things are expressed (and with what=
=20
frequency) is so, so important.

As for concerns that more and more people chipping in on a proposal would=
=20
bog it down or lead to even more of the drawbacks of "design by committee",=
=20
my own impression is that that is usually the result of expectations that=
=20
things speed up *in the near term, *as well as from notions that=20
integrating new people into a project involves no complexity, challenges,=
=20
or ramp-up-times of its own.  But I suspect that as more and more people=20
take it upon themselves to patiently and courteously get up to speed on the=
=20
technical details, background, history, and culture of an ongoing proposal=
=20
(as opposed to barging in on the scene demanding that others overhaul their=
=20
labored, carefully made designs on the whim of some newcomer), in the long=
=20
term it could lead to great acceleration of the development of significant=
=20
new features.  I came in on the C++11 scene only shortly before it was set=
=20
for final standardization, but for my own programming it has represented a=
=20
revolution for how effectively I can use C++.  I don't know how much=20
impatience or complaint was expressed about the timing of its arrival=20
following C++03.  But my own impression is that it has since led to an=20
enormous increase of interest in C++.  So I have a question: was there=20
nearly this much anticipation and interest in the development and arrival=
=20
of powerful new features prior to C++11?  Is it possible that C++ is the=20
victim of the enormous success of C++11, for setting unreasonably high=20
expectation for a repeat performance?  Are people's frustrations and=20
complaints about C++17 the result of not personally adjusting to a simple=
=20
regression to the mean -- that is, is it the result of forming the=20
expectation that the amount of progress and success made with C++11 is=20
_normal_?  The amount of stable, production-ready features we got in C++11,=
=20
only 8 years after C++03, seems a remarkable achievement to me.  That there=
=20
seems a plausible chance of getting any number of Bjarne's "famous laundry=
=20
list" of 10 features by C++20 is very exciting to me; and the timeframe=20
would be similar to the gap between '03 and '11.  If anything, given=20
regression to the mean, we should be very enthusiastic that a similarly=20
high level of productivity and performance is apparently being maintained.

There are enormous demands on C++ as a very serious, professional language=
=20
for all kinds of mission-critical and systems-level projects.  It faces=20
incredibly diverse expectations and requirements from quite varied=20
industries.  It has a history of meeting those expectations, and it is=20
critical that it continue to do so.  That takes a tremendous amount of care=
=20
and requires managing a great deal of complexity in the design space.  That=
=20
it manages to move forward and grow in the face of so many hard constraints=
=20
is a marvel to me.  It simply does not have the luxury of being merely=20
"neat" or "convenient", or of catering to the rush of more parochial=20
demands and expectations.  That it still manages to be a very convenient=20
language to use, even for very performant, low-level projects, is why I'm=
=20
very loyal to the language.  Insofar as that is the result of a=20
conservative, careful, and plodding approach to standardization, I would=20
not trade it for a quicker timeframe.

-Andy

On Tuesday, January 3, 2017 at 3:39:11 PM UTC-7, Vicente J. Botet Escriba=
=20
wrote:
>
> Le 03/01/2017 =C3=A0 15:49, Nicol Bolas a =C3=A9crit :
>
> On Tuesday, January 3, 2017 at 9:04:59 AM UTC-5, Arthur Tchaikovsky wrote=
:=20
>>
>> @Peter Koch Larsen
>> >still find it to be a
>> >good release. constexpr if will be a great help to many of us. Also do
>> >not forget that stuff implemented in a TS. This is much better than
>> >having nothing.
>>
>> I also agree that is better to have something than nothing, but all the=
=20
>> above doesn't mean that this is a good release. It is mediocre, majority=
 of=20
>> the most important features are not in C++17. This is a HUGE disappointm=
ent=20
>> and I believe those were the features that were 'defining' quality of th=
e=20
>> C++17.
>>
>
> Who care if it was a good or a bad release, a minor or major release. Thi=
s=20
> is almost already part of the past. We need to fix as much issues as=20
> possible before releasing it and move on.
>
> People that cares about having a major and good release for 2020, should=
=20
> start now helping on the implementation of those features so that we have=
=20
> more experience, refining/inspecting the proposals so that we are able to=
=20
> catch most of the unavoidable issues, using them, writing blogs, ...
>
> Please stop complaining about this or that, most of the people that=20
> participates on the elaboration of the standard are doing it on their fre=
e=20
> time, and they work on the feature they consider they could help the most=
..=20
>
> I think part of the problem with the "HUGE disappointment" is that people=
=20
> were expecting things from C++17 that were, realistically speaking, *not=
=20
> gonna happen*.
>
> For example, in mid-2015, Bjarne posted his top-10 list of things he=20
> wanted in C++17 <http://wg21.link/N4492>, and people instantly took that=
=20
> as some kind of measuring tool to decide whether C++17 was good enough or=
=20
> not. But quite frankly, Stroustrup's top-10 list was ridiculously=20
> optimistic.
>
> Several topic he cited were things that were just *not gonna happen*, and=
=20
> that should have been apparent to everyone in mid-2015. Modules and=20
> contracts were way too early, both involving a great deal of complexity a=
nd=20
> precisely *zero* implementation experience. Those were not going into=20
> C++17 and it should have been quite obvious in mid-2015 that this was the=
=20
> case.
>
> IMHO, it was obvious in mid-2015 not all of these features could be on=20
> C++17. Remind that the door was closed in Oulu (Jun 2016), only one year=
=20
> later this announce was done. Please check the state of the proposal in=
=20
> this list in mid-2015.
>
> The train model doesn't consists in a minor a major release. It consists=
=20
> in releases that are delivered every 3 years. A feature is part of a=20
> release when it is ready, not before.
>
> We have not done a bad release, and the release 2020 can start just now.
>
> Vicente
>
> P.S. This post is not a response to this specif post in the thread, but=
=20
> about the global thread.
>

--=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/7272ef17-7d02-412e-9ee6-0eb7c7bb70ca%40isocpp.or=
g.

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

<div dir=3D"ltr">I don&#39;t think any of us, in our day jobs, appreciate m=
anagers who seem to only put pressure on developers to release exciting and=
 earthshaking new features on arbitrary time scales based only on unwarrant=
ed expectations and perceptions of promises the developers never made. =C2=
=A0Especially when the manager&#39;s timetables take no account of actual t=
echnical details with which only the most active developers can be familiar=
 enough as far as making sure the implementation is actually feasible, or w=
hen the manager makes which no consideration of avoiding regressions, writi=
ng proper tests, integrating the new features well with existing functional=
ity, not surprising customers too much, not introducing concepts that will =
be unteachable to customers, etc., etc. =C2=A0But at least in such cases th=
e developers get paid for putting up with the nonsense.<br><br>Yet here man=
y developers are doing much the same thing to the committee, proposal write=
rs, and implementors, who as has been pointed out, in many cases are not ev=
en being paid for their efforts. =C2=A0I&#39;m extremely sympathetic to the=
 point that if developers are dissatisfied with progress, they can roll up =
their own sleeves. =C2=A0And it&#39;s not that expressing wishes for featur=
es or for solving ongoing tricky problems is useless, and it&#39;s not that=
 raising concerns or pointing out defects with extant proposals is useless =
(far from it). =C2=A0But *how* those things are expressed (and with what fr=
equency) is so, so important.<br><br>As for concerns that more and more peo=
ple chipping in on a proposal would bog it down or lead to even more of the=
 drawbacks of &quot;design by committee&quot;, my own impression is that th=
at is usually the result of expectations that things speed up <i>in the nea=
r term, </i>as well as from notions that integrating new people into a proj=
ect involves no complexity, challenges, or ramp-up-times of its own. =C2=A0=
But I suspect that as more and more people take it upon themselves to patie=
ntly and courteously get up to speed on the technical details, background, =
history, and culture of an ongoing proposal (as opposed to barging in on th=
e scene demanding that others overhaul their labored, carefully made design=
s on the whim of some newcomer), in the long term it could lead to great ac=
celeration of the development of significant new features. =C2=A0I came in =
on the C++11 scene only shortly before it was set for final standardization=
, but for my own programming it has represented a revolution for how effect=
ively I can use C++. =C2=A0I don&#39;t know how much impatience or complain=
t was expressed about the timing of its arrival following C++03. =C2=A0But =
my own impression is that it has since led to an enormous increase of inter=
est in C++. =C2=A0So I have a question: was there nearly this much anticipa=
tion and interest in the development and arrival of powerful new features p=
rior to C++11? =C2=A0Is it possible that C++ is the victim of the enormous =
success of C++11, for setting unreasonably high expectation for a repeat pe=
rformance? =C2=A0Are people&#39;s frustrations and complaints about C++17 t=
he result of not personally adjusting to a simple regression to the mean --=
 that is, is it the result of forming the expectation that the amount of pr=
ogress and success made with C++11 is _normal_? =C2=A0The amount of stable,=
 production-ready features we got in C++11, only 8 years after C++03, seems=
 a remarkable achievement to me. =C2=A0That there seems a plausible chance =
of getting any number of Bjarne&#39;s &quot;famous laundry list&quot; of 10=
 features by C++20 is very exciting to me; and the timeframe would be simil=
ar to the gap between &#39;03 and &#39;11. =C2=A0If anything, given regress=
ion to the mean, we should be very enthusiastic that a similarly high level=
 of productivity and performance is apparently being maintained.<br><br>The=
re are enormous demands on C++ as a very serious, professional language for=
 all kinds of mission-critical and systems-level projects. =C2=A0It faces i=
ncredibly diverse expectations and requirements from quite varied industrie=
s. =C2=A0It has a history of meeting those expectations, and it is critical=
 that it continue to do so. =C2=A0That takes a tremendous amount of care an=
d requires managing a great deal of complexity in the design space. =C2=A0T=
hat it manages to move forward and grow in the face of so many hard constra=
ints is a marvel to me. =C2=A0It simply does not have the luxury of being m=
erely &quot;neat&quot; or &quot;convenient&quot;, or of catering to the rus=
h of more parochial demands and expectations. =C2=A0That it still manages t=
o be a very convenient language to use, even for very performant, low-level=
 projects, is why I&#39;m very loyal to the language. =C2=A0Insofar as that=
 is the result of a conservative, careful, and plodding approach to standar=
dization, I would not trade it for a quicker timeframe.<br><br>-Andy<br><br=
>On Tuesday, January 3, 2017 at 3:39:11 PM UTC-7, Vicente J. Botet Escriba =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div>Le 03/01/2017 =C3=A0 15:49, Nicol Bolas a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">On Tuesday, January 3, 2017 at 9:04:59 AM UTC-5,
        Arthur Tchaikovsky 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>@Peter Koch Larsen</div>
            <div>&gt;still find it to be a<br>
              &gt;good release. constexpr if will be a great help to
              many of us. Also do<br>
              &gt;not forget that stuff implemented in a TS. This is
              much better than<br>
              &gt;having nothing.</div>
            <div><br>
            </div>
            <div>I also agree that is better to have something than
              nothing, but all the above doesn&#39;t mean that this is a
              good release. It is mediocre, majority of the most
              important features are not in C++17. This is a HUGE
              disappointment and I believe those were the features that
              were &#39;defining&#39; quality of the C++17.</div>
          </div>
        </blockquote>
        <div><br>
        </div>
      </div>
    </blockquote>
    Who care if it was a good or a bad release, a minor or major
    release. This is almost already part of the past. We need to fix as
    much issues as possible before releasing it and move on.<br>
    <br>
    People that cares about having a major and good release for 2020,
    should start now helping on the implementation of those features so
    that we have more experience, refining/inspecting the proposals so
    that we are able to catch most of the unavoidable issues, using
    them, writing blogs, ...<br>
    <br>
    Please stop complaining about this or that, most of the people that
    participates on the elaboration of the standard are doing it on
    their free time, and they work on the feature they consider they
    could help the most. <br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>I think part of the problem with the &quot;HUGE disappointment=
&quot;
          is that people were expecting things from C++17 that were,
          realistically speaking, <i>not gonna happen</i>.<br>
          <br>
          For example, in mid-2015, Bjarne posted his <a href=3D"http://wg2=
1.link/N4492" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwg21.link%2FN4492\x26sa=
\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFdcsY0IsGJQmNZZbICWRbxjx_rMw&#39;;return=
 true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%=
2F%2Fwg21.link%2FN4492\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFdcsY0IsGJQm=
NZZbICWRbxjx_rMw&#39;;return true;">top-10
            list of things he wanted in C++17</a>, and people instantly
          took that as some kind of measuring tool to decide whether
          C++17 was good enough or not. But quite frankly, Stroustrup&#39;s
          top-10 list was ridiculously optimistic.<br>
          <br>
        </div>
      </div>
    </blockquote>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>Several topic he cited were things that were just <i>not
            gonna happen</i>, and that should have been apparent to
          everyone in mid-2015. Modules and contracts were way too
          early, both involving a great deal of complexity and precisely
          <i>zero</i> implementation experience. Those were not going
          into C++17 and it should have been quite obvious in mid-2015
          that this was the case.<br>
        </div>
      </div>
    </blockquote>
    IMHO, it was obvious in mid-2015 not all of these features could be
    on C++17. Remind that the door was closed in Oulu (Jun 2016), only
    one year later this announce was done. Please check the state of the
    proposal in this list in mid-2015.<br>
    <br>
    The train model doesn&#39;t consists in a minor a major release. It
    consists in releases that are delivered every 3 years. A feature is
    part of a release when it is ready, not before.<br>
    <br>
    We have not done a bad release, and the release 2020 can start just
    now.<br>
    <br>
    Vicente<br>
    <br>
    P.S. This post is not a response to this specif post in the thread,
    but about the global thread.<br>
  </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/7272ef17-7d02-412e-9ee6-0eb7c7bb70ca%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7272ef17-7d02-412e-9ee6-0eb7c7bb70ca=
%40isocpp.org</a>.<br />

------=_Part_1703_1795731550.1483487858219--

------=_Part_1702_2046578116.1483487858219--

.

------=_Part_2047_1271356070.1483502836393
Content-Type: multipart/alternative;
 boundary="----=_Part_2048_206071041.1483502836393"

------=_Part_2048_206071041.1483502836393
Content-Type: text/plain; charset=UTF-8

On Tuesday, January 3, 2017 at 4:29:10 PM UTC-5, Jens Maurer wrote:
>
> On 01/03/2017 09:13 PM, Nicol Bolas wrote:
> > Admittedly, I've never been to a meeting. But from the outside
> > looking in, I don't get the impression that throwing more people at
> > the committee will make things get resolved faster. Would throwing
> > more people at, for example, comparison operator generation have
> > really allowed it to get into C++17? Could more people have resolved
> > the various UCS issues and allowed us to get that in C++17?
>
> What's UCS?
>

Unified call syntax.

Anyway, for comparison operators specifically, my impression is that
> people have different expectations and put different emphasis on
> "auto-generation" vs. "opt-in" and "how much existing code must
> continue to work". As far as I can see, having someone that
> modified a compiler with a specific set of default comparison
> rules and ran it on a large codebase would have accelerated the
> process.
>

That sounds reasonable. However, the problem here is communication. In
order for other people to do that, someone involved in the project needs to
advertise that this is something that needs to be looked into. I'm sure
there are people out there with compiler knowledge who might have been
willing to have a go at it. But without knowing that this was something the
committee could use, you couldn't really gain access to that resource.

Perhaps the committee could come up with some way to advertise needs such
as this. I think the C++ community would be happy to see some way to
contribute, not in a technical way, but through their coding skills.

Even just writing a paper summarizing the developments at the
> N meetings where the topic was discussed (including seemingly
> minority opinions) would have helped.
>

"the N meetings"? Do you mean the C++ committee meetings, or are you
referring to something else?

--
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/72c5d05f-7c9d-41cb-bd10-d222d8d15099%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, January 3, 2017 at 4:29:10 PM UTC-5, Jens Maur=
er wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 01/03/2017 09:13 P=
M, Nicol Bolas wrote:
<br>&gt; Admittedly, I&#39;ve never been to a meeting. But from the outside
<br>&gt; looking in, I don&#39;t get the impression that throwing more peop=
le at
<br>&gt; the committee will make things get resolved faster. Would throwing
<br>&gt; more people at, for example, comparison operator generation have
<br>&gt; really allowed it to get into C++17? Could more people have resolv=
ed
<br>&gt; the various UCS issues and allowed us to get that in C++17?
<br>
<br>What&#39;s UCS?
<br></blockquote><div><br>Unified call syntax.<br><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;">
Anyway, for comparison operators specifically, my impression is that
<br>people have different expectations and put different emphasis on
<br>&quot;auto-generation&quot; vs. &quot;opt-in&quot; and &quot;how much e=
xisting code must
<br>continue to work&quot;. As far as I can see, having someone that
<br>modified a compiler with a specific set of default comparison
<br>rules and ran it on a large codebase would have accelerated the
<br>process.<br></blockquote><div><br>That sounds reasonable. However, the =
problem here is communication. In order for other people to do that, someon=
e involved in the project needs to advertise that this is something that ne=
eds to be looked into. I&#39;m sure there are people out there with compile=
r knowledge who might have been willing to have a go at it. But without kno=
wing that this was something the committee could use, you couldn&#39;t real=
ly gain access to that resource.<br><br>Perhaps the committee could come up=
 with some way to advertise needs such as this. I think the C++ community w=
ould be happy to see some way to contribute, not in a technical way, but th=
rough their coding skills.<br><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;">
Even just writing a paper summarizing the developments at the
<br>N meetings where the topic was discussed (including seemingly
<br>minority opinions) would have helped.<br></blockquote><div><br>&quot;th=
e N meetings&quot;? Do you mean the C++ committee meetings, or are you refe=
rring to something else? <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/72c5d05f-7c9d-41cb-bd10-d222d8d15099%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/72c5d05f-7c9d-41cb-bd10-d222d8d15099=
%40isocpp.org</a>.<br />

------=_Part_2048_206071041.1483502836393--

------=_Part_2047_1271356070.1483502836393--

.

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

I think he means there are N meetings, N signifying an unknown but definite
amount of meetings that represent, collectively, the C++ committee meetings.

Like how a container contains N items?

On Tue, Jan 3, 2017 at 11:07 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Tuesday, January 3, 2017 at 4:29:10 PM UTC-5, Jens Maurer wrote:
>>
>> On 01/03/2017 09:13 PM, Nicol Bolas wrote:
>> > Admittedly, I've never been to a meeting. But from the outside
>> > looking in, I don't get the impression that throwing more people at
>> > the committee will make things get resolved faster. Would throwing
>> > more people at, for example, comparison operator generation have
>> > really allowed it to get into C++17? Could more people have resolved
>> > the various UCS issues and allowed us to get that in C++17?
>>
>> What's UCS?
>>
>
> Unified call syntax.
>
> Anyway, for comparison operators specifically, my impression is that
>> people have different expectations and put different emphasis on
>> "auto-generation" vs. "opt-in" and "how much existing code must
>> continue to work". As far as I can see, having someone that
>> modified a compiler with a specific set of default comparison
>> rules and ran it on a large codebase would have accelerated the
>> process.
>>
>
> That sounds reasonable. However, the problem here is communication. In
> order for other people to do that, someone involved in the project needs to
> advertise that this is something that needs to be looked into. I'm sure
> there are people out there with compiler knowledge who might have been
> willing to have a go at it. But without knowing that this was something the
> committee could use, you couldn't really gain access to that resource.
>
> Perhaps the committee could come up with some way to advertise needs such
> as this. I think the C++ community would be happy to see some way to
> contribute, not in a technical way, but through their coding skills.
>
> Even just writing a paper summarizing the developments at the
>> N meetings where the topic was discussed (including seemingly
>> minority opinions) would have helped.
>>
>
> "the N meetings"? Do you mean the C++ committee meetings, or are you
> referring to something else?
>
> --
> 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/72c5d05f-7c9d-41cb-
> bd10-d222d8d15099%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/72c5d05f-7c9d-41cb-bd10-d222d8d15099%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/CAMD6iD_oFs%2Bhwwim%3DvHObchTp_7WO4B4kKSWFLN29Q%3DZm%2Bx97A%40mail.gmail.com.

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

<div dir=3D"ltr">I think he means there are N meetings, N signifying an unk=
nown but definite amount of meetings that represent, collectively, the C++ =
committee meetings.<div><br></div><div>Like how a container contains N item=
s?</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On =
Tue, Jan 3, 2017 at 11:07 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=
=3D"">On Tuesday, January 3, 2017 at 4:29:10 PM UTC-5, Jens Maurer wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex">On 01/03/2017 09:13 PM, Nicol Bolas w=
rote:
<br>&gt; Admittedly, I&#39;ve never been to a meeting. But from the outside
<br>&gt; looking in, I don&#39;t get the impression that throwing more peop=
le at
<br>&gt; the committee will make things get resolved faster. Would throwing
<br>&gt; more people at, for example, comparison operator generation have
<br>&gt; really allowed it to get into C++17? Could more people have resolv=
ed
<br>&gt; the various UCS issues and allowed us to get that in C++17?
<br>
<br>What&#39;s UCS?
<br></blockquote></span><div><br>Unified call syntax.<br><br></div><span cl=
ass=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex">
Anyway, for comparison operators specifically, my impression is that
<br>people have different expectations and put different emphasis on
<br>&quot;auto-generation&quot; vs. &quot;opt-in&quot; and &quot;how much e=
xisting code must
<br>continue to work&quot;. As far as I can see, having someone that
<br>modified a compiler with a specific set of default comparison
<br>rules and ran it on a large codebase would have accelerated the
<br>process.<br></blockquote></span><div><br>That sounds reasonable. Howeve=
r, the problem here is communication. In order for other people to do that,=
 someone involved in the project needs to advertise that this is something =
that needs to be looked into. I&#39;m sure there are people out there with =
compiler knowledge who might have been willing to have a go at it. But with=
out knowing that this was something the committee could use, you couldn&#39=
;t really gain access to that resource.<br><br>Perhaps the committee could =
come up with some way to advertise needs such as this. I think the C++ comm=
unity would be happy to see some way to contribute, not in a technical way,=
 but through their coding skills.<br><br></div><span class=3D""><blockquote=
 class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex">
Even just writing a paper summarizing the developments at the
<br>N meetings where the topic was discussed (including seemingly
<br>minority opinions) would have helped.<br></blockquote></span><div><br>&=
quot;the N meetings&quot;? Do you mean the C++ committee meetings, or are y=
ou referring to something else? <br></div></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<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/72c5d05f-7c9d-41cb-bd10-d222d8d15099%=
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/72c5=
d05f-7c9d-41cb-<wbr>bd10-d222d8d15099%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/CAMD6iD_oFs%2Bhwwim%3DvHObchTp_7WO4B4=
kKSWFLN29Q%3DZm%2Bx97A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD_o=
Fs%2Bhwwim%3DvHObchTp_7WO4B4kKSWFLN29Q%3DZm%2Bx97A%40mail.gmail.com</a>.<br=
 />

--001a114a85021611f505453ed494--

.

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

2017-01-03 23:39 GMT+01:00 Vicente J. Botet Escriba <vicente.botet@wanadoo
..fr>:

> People that cares about having a major and good release for 2020, should
> start now helping on the implementation of those features so that we have
> more experience
>

My experience is that your proposal/contribution remains unnoticed by the
committee if you do not attend the meetings (even if you provide a
reference implementation).
Unfortunately I've neither the financial background to travel (several
times) each year around the world nor my employer does.

--
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%2Bwfc197O7zJpowinW1A6y-VGPzPGZ1eS5Q118owj%3DtUoP74iQ%40mail.gmail.com.

--001a114920f890464c05453f6acc
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">2017=
-01-03 23:39 GMT+01:00 Vicente J. <span tabindex=3D"-1" id=3D":152.16" styl=
e=3D"" class=3D"">Botet</span> <span tabindex=3D"-1" id=3D":152.17" style=
=3D"" class=3D"">Escriba</span> <span dir=3D"ltr">&lt;<a target=3D"_blank" =
href=3D"mailto:vicente.botet@wanadoo.fr"><span tabindex=3D"-1" id=3D":152.1=
8" style=3D"" class=3D"">vicente</span>.<span tabindex=3D"-1" id=3D":152.19=
" style=3D"" class=3D"">botet</span>@<span tabindex=3D"-1" id=3D":152.20" s=
tyle=3D"" class=3D"">wanadoo</span>.fr</a>&gt;</span>:<br><blockquote style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex" class=3D"gmail_quote">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF">
    People that cares about having a major and good release for 2020,
    should start now helping on the implementation of those features so
    that we have more experience<br></div></blockquote></div><br></div><div=
 class=3D"gmail_extra">My experience is that your proposal/contribution rem=
ains unnoticed by the committee if you do not attend the meetings (even if =
you provide a reference implementation).<br></div><div class=3D"gmail_extra=
">Unfortunately I&#39;ve neither the financial background to travel (severa=
l times) each year around the world nor my employer does.</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%2Bwfc197O7zJpowinW1A6y-VGPzPGZ1eS5=
Q118owj%3DtUoP74iQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc197O7=
zJpowinW1A6y-VGPzPGZ1eS5Q118owj%3DtUoP74iQ%40mail.gmail.com</a>.<br />

--001a114920f890464c05453f6acc--

.

This is a multi-part message in MIME format.
--------------DABB8B3BBAC98FCCBDF06D64
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 04/01/2017 =C3=A0 08:05, Oliver Kowalke a =C3=A9crit :
> 2017-01-03 23:39 GMT+01:00 Vicente J. Botet Escriba=20
> <vicente.botet@wanadoo.fr <mailto:vicente.botet@wanadoo.fr>>:
>
>     People that cares about having a major and good release for 2020,
>     should start now helping on the implementation of those features
>     so that we have more experience
>
>
> My experience is that your proposal/contribution remains unnoticed by=20
> the committee if you do not attend the meetings (even if you provide a=20
> reference implementation).
> Unfortunately I've neither the financial background to travel (several=20
> times) each year around the world nor my employer does.
Hi Oliver,

This is another issue. I believe this depends on how you shell your=20
proposal in this forum (or in the official reflectors), if you have a=20
champion that is working with you and can defend the proposal as if you=20
where there , ....
Note that there are some of feature in the standard proposed by people=20
that never assisted ti a meeting or did it rarely.
I'm not saying that not being able to assists helps.

I was talking of  the features expected in a release, features that the=20
committee is already interested in, as the list of the 10-features.
Helping to make these proposal ready helps to have them on the next release=
..
If someone consider that Concepts should be part of the next standard he=20
could try to use the current implementation, make some libraries with=20
it, write a blog about its experience, report issues he could find, ...
The same for other expected features.

Vicente

--=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/f820973b-59e9-94a8-df85-901f11148317%40wanadoo.f=
r.

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 04/01/2017 =C3=A0 08:05, Oliver Kowal=
ke a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
cite=3D"mid:CA+wfc197O7zJpowinW1A6y-VGPzPGZ1eS5Q118owj=3DtUoP74iQ@mail.gmai=
l.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">2017-01-03 23:39 GMT+01:00 Vicente J.
            <span tabindex=3D"-1" id=3D":152.16" style=3D"" class=3D"">Bote=
t</span>
            <span tabindex=3D"-1" id=3D":152.17" style=3D"" class=3D"">Escr=
iba</span>
            <span dir=3D"ltr">&lt;<a moz-do-not-send=3D"true"
                target=3D"_blank" href=3D"mailto:vicente.botet@wanadoo.fr">=
<span
                  tabindex=3D"-1" id=3D":152.18" style=3D"" class=3D"">vice=
nte</span>.<span
                  tabindex=3D"-1" id=3D":152.19" style=3D"" class=3D"">bote=
t</span>@<span
                  tabindex=3D"-1" id=3D":152.20" style=3D"" class=3D"">wana=
doo</span>.fr</a>&gt;</span>:<br>
            <blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px
              solid rgb(204,204,204);padding-left:1ex"
              class=3D"gmail_quote">
              <div bgcolor=3D"#FFFFFF"> People that cares about having a
                major and good release for 2020, should start now
                helping on the implementation of those features so that
                we have more experience<br>
              </div>
            </blockquote>
          </div>
          <br>
        </div>
        <div class=3D"gmail_extra">My experience is that your
          proposal/contribution remains unnoticed by the committee if
          you do not attend the meetings (even if you provide a
          reference implementation).<br>
        </div>
        <div class=3D"gmail_extra">Unfortunately I've neither the
          financial background to travel (several times) each year
          around the world nor my employer does.</div>
      </div>
    </blockquote>
    Hi Oliver,<br>
    <br>
    This is another issue. I believe this depends on how you shell your
    proposal in this forum (or in the official reflectors), if you have
    a champion that is working with you and can defend the proposal as
    if you where there , .... <br>
    Note that there are some of feature in the standard proposed by
    people that never assisted ti a meeting or did it rarely.<br>
    I'm not saying that not being able to assists helps.<br>
    <br>
    I was talking of=C2=A0 the features expected in a release, features tha=
t
    the committee is already interested in, as the list of the
    10-features. <br>
    Helping to make these proposal ready helps to have them on the next
    release.<br>
    If someone consider that Concepts should be part of the next
    standard he could try to use the current implementation, make some
    libraries with it, write a blog about its experience, report issues
    he could find, ...<br>
    The same for other expected features.<br>
    <br>
    Vicente<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/f820973b-59e9-94a8-df85-901f11148317%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f820973b-59e9-94a8-df85-901f11148317=
%40wanadoo.fr</a>.<br />

--------------DABB8B3BBAC98FCCBDF06D64--

.

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

2017-01-04 8:33 GMT+01:00 Vicente J. Botet Escriba <vicente.botet@wanadoo.fr
>:

> This is another issue. I believe this depends on how you shell your
> proposal in this forum (or in the official reflectors),
>

I got the recommendation by a committee member not to discuss the
propsal(s) in this forum (endless discussions ...)  =:o


> I was talking of  the features expected in a release, features that the
> committee is already interested in, as the list of the 10-features.
>

for instance coroutines

--
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%2Bwfc18eUKgsn%3DdioijcrV_WwWa-Nd%2BUjG1ExiVCDNmvom8R0A%40mail.gmail.com.

--001a11481660ce88290545400348
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">2017=
-01-04 8:33 GMT+01:00 Vicente J. Botet Escriba <span dir=3D"ltr">&lt;<a tar=
get=3D"_blank" href=3D"mailto:vicente.botet@wanadoo.fr">vicente.botet@wanad=
oo.fr</a>&gt;</span>:<br><blockquote style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF">
    This is another issue. I believe this depends on how you shell your
    proposal in this forum (or in the official reflectors),<br></div></bloc=
kquote><div><br></div><div>I got the recommendation by a committee member n=
ot to discuss the propsal(s) in this forum (endless discussions ...)=C2=A0 =
=3D:o<br></div><div>=C2=A0</div><blockquote style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_=
quote"><div bgcolor=3D"#FFFFFF">
   =20
    I was talking of=C2=A0 the features expected in a release, features tha=
t
    the committee is already interested in, as the list of the
    10-features.<br></div></blockquote><div><br></div><div>for instance cor=
outines<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/CA%2Bwfc18eUKgsn%3DdioijcrV_WwWa-Nd%2=
BUjG1ExiVCDNmvom8R0A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc18e=
UKgsn%3DdioijcrV_WwWa-Nd%2BUjG1ExiVCDNmvom8R0A%40mail.gmail.com</a>.<br />

--001a11481660ce88290545400348--

.

On 01/04/2017 05:07 AM, Nicol Bolas wrote:
> On Tuesday, January 3, 2017 at 4:29:10 PM UTC-5, Jens Maurer wrote:
>
>     On 01/03/2017 09:13 PM, Nicol Bolas wrote:
>     > Admittedly, I've never been to a meeting. But from the outside
>     > looking in, I don't get the impression that throwing more people at
>     > the committee will make things get resolved faster. Would throwing
>     > more people at, for example, comparison operator generation have
>     > really allowed it to get into C++17? Could more people have resolved
>     > the various UCS issues and allowed us to get that in C++17?
>
>     What's UCS?
>
> Unified call syntax.

Ok, this one is a laudable goal --- if pursued 30 years ago.

>     Even just writing a paper summarizing the developments at the
>     N meetings where the topic was discussed (including seemingly
>     minority opinions) would have helped.
>
>
> "the N meetings"? Do you mean the C++ committee meetings, or are you referring to something else?

There were several (many) C++ committee meetings where the comparison operators
were discussed, sometimes (it seems to me) not loop-free.

Jens

--
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/586CB852.4060602%40gmx.net.

.

On 01/04/2017 08:48 AM, Oliver Kowalke wrote:
> 2017-01-04 8:33 GMT+01:00 Vicente J. Botet Escriba <vicente.botet@wanadoo.fr <mailto:vicente.botet@wanadoo.fr>>:
>
>     This is another issue. I believe this depends on how you shell your proposal in this forum (or in the official reflectors),
>
>
> I got the recommendation by a committee member not to discuss the propsal(s) in this forum (endless discussions ...)  =:o
>
>
>     I was talking of  the features expected in a release, features that the committee is already interested in, as the list of the 10-features.
>
>
> for instance coroutines

For coroutines (and as a matter of advertisement), as a personal opinion, I am looking
for an alternative to the proposal on the table, which (in my opinion) has a too broad
library / core interface that feels "hackish" to me (need another feature? let's bolt
it on top).

There was a "resumable functions" proposal (that I didn't look into closely),
and reportedly, it didn't provide the configurability that the current
coroutines proposal provides, so I can only assume that it's dead.

Jens

--
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/586CB921.6010103%40gmx.net.

.

On 01/04/2017 09:58 AM, Jens Maurer wrote:
> On 01/04/2017 08:48 AM, Oliver Kowalke wrote:
>> 2017-01-04 8:33 GMT+01:00 Vicente J. Botet Escriba <vicente.botet@wanadoo.fr <mailto:vicente.botet@wanadoo.fr>>:
>>
>>     This is another issue. I believe this depends on how you shell your proposal in this forum (or in the official reflectors),
>>
>>
>> I got the recommendation by a committee member not to discuss the propsal(s) in this forum (endless discussions ...)  =:o
>>
>>
>>     I was talking of  the features expected in a release, features that the committee is already interested in, as the list of the 10-features.
>>
>>
>> for instance coroutines
>
> For coroutines (and as a matter of advertisement), as a personal opinion, I am looking
> for an alternative to the proposal on the table, which (in my opinion) has a too broad
> library / core interface that feels "hackish" to me (need another feature? let's bolt
> it on top).
>
> There was a "resumable functions" proposal (that I didn't look into closely),
> and reportedly, it didn't provide the configurability that the current
> coroutines proposal provides, so I can only assume that it's dead.

As an example for the kind of re-engineering I'm looking for:

P0352R0 Smart References through Delegation: An Alternative to N4477's Operator Dot

seems to be a substantially less involved approach to operator dot compared to

P0416R1 Operator Dot (R3)

I continue to consider overloading of "operator dot" a minor nuisance,
and thus I very much appreciate an approach that is minimally invasive
to core language rules.

Jens

--
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/586CBA3B.5010903%40gmx.net.

.

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

>Please stop complaining about this or that, most of the people that
participates on the elaboration of the standard are doing it on their free
time.

I simply don't understand that argument. I thought people are there not for
the money but for the love and passion to language and they don't expect to
be paid for it?
So following, that people are doing it for free they mustn't be ever
criticized for it?
I'm sorry but you are being judged by the work you produced not by the
money you are being paid for that work. That's how real world works.

If your work is of poor quality (and C++17 in many people's eyes is) you
(the people who are responsible, the committee) should get criticized and
I'm glad to see that happening. Let's stop that 'patting each other on the
back' and saying to yourselves that yet again, you did great job. No you
didn't. You blew it.
As for asking:
>Who care if it was a good or a bad release, a minor or major release[...]
I'm pretty certain that there are lots of people who actually care a lot.

This situation reminds me of a scene where engineer of certain brand of car
was arguing with the people (the regular users of that car) that they
shouldn't criticize the engineer for his work because they (the users) are
incapable of actually making even worse car than that produced by those
engineers.

I'm sorry but it doesn't work that way. I, as a user, even though I'm
unable to have any impact (nor I'm admittedly capable of making it) on a
car being produced, have every right to express my disappointment with a
car. Is it poorly made? If so I have right to criticize it. And I really
don't care how much(or how little) those people involved in production of
this car were paid. This (the wages) is totally different issue.
And if there are more and more voices from users that the car is of poor
quality, well, I think there is something on the matter. Even though
engineers think that yet again they've produced something great and pat
each other on the back.
Same goes for films, clothes, food... If something is of poor quality users
have right to criticize it even though the people making it weren't paid as
much as they should and despite the fact that the users are incapable of
producing such item themselves.

On Wed, Jan 4, 2017 at 9:02 AM, Jens Maurer <Jens.Maurer@gmx.net> wrote:

> On 01/04/2017 09:58 AM, Jens Maurer wrote:
> > On 01/04/2017 08:48 AM, Oliver Kowalke wrote:
> >> 2017-01-04 8:33 GMT+01:00 Vicente J. Botet Escriba <
> vicente.botet@wanadoo.fr <mailto:vicente.botet@wanadoo.fr>>:
> >>
> >>     This is another issue. I believe this depends on how you shell your
> proposal in this forum (or in the official reflectors),
> >>
> >>
> >> I got the recommendation by a committee member not to discuss the
> propsal(s) in this forum (endless discussions ...)  =:o
> >>
> >>
> >>     I was talking of  the features expected in a release, features that
> the committee is already interested in, as the list of the 10-features.
> >>
> >>
> >> for instance coroutines
> >
> > For coroutines (and as a matter of advertisement), as a personal
> opinion, I am looking
> > for an alternative to the proposal on the table, which (in my opinion)
> has a too broad
> > library / core interface that feels "hackish" to me (need another
> feature? let's bolt
> > it on top).
> >
> > There was a "resumable functions" proposal (that I didn't look into
> closely),
> > and reportedly, it didn't provide the configurability that the current
> > coroutines proposal provides, so I can only assume that it's dead.
>
> As an example for the kind of re-engineering I'm looking for:
>
> P0352R0 Smart References through Delegation: An Alternative to N4477's
> Operator Dot
>
> seems to be a substantially less involved approach to operator dot
> compared to
>
> P0416R1 Operator Dot (R3)
>
> I continue to consider overloading of "operator dot" a minor nuisance,
> and thus I very much appreciate an approach that is minimally invasive
> to core language rules.
>
> Jens
>
> --
> 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/586CBA3B.5010903%40gmx.net.
>



--
Yours sincerely
Artur Czajkowski

--
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/CANPOWseGQq1AVmzWLbqaT2%2BDp0piGwnC6jjbkiHEFzGTaf7o6Q%40mail.gmail.com.

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

<div dir=3D"ltr"><div>&gt;Please stop complaining about this or that, most =
of the people that    participates on the elaboration of the standard are d=
oing it on    their free time.</div><div><br></div><div>I simply don&#39;t =
understand that argument. I thought people are there not for the money but =
for the love and passion to language and they don&#39;t expect to be paid f=
or it? </div><div>So following, that people are doing it for free they must=
n&#39;t be ever criticized for it? </div><div>I&#39;m sorry but=C2=A0you ar=
e being judged by the work you produced not by the money you are being paid=
 for that work. That&#39;s how real world works.</div><div><br></div><div>I=
f your work is of poor quality (and C++17 in many people&#39;s eyes is) you=
 (the people who are responsible, the committee) should get criticized and =
I&#39;m glad to see that happening. Let&#39;s stop that &#39;patting each o=
ther on the back&#39; and saying to yourselves that yet again, you did grea=
t job. No you didn&#39;t. You blew it. </div><div>As for asking:</div><div>=
&gt;Who care if it was a good or a bad release, a minor or major    release=
[...]</div><div>I&#39;m pretty certain that there are lots of people who ac=
tually care a lot.</div><div><br></div><div>This situation reminds me=C2=A0=
of a=C2=A0scene where engineer of certain brand of=C2=A0car was arguing wit=
h the people (the regular users of that car) that they shouldn&#39;t critic=
ize the engineer for his work because they (the users) are incapable of act=
ually making even worse car than that produced by those engineers.</div><di=
v><br></div><div>I&#39;m sorry but=C2=A0it doesn&#39;t work that way. I, as=
 a user, even though I&#39;m unable to have any impact (nor I&#39;m admitte=
dly capable of making it)=C2=A0on a car being produced, have every right to=
 express my disappointment with a car. Is it poorly made? If so I have righ=
t to criticize it. And I really don&#39;t care how much(or how little) thos=
e people involved in production of this car were paid. This (the wages)=C2=
=A0is totally different issue.</div><div>And if there are more and more voi=
ces from users that the car is of poor quality, well, I think there is some=
thing on the matter. Even though engineers think that yet again they&#39;ve=
 produced something great and pat each other on the back.</div><div>Same go=
es for films, clothes, food... If something is of poor quality users have r=
ight to criticize it even though the people making it weren&#39;t paid as m=
uch as they should and despite the fact that the users are incapable of pro=
ducing such item themselves.</div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Wed, Jan 4, 2017 at 9:02 AM, Jens Maurer <span dir=3D"l=
tr">&lt;<a href=3D"mailto:Jens.Maurer@gmx.net" target=3D"_blank">Jens.Maure=
r@gmx.net</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>On=
 01/04/2017 09:58 AM, Jens Maurer wrote:<br>
&gt; On 01/04/2017 08:48 AM, Oliver Kowalke wrote:<br>
&gt;&gt; 2017-01-04 8:33 GMT+01:00 Vicente J. Botet Escriba &lt;<a href=3D"=
mailto:vicente.botet@wanadoo.fr">vicente.botet@wanadoo.fr</a> &lt;mailto:<a=
 href=3D"mailto:vicente.botet@wanadoo.fr">vicente.botet@wanadoo.<wbr>fr</a>=
&gt;&gt;:<br>
&gt;&gt;<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0This is another issue. I believe this depends o=
n how you shell your proposal in this forum (or in the official reflectors)=
,<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; I got the recommendation by a committee member not to discuss the =
propsal(s) in this forum (endless discussions ...)=C2=A0 =3D:o<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0I was talking of=C2=A0 the features expected in=
 a release, features that the committee is already interested in, as the li=
st of the 10-features.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; for instance coroutines<br>
&gt;<br>
&gt; For coroutines (and as a matter of advertisement), as a personal opini=
on, I am looking<br>
&gt; for an alternative to the proposal on the table, which (in my opinion)=
 has a too broad<br>
&gt; library / core interface that feels &quot;hackish&quot; to me (need an=
other feature? let&#39;s bolt<br>
&gt; it on top).<br>
&gt;<br>
&gt; There was a &quot;resumable functions&quot; proposal (that I didn&#39;=
t look into closely),<br>
&gt; and reportedly, it didn&#39;t provide the configurability that the cur=
rent<br>
&gt; coroutines proposal provides, so I can only assume that it&#39;s dead.=
<br>
<br>
</span>As an example for the kind of re-engineering I&#39;m looking for:<br=
>
<br>
P0352R0 Smart References through Delegation: An Alternative to N4477&#39;s =
Operator Dot<br>
<br>
seems to be a substantially less involved approach to operator dot compared=
 to<br>
<br>
P0416R1 Operator Dot (R3)<br>
<br>
I continue to consider overloading of &quot;operator dot&quot; a minor nuis=
ance,<br>
and thus I very much appreciate an approach that is minimally invasive<br>
to core language rules.<br>
<span><br>
Jens<br>
<br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/586CBA3B.5010903%40gmx.net" ta=
rget=3D"_blank" rel=3D"noreferrer">https://groups.google.com/a/<wbr>isocpp.=
org/d/msgid/std-<wbr>proposals/586CBA3B.5010903%<wbr>40gmx.net</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature">Yours sincerely<br>Artur Czajkow=
ski</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/CANPOWseGQq1AVmzWLbqaT2%2BDp0piGwnC6j=
jbkiHEFzGTaf7o6Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANPOWseGQq1AVm=
zWLbqaT2%2BDp0piGwnC6jjbkiHEFzGTaf7o6Q%40mail.gmail.com</a>.<br />

--001a1141b9a2e507b20545426f05--

.

> On 4 Jan 2017, at 08:54, Jens Maurer <Jens.Maurer@gmx.net> wrote:
> There were several (many) C++ committee meetings where the comparison ope=
rators
> were discussed, sometimes (it seems to me) not loop-free.

The never ending comparison loop seems to be straight forward to me:

 - one half the committee insists that default comparisons shall be imposed=
 on everybody by default, stating that users who do not want it can "opt ou=
t" and that the feature is useless if it were "opt in"
 - the other half of the committee insists that the feature should be "opt =
in" as a couple of hundred million lines of code are somewhat hard to audit=
 for the cases where it is necessary to "opt out".

Even discounting some people who are neutral there still is no consensus to=
 make a change. No consensus for change means no change. We can run through=
 that cycle as often as necessary but it seems unlikely that a consensus fo=
r change emerges with the positions staying unchanged.

--=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/D5BFDC0C-51E7-4859-B541-D3C8CE436725%40gmail.com=
..

.

On 01/04/2017 12:35 PM, Dietmar K=C3=BChl wrote:
>> On 4 Jan 2017, at 08:54, Jens Maurer <Jens.Maurer@gmx.net> wrote:
>> There were several (many) C++ committee meetings where the comparison op=
erators
>> were discussed, sometimes (it seems to me) not loop-free.
>=20
> The never ending comparison loop seems to be straight forward to me:
>=20
>  - one half the committee insists that default comparisons shall be impos=
ed on everybody by default, stating that users who do not want it can "opt =
out" and that the feature is useless if it were "opt in"
>  - the other half of the committee insists that the feature should be "op=
t in" as a couple of hundred million lines of code are somewhat hard to aud=
it for the cases where it is necessary to "opt out".

Right.  There was apparently an EWG vote on this some time ago,
but that seems to have left the other half unconvinced.

> Even discounting some people who are neutral there still is no
> consensus to make a change. No consensus for change means no change.
> We can run through that cycle as often as necessary but it seems
> unlikely that a consensus for change emerges with the positions
> staying unchanged.

A somewhat novel approach would be for =3D=3D and !=3D to be default
(opt-out) and < and friends to be opt-in.  Arguably, anything that
can be copied has a meaningful =3D=3D.

Jens

--=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/586CFA26.10104%40gmx.net.

.

------=_Part_1526_1762632770.1483540770520
Content-Type: multipart/alternative;
 boundary="----=_Part_1527_776111969.1483540770521"

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

W dniu =C5=9Broda, 4 stycznia 2017 11:42:12 UTC+1 u=C5=BCytkownik Arthur Tc=
haikovsky=20
napisa=C5=82:
>
> >Please stop complaining about this or that, most of the people that=20
> participates on the elaboration of the standard are doing it on their fre=
e=20
> time.
>
> I simply don't understand that argument. I thought people are there not=
=20
> for the money but for the love and passion to language and they don't=20
> expect to be paid for it?=20
> So following, that people are doing it for free they mustn't be ever=20
> criticized for it?=20
> I'm sorry but you are being judged by the work you produced not by the=20
> money you are being paid for that work. That's how real world works.
>
> If your work is of poor quality (and C++17 in many people's eyes is) you=
=20
> (the people who are responsible, the committee) should get criticized and=
=20
> I'm glad to see that happening. Let's stop that 'patting each other on th=
e=20
> back' and saying to yourselves that yet again, you did great job. No you=
=20
> didn't. You blew it.=20
> As for asking:
> >Who care if it was a good or a bad release, a minor or major release[...=
]
> I'm pretty certain that there are lots of people who actually care a lot.
>
> This situation reminds me of a scene where engineer of certain brand=20
> of car was arguing with the people (the regular users of that car) that=
=20
> they shouldn't criticize the engineer for his work because they (the user=
s)=20
> are incapable of actually making even worse car than that produced by tho=
se=20
> engineers.
>
> I'm sorry but it doesn't work that way. I, as a user, even though I'm=20
> unable to have any impact (nor I'm admittedly capable of making it) on a=
=20
> car being produced, have every right to express my disappointment with a=
=20
> car. Is it poorly made? If so I have right to criticize it. And I really=
=20
> don't care how much(or how little) those people involved in production of=
=20
> this car were paid. This (the wages) is totally different issue.
> And if there are more and more voices from users that the car is of poor=
=20
> quality, well, I think there is something on the matter. Even though=20
> engineers think that yet again they've produced something great and pat=
=20
> each other on the back.
> Same goes for films, clothes, food... If something is of poor quality=20
> users have right to criticize it even though the people making it weren't=
=20
> paid as much as they should and despite the fact that the users are=20
> incapable of producing such item themselves.
>

While I don't disagree with this point of view, I'd rather say that they=20
did good job, just not what was most wished for.

I think committee should really prioritize its work, esp. on features that=
=20
should have been there long time ago: modules, reflection and maybe=20
concepts.
I get it, modules are really ungrateful piece of functionality to work on=
=20
(due to legacy cruft), but users craved for it for more than 10 years=20
already.
Same for reflection and concepts.
If there are no volunteers to work on top prio features, committee should=
=20
find money from corporate bakers and hire (=3Dforce) people to do the job.=
=20

For non-prio features, if there are volunteers, and free time in committee,=
=20
yeah, go for it - but only once top prio features are done/blocked.

Regards,
Maciej
=20
=20

> On Wed, Jan 4, 2017 at 9:02 AM, Jens Maurer <Jens....@gmx.net=20
> <javascript:>> wrote:
>
>> On 01/04/2017 09:58 AM, Jens Maurer wrote:
>> > On 01/04/2017 08:48 AM, Oliver Kowalke wrote:
>> >> 2017-01-04 8:33 GMT+01:00 Vicente J. Botet Escriba <
>> vicent...@wanadoo.fr <javascript:> <mailto:vicent...@wanadoo.fr=20
>> <javascript:>>>:
>> >>
>> >>     This is another issue. I believe this depends on how you shell=20
>> your proposal in this forum (or in the official reflectors),
>> >>
>> >>
>> >> I got the recommendation by a committee member not to discuss the=20
>> propsal(s) in this forum (endless discussions ...)  =3D:o
>> >>
>> >>
>> >>     I was talking of  the features expected in a release, features=20
>> that the committee is already interested in, as the list of the 10-featu=
res.
>> >>
>> >>
>> >> for instance coroutines
>> >
>> > For coroutines (and as a matter of advertisement), as a personal=20
>> opinion, I am looking
>> > for an alternative to the proposal on the table, which (in my opinion)=
=20
>> has a too broad
>> > library / core interface that feels "hackish" to me (need another=20
>> feature? let's bolt
>> > it on top).
>> >
>> > There was a "resumable functions" proposal (that I didn't look into=20
>> closely),
>> > and reportedly, it didn't provide the configurability that the current
>> > coroutines proposal provides, so I can only assume that it's dead.
>>
>> As an example for the kind of re-engineering I'm looking for:
>>
>> P0352R0 Smart References through Delegation: An Alternative to N4477's=
=20
>> Operator Dot
>>
>> seems to be a substantially less involved approach to operator dot=20
>> compared to
>>
>> P0416R1 Operator Dot (R3)
>>
>> I continue to consider overloading of "operator dot" a minor nuisance,
>> and thus I very much appreciate an approach that is minimally invasive
>> to core language rules.
>>
>> Jens
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> 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=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/586CBA3B.50=
10903%40gmx.net
>> .
>>
>
>
>
> --=20
> Yours sincerely
> Artur Czajkowski
>

--=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/dffd37c1-b280-42ac-a703-e50977b51f3b%40isocpp.or=
g.

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

<div dir=3D"ltr">W dniu =C5=9Broda, 4 stycznia 2017 11:42:12 UTC+1 u=C5=BCy=
tkownik Arthur Tchaikovsky napisa=C5=82:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><div>&gt;Please stop complaining about this or t=
hat, most of the people that    participates on the elaboration of the stan=
dard are doing it on    their free time.</div><div><br></div><div>I simply =
don&#39;t understand that argument. I thought people are there not for the =
money but for the love and passion to language and they don&#39;t expect to=
 be paid for it? </div><div>So following, that people are doing it for free=
 they mustn&#39;t be ever criticized for it? </div><div>I&#39;m sorry but=
=C2=A0you are being judged by the work you produced not by the money you ar=
e being paid for that work. That&#39;s how real world works.</div><div><br>=
</div><div>If your work is of poor quality (and C++17 in many people&#39;s =
eyes is) you (the people who are responsible, the committee) should get cri=
ticized and I&#39;m glad to see that happening. Let&#39;s stop that &#39;pa=
tting each other on the back&#39; and saying to yourselves that yet again, =
you did great job. No you didn&#39;t. You blew it. </div><div>As for asking=
:</div><div>&gt;Who care if it was a good or a bad release, a minor or majo=
r    release[...]</div><div>I&#39;m pretty certain that there are lots of p=
eople who actually care a lot.</div><div><br></div><div>This situation remi=
nds me=C2=A0of a=C2=A0scene where engineer of certain brand of=C2=A0car was=
 arguing with the people (the regular users of that car) that they shouldn&=
#39;t criticize the engineer for his work because they (the users) are inca=
pable of actually making even worse car than that produced by those enginee=
rs.</div><div><br></div><div>I&#39;m sorry but=C2=A0it doesn&#39;t work tha=
t way. I, as a user, even though I&#39;m unable to have any impact (nor I&#=
39;m admittedly capable of making it)=C2=A0on a car being produced, have ev=
ery right to express my disappointment with a car. Is it poorly made? If so=
 I have right to criticize it. And I really don&#39;t care how much(or how =
little) those people involved in production of this car were paid. This (th=
e wages)=C2=A0is totally different issue.</div><div>And if there are more a=
nd more voices from users that the car is of poor quality, well, I think th=
ere is something on the matter. Even though engineers think that yet again =
they&#39;ve produced something great and pat each other on the back.</div><=
div>Same goes for films, clothes, food... If something is of poor quality u=
sers have right to criticize it even though the people making it weren&#39;=
t paid as much as they should and despite the fact that the users are incap=
able of producing such item themselves.</div></div></blockquote><div><br></=
div><div>While I don&#39;t disagree with this point of view, I&#39;d rather=
 say that they did good job, just not what was most wished for.</div><div><=
br></div><div>I think committee should really prioritize its work, esp. on =
features that should have been there long time ago: modules, reflection and=
 maybe concepts.</div><div>I get it, modules are really ungrateful piece of=
 functionality to work on (due to legacy cruft), but users craved for it fo=
r more than 10 years already.</div><div>Same for reflection and concepts.</=
div><div>If there are no volunteers to work on top prio features, committee=
 should find money from corporate bakers and hire (=3Dforce) people to do t=
he job.=C2=A0</div><div><br></div><div>For non-prio features, if there are =
volunteers, and free time in committee, yeah, go for it - but only once top=
 prio features are done/blocked.<br></div><div><br></div><div>Regards,</div=
><div>Maciej</div><div>=C2=A0</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><div class=3D"gmail_quote">On W=
ed, Jan 4, 2017 at 9:02 AM, Jens Maurer <span dir=3D"ltr">&lt;<a href=3D"ja=
vascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"2HApu0a0CwAJ" rel=3D"=
nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" on=
click=3D"this.href=3D&#39;javascript:&#39;;return true;">Jens....@gmx.net</=
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>On 01/04/2017 =
09:58 AM, Jens Maurer wrote:<br>
&gt; On 01/04/2017 08:48 AM, Oliver Kowalke wrote:<br>
&gt;&gt; 2017-01-04 8:33 GMT+01:00 Vicente J. Botet Escriba &lt;<a href=3D"=
javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"2HApu0a0CwAJ" rel=
=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;=
" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">vicent...@wana=
doo.fr</a> &lt;mailto:<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"2HApu0a0CwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#3=
9;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#3=
9;;return true;">vicent...@wanadoo.<wbr>fr</a>&gt;&gt;:<br>
&gt;&gt;<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0This is another issue. I believe this depends o=
n how you shell your proposal in this forum (or in the official reflectors)=
,<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; I got the recommendation by a committee member not to discuss the =
propsal(s) in this forum (endless discussions ...)=C2=A0 =3D:o<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0I was talking of=C2=A0 the features expected in=
 a release, features that the committee is already interested in, as the li=
st of the 10-features.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; for instance coroutines<br>
&gt;<br>
&gt; For coroutines (and as a matter of advertisement), as a personal opini=
on, I am looking<br>
&gt; for an alternative to the proposal on the table, which (in my opinion)=
 has a too broad<br>
&gt; library / core interface that feels &quot;hackish&quot; to me (need an=
other feature? let&#39;s bolt<br>
&gt; it on top).<br>
&gt;<br>
&gt; There was a &quot;resumable functions&quot; proposal (that I didn&#39;=
t look into closely),<br>
&gt; and reportedly, it didn&#39;t provide the configurability that the cur=
rent<br>
&gt; coroutines proposal provides, so I can only assume that it&#39;s dead.=
<br>
<br>
</span>As an example for the kind of re-engineering I&#39;m looking for:<br=
>
<br>
P0352R0 Smart References through Delegation: An Alternative to N4477&#39;s =
Operator Dot<br>
<br>
seems to be a substantially less involved approach to operator dot compared=
 to<br>
<br>
P0416R1 Operator Dot (R3)<br>
<br>
I continue to consider overloading of &quot;operator dot&quot; a minor nuis=
ance,<br>
and thus I very much appreciate an approach that is minimally invasive<br>
to core language rules.<br>
<span><br>
Jens<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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
2HApu0a0CwAJ" 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"2HApu0a0CwAJ" 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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/586CBA3B.5010903%40gmx.net" re=
l=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;https://gr=
oups.google.com/a/isocpp.org/d/msgid/std-proposals/586CBA3B.5010903%40gmx.n=
et&#39;;return true;" onclick=3D"this.href=3D&#39;https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/586CBA3B.5010903%40gmx.net&#39;;return =
true;">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposa=
ls/586CBA3B.5010903%<wbr>40gmx.net</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div>Yours sincerely<br=
>Artur Czajkowski</div>
</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/dffd37c1-b280-42ac-a703-e50977b51f3b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dffd37c1-b280-42ac-a703-e50977b51f3b=
%40isocpp.org</a>.<br />

------=_Part_1527_776111969.1483540770521--

------=_Part_1526_1762632770.1483540770520--

.

------=_Part_6389_1460180938.1483545254384
Content-Type: multipart/alternative;
 boundary="----=_Part_6390_2024017215.1483545254384"

------=_Part_6390_2024017215.1483545254384
Content-Type: text/plain; charset=UTF-8

On Wednesday, January 4, 2017 at 5:42:12 AM UTC-5, Arthur Tchaikovsky wrote:
>
> >Please stop complaining about this or that, most of the people that
> participates on the elaboration of the standard are doing it on their free
> time.
>
> I simply don't understand that argument. I thought people are there not
> for the money but for the love and passion to language and they don't
> expect to be paid for it?
> So following, that people are doing it for free they mustn't be ever
> criticized for it?
> I'm sorry but you are being judged by the work you produced not by the
> money you are being paid for that work. That's how real world works.
>
> If your work is of poor quality (and C++17 in many people's eyes is) you
> (the people who are responsible, the committee) should get criticized and
> I'm glad to see that happening. Let's stop that 'patting each other on the
> back' and saying to yourselves that yet again, you did great job. No you
> didn't. You blew it.
>

Here's the problem with that: C++17 is not "of poor quality".

"Many people" are *disappointed* with it because it didn't do more. "Many
people" are *disappointed* with it because they felt Bjarne (and to a
lesser extent Herb) promised them that it would be bigger than it was.
"Many people" are disappointed in it for various reasons.

But I have yet to see any wide-spread criticism of C++17 *itself*. It seems
everyone thinks that the features and functionality we got were
more-or-less fine. Virtually all the complaints are about what we *didn't
get*, which is not a measure of the quality or usefulness of the features
we actually got. So I don't buy your claim of C++17 being "of poor quality".

A car is not "of poor quality" just because it could have been better. It's
"of poor quality" if it spontaneously explodes, or if the breaks fail, or
if the engine falls out, or if it is otherwise non-functional *as a car*.
That it doesn't have an awesome sound system or the best gas mileage or
whatever does not mean it is "of poor quality".

When dealing in criticism, it is vital not to descend into hyperbole, to
not over-state a problem. Once you do, it is very easy for the people
you're criticizing to dismiss your statements as wild ranting (we are on a
thread called TOTAL RETARDATION, mind you). Calling C++17 "poor quality" is
hyperbole; it makes it hard to take your point seriously.

I agree that the fact that committee members are unpaid volunteers should
not be used to shield them from criticism. But it is unfair to criticize
the committee for not living up to *arbitrary* expectations. Bjarne
promised something he ought to have known at the time that he couldn't
deliver; go complain to *him*.

As for asking:
> >Who care if it was a good or a bad release, a minor or major release[...]
> I'm pretty certain that there are lots of people who actually care a lot.
>

Yes, there are plenty of people who care. The question is... should they?

If C++ only gets "minor" releases from here onwards, so what? If C++20
contains concepts but not reflection, and C++23 contains reflection but not
contracts, and C++26 contains contracts but not reflection-generation, and
so forth... so what? Why is this objectively bad?

If you want to accurately judge the committee's process, it seems to me
that the most effective way is to look at *why* a feature did or did not
make it into the standard in a fashion that you might deem timely. If the
reason why concepts was held back makes sense to you, then there's nothing
to complain about. If the reason why modules wasn't in C++17 is a good
reason, then why are you complaining about it not being there.

I judge the quality of people complaints based on how reasonable those
complaints are, by how much they actually understand a situation and judge
it. And most of the complaints about C++17 not having enough features don't
hold water for me. It sounds more like people crying over their pet feature
not getting in, rather than realizing the complexities of getting such
things done.

You are free to complain however much you like; God knows I've complained
about the standards process enough. But at the end of the day, what matters
is whether those are legitimate complaints. And personally, people being
disappointed because they felt that they were promised something that was
not delivered only qualifies as legitimate when the complaint is aimed at
the party responsible for those promises.

--
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/72c627ac-4e8a-4054-8e8d-33b6e1f6386b%40isocpp.org.

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

<div dir=3D"ltr">On Wednesday, January 4, 2017 at 5:42:12 AM UTC-5, Arthur =
Tchaikovsky wrote:<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>&gt;Please stop complaining about this or that, most of the peopl=
e that    participates on the elaboration of the standard are doing it on  =
  their free time.</div><div><br></div><div>I simply don&#39;t understand t=
hat argument. I thought people are there not for the money but for the love=
 and passion to language and they don&#39;t expect to be paid for it? </div=
><div>So following, that people are doing it for free they mustn&#39;t be e=
ver criticized for it? </div><div>I&#39;m sorry but=C2=A0you are being judg=
ed by the work you produced not by the money you are being paid for that wo=
rk. That&#39;s how real world works.</div><div><br></div><div>If your work =
is of poor quality (and C++17 in many people&#39;s eyes is) you (the people=
 who are responsible, the committee) should get criticized and I&#39;m glad=
 to see that happening. Let&#39;s stop that &#39;patting each other on the =
back&#39; and saying to yourselves that yet again, you did great job. No yo=
u didn&#39;t. You blew it. </div></div></blockquote><div><br>Here&#39;s the=
 problem with that: C++17 is not &quot;of poor quality&quot;.<br><br>&quot;=
Many people&quot; are <i>disappointed</i> with it because it didn&#39;t do =
more. &quot;Many people&quot; are <i>disappointed</i> with it because they =
felt Bjarne (and to a lesser extent Herb) promised them that it would be bi=
gger than it was. &quot;Many people&quot; are disappointed in it for variou=
s reasons.<br><br>But I have yet to see any wide-spread criticism of C++17 =
<i>itself</i>. It seems everyone thinks that the features and functionality=
 we got were more-or-less fine. Virtually all the complaints are about what=
 we <i>didn&#39;t get</i>, which is not a measure of the quality or usefuln=
ess of the features we actually got. So I don&#39;t buy your claim of C++17=
 being &quot;of poor quality&quot;.<br><br>A car is not &quot;of poor quali=
ty&quot; just because it could have been better. It&#39;s &quot;of poor qua=
lity&quot; if it spontaneously explodes, or if the breaks fail, or if the e=
ngine falls out, or if it is otherwise non-functional <i>as a car</i>. That=
 it doesn&#39;t have an awesome sound system or the best gas mileage or wha=
tever does not mean it is &quot;of poor quality&quot;.<br><br>When dealing =
in criticism, it is vital not to descend into hyperbole, to not over-state =
a problem. Once you do, it is very easy for the people you&#39;re criticizi=
ng to dismiss your statements as wild ranting (we are on a thread called TO=
TAL RETARDATION, mind you). Calling C++17 &quot;poor quality&quot; is hyper=
bole; it makes it hard to take your point seriously.<br><br>I agree that th=
e fact that committee members are unpaid volunteers should not be used to s=
hield them from criticism. But it is unfair to criticize the committee for =
not living up to <i>arbitrary</i> expectations. Bjarne promised something h=
e ought to have known at the time that he couldn&#39;t deliver; go complain=
 to <i>him</i>.<br><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><div>As for asking:</div><div>&gt;Who care if it was a good=
 or a bad release, a minor or major    release[...]</div><div>I&#39;m prett=
y certain that there are lots of people who actually care a lot.</div></div=
></blockquote><div><br>Yes, there are plenty of people who care. The questi=
on is... should they?<br><br>If C++ only gets &quot;minor&quot; releases fr=
om here onwards, so what? If C++20 contains concepts but not reflection, an=
d C++23 contains reflection but not contracts, and C++26 contains contracts=
 but not reflection-generation, and so forth... so what? Why is this object=
ively bad?<br><br>If you want to accurately judge the committee&#39;s proce=
ss, it seems to me that the most effective way is to look at <i>why</i> a f=
eature did or did not make it into the standard in a fashion that you might=
 deem timely. If the reason why concepts was held back makes sense to you, =
then there&#39;s nothing to complain about. If the reason why modules wasn&=
#39;t in C++17 is a good reason, then why are you complaining about it not =
being there.<br><br>I judge the quality of people complaints based on how r=
easonable those complaints are, by how much they actually understand a situ=
ation and judge it. And most of the complaints about C++17 not having enoug=
h features don&#39;t hold water for me. It sounds more like people crying o=
ver their pet feature not getting in, rather than realizing the complexitie=
s of getting such things done.<br><br>You are free to complain however much=
 you like; God knows I&#39;ve complained about the standards process enough=
.. But at the end of the day, what matters is whether those are legitimate c=
omplaints. And personally, people being disappointed because they felt that=
 they were promised something that was not delivered only qualifies as legi=
timate when the complaint is aimed at the party responsible for those promi=
ses.</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/72c627ac-4e8a-4054-8e8d-33b6e1f6386b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/72c627ac-4e8a-4054-8e8d-33b6e1f6386b=
%40isocpp.org</a>.<br />

------=_Part_6390_2024017215.1483545254384--

------=_Part_6389_1460180938.1483545254384--

.

------=_Part_8971_1568682484.1483545679850
Content-Type: multipart/alternative;
 boundary="----=_Part_8972_1072588184.1483545679850"

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



On Wednesday, January 4, 2017 at 9:39:30 AM UTC-5, m.ce...@gmail.com wrote:
>
> W dniu =C5=9Broda, 4 stycznia 2017 11:42:12 UTC+1 u=C5=BCytkownik Arthur =
Tchaikovsky=20
> napisa=C5=82:
>>
>> >Please stop complaining about this or that, most of the people that=20
>> participates on the elaboration of the standard are doing it on their fr=
ee=20
>> time.
>>
>> I simply don't understand that argument. I thought people are there not=
=20
>> for the money but for the love and passion to language and they don't=20
>> expect to be paid for it?=20
>> So following, that people are doing it for free they mustn't be ever=20
>> criticized for it?=20
>> I'm sorry but you are being judged by the work you produced not by the=
=20
>> money you are being paid for that work. That's how real world works.
>>
>> If your work is of poor quality (and C++17 in many people's eyes is) you=
=20
>> (the people who are responsible, the committee) should get criticized an=
d=20
>> I'm glad to see that happening. Let's stop that 'patting each other on t=
he=20
>> back' and saying to yourselves that yet again, you did great job. No you=
=20
>> didn't. You blew it.=20
>> As for asking:
>> >Who care if it was a good or a bad release, a minor or major release[..=
..]
>> I'm pretty certain that there are lots of people who actually care a lot=
..
>>
>> This situation reminds me of a scene where engineer of certain brand=20
>> of car was arguing with the people (the regular users of that car) that=
=20
>> they shouldn't criticize the engineer for his work because they (the use=
rs)=20
>> are incapable of actually making even worse car than that produced by th=
ose=20
>> engineers.
>>
>> I'm sorry but it doesn't work that way. I, as a user, even though I'm=20
>> unable to have any impact (nor I'm admittedly capable of making it) on a=
=20
>> car being produced, have every right to express my disappointment with a=
=20
>> car. Is it poorly made? If so I have right to criticize it. And I really=
=20
>> don't care how much(or how little) those people involved in production o=
f=20
>> this car were paid. This (the wages) is totally different issue.
>> And if there are more and more voices from users that the car is of poor=
=20
>> quality, well, I think there is something on the matter. Even though=20
>> engineers think that yet again they've produced something great and pat=
=20
>> each other on the back.
>> Same goes for films, clothes, food... If something is of poor quality=20
>> users have right to criticize it even though the people making it weren'=
t=20
>> paid as much as they should and despite the fact that the users are=20
>> incapable of producing such item themselves.
>>
>
> While I don't disagree with this point of view, I'd rather say that they=
=20
> did good job, just not what was most wished for.
>
> I think committee should really prioritize its work, esp. on features tha=
t=20
> should have been there long time ago: modules, reflection and maybe=20
> concepts.
>
I get it, modules are really ungrateful piece of functionality to work on=
=20
> (due to legacy cruft), but users craved for it for more than 10 years=20
> already.
> Same for reflection and concepts.
>

Yeah, this is what I mean when I talk about proper judgement of the=20
committee's process. In that this criticism doesn't really show that.

Modules has not been delayed because it is a "really ungrateful piece of=20
functionality to work on". People have been working on modules. *A lot of=
=20
people* have been working on modules. We have two in-progress=20
implementations *right now*. It even has its own study group.

The same goes for concepts and reflection; both have their own study groups=
=20
(though the concepts SG doesn't seem to have been doing much lately). Lots=
=20
of people are working on it to move it forward. Reflection was essentially=
=20
designing a feature from scratch, a process which required looking at=20
various designs and picking the most effective one. That process ended=20
sometime in 2016, when design agreement was reached.

These things haven't come to fruition because of people being lazy or lack=
=20
of prioritization. They've been slow because *it is hard*. Because these=20
are big, complex things that, unless you're working entirely alone, you are=
=20
not going to get finished in just 3 years. And as concepts TS shows, even=
=20
if you do, that doesn't mean you got it 100% right; some refactoring and=20
adjustment needs to be taken after you get a proof-of-concept working.

--=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/8405d335-55c0-4a94-86fd-c48ce4e56d11%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Wednesday, January 4, 2017 at 9:39:30 AM UTC-5,=
 m.ce...@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"ltr">W dniu =C5=9Broda, 4 stycznia 2017 11:42:12 UTC+1 u=C5=BCytkown=
ik Arthur Tchaikovsky napisa=C5=82:<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>&gt;Please stop complaining about this or that, most=
 of the people that    participates on the elaboration of the standard are =
doing it on    their free time.</div><div><br></div><div>I simply don&#39;t=
 understand that argument. I thought people are there not for the money but=
 for the love and passion to language and they don&#39;t expect to be paid =
for it? </div><div>So following, that people are doing it for free they mus=
tn&#39;t be ever criticized for it? </div><div>I&#39;m sorry but=C2=A0you a=
re being judged by the work you produced not by the money you are being pai=
d for that work. That&#39;s how real world works.</div><div><br></div><div>=
If your work is of poor quality (and C++17 in many people&#39;s eyes is) yo=
u (the people who are responsible, the committee) should get criticized and=
 I&#39;m glad to see that happening. Let&#39;s stop that &#39;patting each =
other on the back&#39; and saying to yourselves that yet again, you did gre=
at job. No you didn&#39;t. You blew it. </div><div>As for asking:</div><div=
>&gt;Who care if it was a good or a bad release, a minor or major    releas=
e[...]</div><div>I&#39;m pretty certain that there are lots of people who a=
ctually care a lot.</div><div><br></div><div>This situation reminds me=C2=
=A0of a=C2=A0scene where engineer of certain brand of=C2=A0car was arguing =
with the people (the regular users of that car) that they shouldn&#39;t cri=
ticize the engineer for his work because they (the users) are incapable of =
actually making even worse car than that produced by those engineers.</div>=
<div><br></div><div>I&#39;m sorry but=C2=A0it doesn&#39;t work that way. I,=
 as a user, even though I&#39;m unable to have any impact (nor I&#39;m admi=
ttedly capable of making it)=C2=A0on a car being produced, have every right=
 to express my disappointment with a car. Is it poorly made? If so I have r=
ight to criticize it. And I really don&#39;t care how much(or how little) t=
hose people involved in production of this car were paid. This (the wages)=
=C2=A0is totally different issue.</div><div>And if there are more and more =
voices from users that the car is of poor quality, well, I think there is s=
omething on the matter. Even though engineers think that yet again they&#39=
;ve produced something great and pat each other on the back.</div><div>Same=
 goes for films, clothes, food... If something is of poor quality users hav=
e right to criticize it even though the people making it weren&#39;t paid a=
s much as they should and despite the fact that the users are incapable of =
producing such item themselves.</div></div></blockquote><div><br></div><div=
>While I don&#39;t disagree with this point of view, I&#39;d rather say tha=
t they did good job, just not what was most wished for.</div><div><br></div=
><div>I think committee should really prioritize its work, esp. on features=
 that should have been there long time ago: modules, reflection and maybe c=
oncepts.</div></div></blockquote><div></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><div>I get it, modules are really ungrateful=
 piece of functionality to work on (due to legacy cruft), but users craved =
for it for more than 10 years already.</div><div>Same for reflection and co=
ncepts.</div></div></blockquote><div><br>Yeah, this is what I mean when I t=
alk about proper judgement of the committee&#39;s process. In that this cri=
ticism doesn&#39;t really show that.<br><br>Modules has not been delayed be=
cause it is a &quot;really ungrateful piece of functionality to work on&quo=
t;. People have been working on modules. <i>A lot of people</i> have been w=
orking on modules. We have two in-progress implementations <i>right now</i>=
.. It even has its own study group.<br><br>The same goes for concepts and re=
flection; both have their own study groups (though the concepts SG doesn&#3=
9;t seem to have been doing much lately). Lots of people are working on it =
to move it forward. Reflection was essentially designing a feature from scr=
atch, a process which required looking at various designs and picking the m=
ost effective one. That process ended sometime in 2016, when design agreeme=
nt was reached.<br><br>These things haven&#39;t come to fruition because of=
 people being lazy or lack of prioritization. They&#39;ve been slow because=
 <i>it is hard</i>. Because these are big, complex things that, unless you&=
#39;re working entirely alone, you are not going to get finished in just 3 =
years. And as concepts TS shows, even if you do, that doesn&#39;t mean you =
got it 100% right; some refactoring and adjustment needs to be taken after =
you get a proof-of-concept working.</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/8405d335-55c0-4a94-86fd-c48ce4e56d11%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8405d335-55c0-4a94-86fd-c48ce4e56d11=
%40isocpp.org</a>.<br />

------=_Part_8972_1072588184.1483545679850--

------=_Part_8971_1568682484.1483545679850--

.

On 2017-01-04 08:05, Oliver Kowalke wrote:
> 2017-01-03 23:39 GMT+01:00 Vicente J. Botet Escriba
> <vicente.botet@wanadoo.fr <mailto:vicente.botet@wanadoo.fr>>:
>
>     People that cares about having a major and good release for 2020,
>     should start now helping on the implementation of those features so
>     that we have more experience
>
>
> My experience is that your proposal/contribution remains unnoticed by
> the committee if you do not attend the meetings (even if you provide a
> reference implementation).
> Unfortunately I've neither the financial background to travel (several
> times) each year around the world nor my employer does.
>

I wouldn't call it unnoticed, but...

If you see it from the other perspective - in a subcommittee meeting
there are 10 guys present who have each written several proposals they
want to discuss.

What are the odds that the chairman would select *your* paper instead?



     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/o4jdu4%2410n%241%40blaine.gmane.org.

.

> On 4 Jan 2017, at 14:39, m.cencora@gmail.com wrote:
> I think committee should really prioritize its work, esp. on features tha=
t should have been there long time ago: modules, reflection and maybe conce=
pts.

.... and I can tell you what gets prioritized: what is in the interest of pe=
ople participating and paying for the privilege to do the work. The cost of=
 membership is the marginal, unimportant cost. The time spent working on pa=
pers (both reading and writing them) is the bulk, followed by the cost of a=
ttending meetings. You may not like this approach of deciding on priorities=
 but you are welcome to address things you are interested in. I contributed=
 on my own time and dime for multiple years when I had just a small income =
and zero company support (and I think it paid off dramatically), i.e., I do=
n't buy any argument along the lines of "cannot afford": it is "do not want=
 to afford".

--=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/6F461289-A0C2-46BD-A954-7AEB01782F73%40gmail.com=
..

.

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

2017-01-04 19:12 GMT+01:00 Bo Persson <bop@gmb.dk>:

Because the big players like Google, Microsoft, Intel, NVIDIA ... dominate
the standardization (with their own strategic goals).
Those companies let their employees attend each meeting - with more than
one person.
That has impact on which papers are selected and it has impact on the
outcome of votes too.
At least that was my impression ... might be wrong.

--
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%2Bwfc1_r9Fvmr8B3Z232R5ULvp96o9H5Ko29fm96ce4o_kDBOw%40mail.gmail.com.

--94eb2c032720d9d6b40545491f23
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">2017=
-01-04 19:12 GMT+01:00 Bo Persson <span dir=3D"ltr">&lt;<a href=3D"mailto:b=
op@gmb.dk" target=3D"_blank">bop@gmb.dk</a>&gt;</span>:<span class=3D"gmail=
-m_576705525073001258gmail-HOEnZb"></span><br></div><br></div><div class=3D=
"gmail_extra">Because the big players like Google, Microsoft, Intel, NVIDIA=
 ... dominate the standardization (with their own strategic goals).</div><d=
iv class=3D"gmail_extra">Those companies let their employees attend each me=
eting - with more than one person.<br>That has impact on which papers are s=
elected and it has impact on the outcome of votes too.<br></div><div class=
=3D"gmail_extra">At least that was my impression ... might be wrong.<br></d=
iv><div class=3D"gmail_extra"><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/CA%2Bwfc1_r9Fvmr8B3Z232R5ULvp96o9H5Ko=
29fm96ce4o_kDBOw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1_r9Fvm=
r8B3Z232R5ULvp96o9H5Ko29fm96ce4o_kDBOw%40mail.gmail.com</a>.<br />

--94eb2c032720d9d6b40545491f23--

.

------=_Part_1583_1915611904.1483555272963
Content-Type: multipart/alternative;
 boundary="----=_Part_1584_414962098.1483555272964"

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

W dniu =C5=9Broda, 4 stycznia 2017 17:01:20 UTC+1 u=C5=BCytkownik Nicol Bol=
as napisa=C5=82:
>
>
>
> On Wednesday, January 4, 2017 at 9:39:30 AM UTC-5, m.ce...@gmail.com=20
> wrote:
>>
>> W dniu =C5=9Broda, 4 stycznia 2017 11:42:12 UTC+1 u=C5=BCytkownik Arthur=
=20
>> Tchaikovsky napisa=C5=82:
>>>
>>> >Please stop complaining about this or that, most of the people that=20
>>> participates on the elaboration of the standard are doing it on their f=
ree=20
>>> time.
>>>
>>> I simply don't understand that argument. I thought people are there not=
=20
>>> for the money but for the love and passion to language and they don't=
=20
>>> expect to be paid for it?=20
>>> So following, that people are doing it for free they mustn't be ever=20
>>> criticized for it?=20
>>> I'm sorry but you are being judged by the work you produced not by the=
=20
>>> money you are being paid for that work. That's how real world works.
>>>
>>> If your work is of poor quality (and C++17 in many people's eyes is) yo=
u=20
>>> (the people who are responsible, the committee) should get criticized a=
nd=20
>>> I'm glad to see that happening. Let's stop that 'patting each other on =
the=20
>>> back' and saying to yourselves that yet again, you did great job. No yo=
u=20
>>> didn't. You blew it.=20
>>> As for asking:
>>> >Who care if it was a good or a bad release, a minor or major=20
>>> release[...]
>>> I'm pretty certain that there are lots of people who actually care a lo=
t.
>>>
>>> This situation reminds me of a scene where engineer of certain brand=20
>>> of car was arguing with the people (the regular users of that car) that=
=20
>>> they shouldn't criticize the engineer for his work because they (the us=
ers)=20
>>> are incapable of actually making even worse car than that produced by t=
hose=20
>>> engineers.
>>>
>>> I'm sorry but it doesn't work that way. I, as a user, even though I'm=
=20
>>> unable to have any impact (nor I'm admittedly capable of making it) on =
a=20
>>> car being produced, have every right to express my disappointment with =
a=20
>>> car. Is it poorly made? If so I have right to criticize it. And I reall=
y=20
>>> don't care how much(or how little) those people involved in production =
of=20
>>> this car were paid. This (the wages) is totally different issue.
>>> And if there are more and more voices from users that the car is of poo=
r=20
>>> quality, well, I think there is something on the matter. Even though=20
>>> engineers think that yet again they've produced something great and pat=
=20
>>> each other on the back.
>>> Same goes for films, clothes, food... If something is of poor quality=
=20
>>> users have right to criticize it even though the people making it weren=
't=20
>>> paid as much as they should and despite the fact that the users are=20
>>> incapable of producing such item themselves.
>>>
>>
>> While I don't disagree with this point of view, I'd rather say that they=
=20
>> did good job, just not what was most wished for.
>>
>> I think committee should really prioritize its work, esp. on features=20
>> that should have been there long time ago: modules, reflection and maybe=
=20
>> concepts.
>>
> I get it, modules are really ungrateful piece of functionality to work on=
=20
>> (due to legacy cruft), but users craved for it for more than 10 years=20
>> already.
>> Same for reflection and concepts.
>>
>
> Yeah, this is what I mean when I talk about proper judgement of the=20
> committee's process. In that this criticism doesn't really show that.
>
> Modules has not been delayed because it is a "really ungrateful piece of=
=20
> functionality to work on". People have been working on modules. *A lot of=
=20
> people* have been working on modules. We have two in-progress=20
> implementations *right now*. It even has its own study group.
>

It is really hard to believe that as you say given 'a lot of people'=20
working on modules and a decade of time the reason we have no modules=20
support in C++ standard is because 'it is hard'.
I'm following the isocpp forum, website, read most proposals, watch C++=20
conference videos and follow Clang development mailing lists and really=20
don't see that horde of people working on this feature.
I see mainly Gabriel Dos Reis and Richard Smith - hopefully there are way=
=20
more people working 'behind the scenes'.
But even if there are, one just cannot excuse lack of this feature for such=
=20
a long time by saying 'it is hard'. These guys are brilliant engineers, I=
=20
refuse to believe they couldn't find a solution for such a long time.
How come clang have modules support for years?!

From my point of view, the problem is not technical. It's about management=
=20
- resources, planning and decision making.
Maybe 'management' part got better in recent years, but all the previous=20
years are lost.
People are just tired of hearing yet again that we won't have modules,=20
reflection or concept in next C++ version, and that's why (at least=20
partially) they're saying that C++17 is a let-down.

Again about the priorities. I see many proposals, most of them seem to live=
=20
their own lives - i.e. there doesn't seem to be any push from committee to=
=20
finish them, who cares if they miss next version deadline.
I've yet to see a document stating what is committee's overall vision on=20
C++ near future. All I see is status reports on specific=20
proposals/features. Bjarne Stroustrup is the one with the vision, but I=20
doubt that whole committee
actually backs it, or acts actively to make that whole vision come true.

Maybe someone is able to tell us (non-committee people) what are committee=
=20
priorities? What do they plan to do to make C++ a language with features=20
that most modern programming languages have since many years?
Do they somehow encourage (hire?) people to work on most important features=
=20
or are they just 'passively' waiting for features to be finished in their=
=20
study groups so they can give their final approved/not-approved vote.

=20

> The same goes for concepts and reflection; both have their own study=20
> groups (though the concepts SG doesn't seem to have been doing much=20
> lately). Lots of people are working on it to move it forward. Reflection=
=20
> was essentially designing a feature from scratch, a process which require=
d=20
> looking at various designs and picking the most effective one. That proce=
ss=20
> ended sometime in 2016, when design agreement was reached.
>
> These things haven't come to fruition because of people being lazy or lac=
k=20
> of prioritization. They've been slow because *it is hard*. Because these=
=20
> are big, complex things that, unless you're working entirely alone, you a=
re=20
> not going to get finished in just 3 years. And as concepts TS shows, even=
=20
> if you do, that doesn't mean you got it 100% right; some refactoring and=
=20
> adjustment needs to be taken after you get a proof-of-concept working.
>

--=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/81304ce3-7f84-481b-89a8-6e72e49a025d%40isocpp.or=
g.

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

<div dir=3D"ltr">W dniu =C5=9Broda, 4 stycznia 2017 17:01:20 UTC+1 u=C5=BCy=
tkownik Nicol Bolas napisa=C5=82:<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"><br><br>On Wednesday, January 4, 2017 at 9:39:30 AM UTC=
-5, <a>m.ce...@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">W dniu =C5=9Broda, 4 stycznia 2017 11:42:12 UTC+1 u=C5=BC=
ytkownik Arthur Tchaikovsky napisa=C5=82:<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>&gt;Please stop complaining about this or that,=
 most of the people that    participates on the elaboration of the standard=
 are doing it on    their free time.</div><div><br></div><div>I simply don&=
#39;t understand that argument. I thought people are there not for the mone=
y but for the love and passion to language and they don&#39;t expect to be =
paid for it? </div><div>So following, that people are doing it for free the=
y mustn&#39;t be ever criticized for it? </div><div>I&#39;m sorry but=C2=A0=
you are being judged by the work you produced not by the money you are bein=
g paid for that work. That&#39;s how real world works.</div><div><br></div>=
<div>If your work is of poor quality (and C++17 in many people&#39;s eyes i=
s) you (the people who are responsible, the committee) should get criticize=
d and I&#39;m glad to see that happening. Let&#39;s stop that &#39;patting =
each other on the back&#39; and saying to yourselves that yet again, you di=
d great job. No you didn&#39;t. You blew it. </div><div>As for asking:</div=
><div>&gt;Who care if it was a good or a bad release, a minor or major    r=
elease[...]</div><div>I&#39;m pretty certain that there are lots of people =
who actually care a lot.</div><div><br></div><div>This situation reminds me=
=C2=A0of a=C2=A0scene where engineer of certain brand of=C2=A0car was argui=
ng with the people (the regular users of that car) that they shouldn&#39;t =
criticize the engineer for his work because they (the users) are incapable =
of actually making even worse car than that produced by those engineers.</d=
iv><div><br></div><div>I&#39;m sorry but=C2=A0it doesn&#39;t work that way.=
 I, as a user, even though I&#39;m unable to have any impact (nor I&#39;m a=
dmittedly capable of making it)=C2=A0on a car being produced, have every ri=
ght to express my disappointment with a car. Is it poorly made? If so I hav=
e right to criticize it. And I really don&#39;t care how much(or how little=
) those people involved in production of this car were paid. This (the wage=
s)=C2=A0is totally different issue.</div><div>And if there are more and mor=
e voices from users that the car is of poor quality, well, I think there is=
 something on the matter. Even though engineers think that yet again they&#=
39;ve produced something great and pat each other on the back.</div><div>Sa=
me goes for films, clothes, food... If something is of poor quality users h=
ave right to criticize it even though the people making it weren&#39;t paid=
 as much as they should and despite the fact that the users are incapable o=
f producing such item themselves.</div></div></blockquote><div><br></div><d=
iv>While I don&#39;t disagree with this point of view, I&#39;d rather say t=
hat they did good job, just not what was most wished for.</div><div><br></d=
iv><div>I think committee should really prioritize its work, esp. on featur=
es that should have been there long time ago: modules, reflection and maybe=
 concepts.</div></div></blockquote><div></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div>I get it, modules are really ungrateful pi=
ece of functionality to work on (due to legacy cruft), but users craved for=
 it for more than 10 years already.</div><div>Same for reflection and conce=
pts.</div></div></blockquote><div><br>Yeah, this is what I mean when I talk=
 about proper judgement of the committee&#39;s process. In that this critic=
ism doesn&#39;t really show that.<br><br>Modules has not been delayed becau=
se it is a &quot;really ungrateful piece of functionality to work on&quot;.=
 People have been working on modules. <i>A lot of people</i> have been work=
ing on modules. We have two in-progress implementations <i>right now</i>. I=
t even has its own study group.<br></div></div></blockquote><div><br>It is =
really hard to believe that as you say given &#39;a lot of people&#39; work=
ing on modules and a decade of time the reason we have no modules support i=
n C++ standard is because &#39;it is hard&#39;.<br>I&#39;m following the is=
ocpp forum, website, read most proposals, watch C++ conference videos and f=
ollow Clang development mailing lists and really don&#39;t see that horde o=
f people working on this feature.<br>I see mainly Gabriel Dos Reis and Rich=
ard Smith - hopefully there are way more people working &#39;behind the sce=
nes&#39;.<br>But even if there are, one just cannot excuse lack of this fea=
ture for such a long time by saying &#39;it is hard&#39;. These guys are br=
illiant engineers, I refuse to believe they couldn&#39;t find a solution fo=
r such a long time.<br>How come clang have modules support for years?!<br><=
br>From my point of view, the problem is not technical. It&#39;s about mana=
gement - resources, planning and decision making.<br>Maybe &#39;management&=
#39; part got better in recent years, but all the previous years are lost.<=
br>People are just tired of hearing yet again that we won&#39;t have module=
s, reflection or concept in next C++ version, and that&#39;s why (at least =
partially) they&#39;re saying that C++17 is a let-down.<br><br>Again about =
the priorities. I see many proposals, most of them seem to live their own l=
ives - i.e. there doesn&#39;t seem to be any push from committee to finish =
them, who cares if they miss next version deadline.<br>I&#39;ve yet to see =
a document stating what is committee&#39;s overall vision on C++ near futur=
e. All I see is status reports on specific proposals/features. Bjarne Strou=
strup is the one with the vision, but I doubt that whole committee<br>actua=
lly backs it, or acts actively to make that whole vision come true.<br><br>=
Maybe someone is able to tell us (non-committee people) what are committee =
priorities? What do they plan to do to make C++ a language with features th=
at most modern programming languages have since many years?<br>Do they some=
how encourage (hire?) people to work on most important features or are they=
 just &#39;passively&#39; waiting for features to be finished in their stud=
y groups so they can give their final approved/not-approved vote.<br><br>=
=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>The same goes for concepts and reflection; both have their own study gr=
oups (though the concepts SG doesn&#39;t seem to have been doing much latel=
y). Lots of people are working on it to move it forward. Reflection was ess=
entially designing a feature from scratch, a process which required looking=
 at various designs and picking the most effective one. That process ended =
sometime in 2016, when design agreement was reached.<br><br>These things ha=
ven&#39;t come to fruition because of people being lazy or lack of prioriti=
zation. They&#39;ve been slow because <i>it is hard</i>. Because these are =
big, complex things that, unless you&#39;re working entirely alone, you are=
 not going to get finished in just 3 years. And as concepts TS shows, even =
if you do, that doesn&#39;t mean you got it 100% right; some refactoring an=
d adjustment needs to be taken after you get a proof-of-concept working.</d=
iv></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/81304ce3-7f84-481b-89a8-6e72e49a025d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/81304ce3-7f84-481b-89a8-6e72e49a025d=
%40isocpp.org</a>.<br />

------=_Part_1584_414962098.1483555272964--

------=_Part_1583_1915611904.1483555272963--

.

On 01/04/2017 07:41 PM, m.cencora@gmail.com wrote:
> Maybe someone is able to tell us (non-committee people) what are committee priorities? What do they plan to do to make C++ a language with features that most modern programming languages have since many years?
> Do they somehow encourage (hire?) people to work on most important features or are they just 'passively' waiting for features to be finished in their study groups so they can give their final approved/not-approved vote.

The committee is set of people more or less tangentially involved with C++,
but otherwise from very diverse backgrounds.  There are about 100 people in
attendance for a meeting.  Is there a vision?  Not one, but several, some
of them possibly disjoint.

Some people are paid to attend, others attend on their own dime.
All put substantially more hours into the standardization process than
what they're actually paid for, and everyone sets his/her own priorities.

Sometimes, a feature is added because a company selling C++-related
products is compelled by their users to offer a certain feature, and
the company is responsible enough to actually standardize the feature
instead of having a vendor extension.  My unverified guess is that this
happened with the operator new/delete extensions allowing to specify
alignment.  Intel certainly has an interest to make their SIMD stuff
work, and it's kind of a roadblock not to be able to allocate suitably
aligned memory in the first place.

Sometimes, a feature is added because an individual (possibly triggered
by her daily work) saw a need for a feature and decided to invest
enough time to see it through.  This is what happened with
to_chars() / from_chars().

Sometimes, a feature is discussed and progressed, but a substantial part
of the committee has sustained reservations against the shape of the
feature, thus failing to achieve consensus.  This happened with defaulted
comparison operators (until now) and unified call syntax.

Regarding modules in particular, the #include model has shown its age
since 25+ years, but nobody actually (dared to?) attack the problem
in the sense of trying an implementation and writing a paper until fairly
recently.  I'm sure we'd have modules since 5 years or so if someone
had started working on them in earnest 10-15 years ago.

Jens

--
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/586D5FB9.8090500%40gmx.net.

.

------=_Part_5184_514919140.1483573236284
Content-Type: multipart/alternative;
 boundary="----=_Part_5185_1604294420.1483573236285"

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

On Wednesday, January 4, 2017 at 5:35:43 AM UTC-8, Jens Maurer wrote:
>
> On 01/04/2017 12:35 PM, Dietmar K=C3=BChl wrote:=20
> >> On 4 Jan 2017, at 08:54, Jens Maurer <Jens....@gmx.net <javascript:>>=
=20
> wrote:=20
> >> There were several (many) C++ committee meetings where the comparison=
=20
> operators=20
> >> were discussed, sometimes (it seems to me) not loop-free.=20
>
> A somewhat novel approach would be for =3D=3D and !=3D to be default=20
> (opt-out) and < and friends to be opt-in.  Arguably, anything that=20
> can be copied has a meaningful =3D=3D.=20
>

This is a total derailment, but if ever a thread was made to be derailed,=
=20
this thread would be it. ;)
I will gladly take the other side of that "arguably", if anyone ever wants=
=20
to argue about it. Namely, IEEE `float` and `double` are copiable but=20
copies are not always =3D=3D to each other.

    double nan =3D std::nan(nullptr);
    double other_nan =3D nan;  // make a "copy"
    assert(!(nan =3D=3D other_nan));  // the copies are not =3D=3D to each =
other

Philosophically this is fine; we just say that IEEE `float` and `double`=20
are not regular types. But it's awfully awkward in practice.
http://stackoverflow.com/questions/4816156/are-ieee-floats-valid-key-types-=
for-stdmap-and-stdset
AFAIK there is still no "strict total ordering" library facility in C++.

And as long as you have primitive types with wacky non-total orders, you=20
have to deal with really awkward cases like

    struct S { double x, y; };  // plus whatever gymnastics are needed to=
=20
enable default comparisons
    S a =3D { std::nan(nullptr), 3.0 };
    S b =3D { std::nan(nullptr), 2.0 };
    assert(!(a < b) && !(a > b) && !(a =3D=3D b));  // presumably, struct S=
 has=20
no strict total order

I will also happily take the role of explaining why after so many years we=
=20
still don't have
- IEEE floating-point types as template non-type parameters
- strings as template non-type parameters
because the reasons are the same. Just because some type has a copy=20
constructor and an equality-comparison operator, doesn't mean it's a=20
regular type.

(And while I love Concepts Lite in general, I must admit: if you think=20
about this kind of stuff for long enough, you'll start to empathize with=20
the people who oppose the whole idea of=20
"concepts"-as-syntactic-but-not-semantic-constraints.)

=E2=80=93Arthur

--=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/0b419f24-0632-423b-ab56-f4a781fc9967%40isocpp.or=
g.

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

<div dir=3D"ltr">On Wednesday, January 4, 2017 at 5:35:43 AM UTC-8, Jens Ma=
urer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 01/04/2017 12:35=
 PM, Dietmar K=C3=BChl wrote:
<br>&gt;&gt; On 4 Jan 2017, at 08:54, Jens Maurer &lt;<a href=3D"javascript=
:" target=3D"_blank" gdf-obfuscated-mailto=3D"e-35tr69CwAJ" rel=3D"nofollow=
" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D=
"this.href=3D&#39;javascript:&#39;;return true;">Jens....@gmx.net</a>&gt; w=
rote:
<br>&gt;&gt; There were several (many) C++ committee meetings where the com=
parison operators
<br>&gt;&gt; were discussed, sometimes (it seems to me) not loop-free.
<br><br>A somewhat novel approach would be for =3D=3D and !=3D to be defaul=
t
<br>(opt-out) and &lt; and friends to be opt-in. =C2=A0Arguably, anything t=
hat
<br>can be copied has a meaningful =3D=3D.
<br></blockquote><div><br></div><div>This is a total derailment, but if eve=
r a thread was made to be derailed, this thread would be it. ;)</div><div>I=
 will gladly take the other side of that &quot;arguably&quot;, if anyone ev=
er wants to argue about it. Namely, IEEE `float` and `double` are copiable =
but copies are not always =3D=3D to each other.<br></div><div><br></div><di=
v>=C2=A0 =C2=A0 double nan =3D std::nan(nullptr);</div><div>=C2=A0 =C2=A0 d=
ouble other_nan =3D nan; =C2=A0// make a &quot;copy&quot;</div><div>=C2=A0 =
=C2=A0 assert(!(nan =3D=3D other_nan)); =C2=A0// the copies are not =3D=3D =
to each other</div><div><br></div><div>Philosophically this is fine; we jus=
t say that IEEE `float` and `double` are not regular types. But it&#39;s aw=
fully awkward in practice.</div><div><a href=3D"http://stackoverflow.com/qu=
estions/4816156/are-ieee-floats-valid-key-types-for-stdmap-and-stdset">http=
://stackoverflow.com/questions/4816156/are-ieee-floats-valid-key-types-for-=
stdmap-and-stdset</a><br></div><div>AFAIK there is still no &quot;strict to=
tal ordering&quot; library facility in C++.</div><div><br></div><div>And as=
 long as you have primitive types with wacky non-total orders, you have to =
deal with really awkward cases like</div><div><br></div><div>=C2=A0 =C2=A0 =
struct S { double x, y; }; =C2=A0// plus whatever gymnastics are needed to =
enable default comparisons</div><div><div>=C2=A0 =C2=A0 S a =3D { std::nan(=
nullptr), 3.0 };</div></div><div><div>=C2=A0 =C2=A0 S b =3D { std::nan(null=
ptr), 2.0 };</div></div><div>=C2=A0 =C2=A0 assert(!(a &lt; b) &amp;&amp; !(=
a &gt; b) &amp;&amp; !(a =3D=3D b)); =C2=A0// presumably, struct S has no s=
trict total order</div><div><br></div><div>I will also happily take the rol=
e of explaining why after so many years we still don&#39;t have</div><div>-=
 IEEE floating-point types as template non-type parameters</div><div>- stri=
ngs as template non-type parameters</div><div>because the reasons are the s=
ame. Just because some type has a copy constructor and an equality-comparis=
on operator, doesn&#39;t mean it&#39;s a regular type.</div><div><br></div>=
<div>(And while I love Concepts Lite in general, I must admit: if you think=
 about this kind of stuff for long enough, you&#39;ll start to empathize wi=
th the people who oppose the whole idea of &quot;concepts&quot;-as-syntacti=
c-but-not-semantic-constraints.)</div><div><br></div><div>=E2=80=93Arthur</=
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/0b419f24-0632-423b-ab56-f4a781fc9967%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0b419f24-0632-423b-ab56-f4a781fc9967=
%40isocpp.org</a>.<br />

------=_Part_5185_1604294420.1483573236285--

------=_Part_5184_514919140.1483573236284--

.

This is a multi-part message in MIME format.
--------------8797938E2085C05126B6F686
Content-Type: text/plain; charset=UTF-8; format=flowed



On 04/01/2017 19:40, Oliver Kowalke wrote:
> 2017-01-04 19:12 GMT+01:00 Bo Persson <bop@gmb.dk <mailto:bop@gmb.dk>>:
>
> Because the big players like Google, Microsoft, Intel, NVIDIA ...
> dominate the standardization (with their own strategic goals).
Not really. I am always impressed on how unpolitical the committee is.
There are a few issues (especially around concepts) where you can sense
previous differences resurface, but on the whole I have never
experienced a more pragmatic and accepting discussion culture.
I have lost count about how often someone said "oh, I didn't understand
this before, you are right, I was wrong" after a heated discussion.

> Those companies let their employees attend each meeting - with more
> than one person.
Yes, but they do not always (not even often) agree, and they certainly
do not form voting blocks.
People generally represent (and vote according) their own preferences
(which may of course be colored by their experiences in their company).
In the rare cases where they vote according to their companies guidance,
they do give ample notice and reason.
> That has impact on which papers are selected
Mostly any paper with either author or suitable champion available will
be discussed.
Having somebody there who is deeply familiar with the proposal and the
problem domain is essential.
Especially in complex and where controversial approaches are proposed
(like e.g. coroutines) it is almost impossible to assess the merits if
the authors are not there to defend the paper.
> and it has impact on the outcome of votes too.
Somewhat. Most impact can be and is made by convincing arguments.

Best regards

Fabio

--
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/0cf3d1e7-8b47-deef-2f7c-8336f4fec963%40gmx.net.

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <p><br>
    </p>
    <br>
    <div class=3D"moz-cite-prefix">On 04/01/2017 19:40, Oliver Kowalke
      wrote:<br>
    </div>
    <blockquote
cite=3D"mid:CA+wfc1_r9Fvmr8B3Z232R5ULvp96o9H5Ko29fm96ce4o_kDBOw@mail.gmail.=
com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">2017-01-04 19:12 GMT+01:00 Bo Persson
            <span dir=3D"ltr">&lt;<a moz-do-not-send=3D"true"
                href=3D"mailto:bop@gmb.dk" target=3D"_blank">bop@gmb.dk</a>=
&gt;</span>:<span
              class=3D"gmail-m_576705525073001258gmail-HOEnZb"></span><br>
          </div>
          <br>
        </div>
        <div class=3D"gmail_extra">Because the big players like Google,
          Microsoft, Intel, NVIDIA ... dominate the standardization
          (with their own strategic goals).</div>
      </div>
    </blockquote>
    Not really. I am always impressed on how unpolitical the committee
    is. There are a few issues (especially around concepts) where you
    can sense previous differences resurface, but on the whole I have
    never experienced a more pragmatic and accepting discussion culture.
    <br>
    I have lost count about how often someone said "oh, I didn't
    understand this before, you are right, I was wrong" after a heated
    discussion. <br>
    <br>
    <blockquote
cite=3D"mid:CA+wfc1_r9Fvmr8B3Z232R5ULvp96o9H5Ko29fm96ce4o_kDBOw@mail.gmail.=
com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">Those companies let their employees
          attend each meeting - with more than one person.<br>
        </div>
      </div>
    </blockquote>
    Yes, but they do not always (not even often) agree, and they
    certainly do not form voting blocks.<br>
    People generally represent (and vote according) their own
    preferences (which may of course be colored by their experiences in
    their company).<br>
    In the rare cases where they vote according to their companies
    guidance, they do give ample notice and reason. <br>
    <blockquote
cite=3D"mid:CA+wfc1_r9Fvmr8B3Z232R5ULvp96o9H5Ko29fm96ce4o_kDBOw@mail.gmail.=
com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">That has impact on which papers are
          selected </div>
      </div>
    </blockquote>
    Mostly any paper with either author or suitable champion available
    will be discussed. <br>
    Having somebody there who is deeply familiar with the proposal and
    the problem domain is essential. <br>
    Especially in complex and where controversial approaches are
    proposed (like e.g. coroutines) it is almost impossible to assess
    the merits if the authors are not there to defend the paper.<br>
    <blockquote
cite=3D"mid:CA+wfc1_r9Fvmr8B3Z232R5ULvp96o9H5Ko29fm96ce4o_kDBOw@mail.gmail.=
com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">and it has impact on the outcome of
          votes too.<br>
        </div>
      </div>
    </blockquote>
    Somewhat. Most impact can be and is made by convincing arguments.<br>
    <br>
    Best regards<br>
    <br>
    Fabio<br>
    <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/0cf3d1e7-8b47-deef-2f7c-8336f4fec963%=
40gmx.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/0cf3d1e7-8b47-deef-2f7c-8336f4fec963%40=
gmx.net</a>.<br />

--------------8797938E2085C05126B6F686--

.

------=_Part_2826_1177337139.1483586061438
Content-Type: multipart/alternative;
 boundary="----=_Part_2827_649594074.1483586061438"

------=_Part_2827_649594074.1483586061438
Content-Type: text/plain; charset=UTF-8

On Wednesday, January 4, 2017 at 3:49:00 PM UTC-5, Jens Maurer wrote:
>
> On 01/04/2017 07:41 PM, m.ce...@gmail.com <javascript:> wrote:
> > Maybe someone is able to tell us (non-committee people) what are
> committee priorities? What do they plan to do to make C++ a language with
> features that most modern programming languages have since many years?
> > Do they somehow encourage (hire?) people to work on most important
> features or are they just 'passively' waiting for features to be finished
> in their study groups so they can give their final approved/not-approved
> vote.
>
> The committee is set of people more or less tangentially involved with
> C++,
> but otherwise from very diverse backgrounds.  There are about 100 people
> in
> attendance for a meeting.  Is there a vision?  Not one, but several, some
> of them possibly disjoint.
>
> Some people are paid to attend, others attend on their own dime.
> All put substantially more hours into the standardization process than
> what they're actually paid for, and everyone sets his/her own priorities.
>
> Sometimes, a feature is added because a company selling C++-related
> products is compelled by their users to offer a certain feature, and
> the company is responsible enough to actually standardize the feature
> instead of having a vendor extension.  My unverified guess is that this
> happened with the operator new/delete extensions allowing to specify
> alignment.  Intel certainly has an interest to make their SIMD stuff
> work, and it's kind of a roadblock not to be able to allocate suitably
> aligned memory in the first place.
>
> Sometimes, a feature is added because an individual (possibly triggered
> by her daily work) saw a need for a feature and decided to invest
> enough time to see it through.  This is what happened with
> to_chars() / from_chars().
>
> Sometimes, a feature is discussed and progressed, but a substantial part
> of the committee has sustained reservations against the shape of the
> feature, thus failing to achieve consensus.  This happened with defaulted
> comparison operators (until now) and unified call syntax.
>

I think these are probably my biggest concerns, in terms of
standardization. Particularly for UCS.

I say that because, while the "sustained reservation" people may have a
point, that point cannot change the fact that *we need UCS*. One form, the
other, or both. But this is functionality that we as C++ users absolutely
need.

Every time you have to do `using std::swap` before `swap`ing some object,
you're doing something that UCS ought to handle. The same goes for global
`begin`, `end`, `size`, etc. This is a growing problem, one with Ranges TS
is only going to exacerbate. And "sustained reservations" don't actually
fix problems.

This is where I think it would be good to be able to separate technical
reservations (ie: the feature is broken and/or doesn't work to achieve its
stated goal) from other reservations. And that if a feature is going to
solve a problem that the language really needs to solve, then I believe
that non-technical reservations should not be counted as strongly as
technical reservations.

Now, that's not to say that the concerns about UCS were all non-technical.
There were good technical reasons to ditch member-to-global transformation
(though I really wish someone had taken the time to work around them). But
looking at the minutes from Jacksonville, the arguments against it don't
seem to be technical so much as *fear*.

And where was all that fear when list-initialization's rules were being put
together ;)

Essentially, the committee doesn't focus so much on problems as proposals.
Motivations are important only in measuring whether a proposal achieves
something worthwhile; the idea that a proposal could be "too important to
fail" (or at least "too important to fail for any reason other than serious
technical flaws") is not dealt with. And that isn't good.

Regarding modules in particular, the #include model has shown its age
> since 25+ years, but nobody actually (dared to?) attack the problem
> in the sense of trying an implementation and writing a paper until fairly
> recently.  I'm sure we'd have modules since 5 years or so if someone
> had started working on them in earnest 10-15 years ago.
>

I think this really needs to be emphasized.

Back in 2007, modules was being talked about. But there wasn't really an
implementation of it anywhere. Not even as a proof-of-concept. Even C++11's
insane concept stuff had a proof-of-concept implementation. But modules
didn't seem to be moving towards an implementation.

What makes me feel like modules is really going to happen is not the fact
that there's a proposal. It was when Microsoft basically said, "hey, we're
implementing this. Right now. Our compiler's next version will have a
first-pass implementation of it."

For highly complex proposals like modules, implementations are absolutely
key for getting them moving forward. And this is a good thing. It makes
sure that complicated proposals can't just create things out of whole cloth
without proving that they work.

This is also unfortunately the reason why P0057 is moving forward (though
in a TS), while any alternatives are at present just ink on a page. Because
someone is actually implementing P0057, while nobody even has design
agreement on an alternative, let alone a genuine implementation. Outside of
P0099 of course, but that's a pure-library thing.

--
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/f9259329-7e00-4838-a365-e22cd2ea6879%40isocpp.org.

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

<div dir=3D"ltr">On Wednesday, January 4, 2017 at 3:49:00 PM UTC-5, Jens Ma=
urer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 01/04/2017 07:41=
 PM, <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"j1M=
-jWPVCwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39=
;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">=
m.ce...@gmail.com</a> wrote:
<br>&gt; Maybe someone is able to tell us (non-committee people) what are c=
ommittee priorities? What do they plan to do to make C++ a language with fe=
atures that most modern programming languages have since many years?
<br>&gt; Do they somehow encourage (hire?) people to work on most important=
 features or are they just &#39;passively&#39; waiting for features to be f=
inished in their study groups so they can give their final approved/not-app=
roved vote.
<br>
<br>The committee is set of people more or less tangentially involved with =
C++,
<br>but otherwise from very diverse backgrounds. =C2=A0There are about 100 =
people in
<br>attendance for a meeting. =C2=A0Is there a vision? =C2=A0Not one, but s=
everal, some
<br>of them possibly disjoint.
<br>
<br>Some people are paid to attend, others attend on their own dime.
<br>All put substantially more hours into the standardization process than
<br>what they&#39;re actually paid for, and everyone sets his/her own prior=
ities.
<br>
<br>Sometimes, a feature is added because a company selling C++-related
<br>products is compelled by their users to offer a certain feature, and
<br>the company is responsible enough to actually standardize the feature
<br>instead of having a vendor extension. =C2=A0My unverified guess is that=
 this
<br>happened with the operator new/delete extensions allowing to specify
<br>alignment. =C2=A0Intel certainly has an interest to make their SIMD stu=
ff
<br>work, and it&#39;s kind of a roadblock not to be able to allocate suita=
bly
<br>aligned memory in the first place.
<br>
<br>Sometimes, a feature is added because an individual (possibly triggered
<br>by her daily work) saw a need for a feature and decided to invest
<br>enough time to see it through. =C2=A0This is what happened with
<br>to_chars() / from_chars().
<br>
<br>Sometimes, a feature is discussed and progressed, but a substantial par=
t
<br>of the committee has sustained reservations against the shape of the
<br>feature, thus failing to achieve consensus. =C2=A0This happened with de=
faulted
<br>comparison operators (until now) and unified call syntax.<br></blockquo=
te><div><br>I think these are probably my biggest concerns, in terms of sta=
ndardization. Particularly for UCS.<br><br>I say that because, while the &q=
uot;sustained reservation&quot; people may have a point, that point cannot =
change the fact that <i>we need UCS</i>. One form, the other, or both. But =
this is functionality that we as C++ users absolutely need.<br><br>Every ti=
me you have to do `using std::swap` before `swap`ing some object, you&#39;r=
e doing something that UCS ought to handle. The same goes for global `begin=
`, `end`, `size`, etc. This is a growing problem, one with Ranges TS is onl=
y going to exacerbate. And &quot;sustained reservations&quot; don&#39;t act=
ually fix problems.<br><br>This is where I think it would be good to be abl=
e to separate technical reservations (ie: the feature is broken and/or does=
n&#39;t work to achieve its stated goal) from other reservations. And that =
if a feature is going to solve a problem that the language really needs to =
solve, then I believe that non-technical reservations should not be counted=
 as strongly as technical reservations.<br><br>Now, that&#39;s not to say t=
hat the concerns about UCS were all non-technical. There were good technica=
l reasons to ditch member-to-global transformation (though I really wish so=
meone had taken the time to work around them). But looking at the minutes f=
rom Jacksonville, the arguments against it don&#39;t seem to be technical s=
o much as <i>fear</i>.<br><br>And where was all that fear when list-initial=
ization&#39;s rules were being put together ;)<br><br>Essentially, the comm=
ittee doesn&#39;t focus so much on problems as proposals. Motivations are i=
mportant only in measuring whether a proposal achieves something worthwhile=
; the idea that a proposal could be &quot;too important to fail&quot; (or a=
t least &quot;too important to fail for any reason other than serious techn=
ical flaws&quot;) is not dealt with. And that isn&#39;t good.<br><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">
Regarding modules in particular, the #include model has shown its age
<br>since 25+ years, but nobody actually (dared to?) attack the problem
<br>in the sense of trying an implementation and writing a paper until fair=
ly
<br>recently. =C2=A0I&#39;m sure we&#39;d have modules since 5 years or so =
if someone
<br>had started working on them in earnest 10-15 years ago.<br></blockquote=
><div><br>I think this really needs to be emphasized.<br><br>Back in 2007, =
modules was being talked about. But there wasn&#39;t really an implementati=
on of it anywhere. Not even as a proof-of-concept. Even C++11&#39;s insane =
concept stuff had a proof-of-concept implementation. But modules didn&#39;t=
 seem to be moving towards an implementation.<br><br>What makes me feel lik=
e modules is really going to happen is not the fact that there&#39;s a prop=
osal. It was when Microsoft basically said, &quot;hey, we&#39;re implementi=
ng this. Right now. Our compiler&#39;s next version will have a first-pass =
implementation of it.&quot;<br><br>For highly complex proposals like module=
s, implementations are absolutely key for getting them moving forward. And =
this is a good thing. It makes sure that complicated proposals can&#39;t ju=
st create things out of whole cloth without proving that they work.<br><br>=
This is also unfortunately the reason why P0057 is moving forward (though i=
n a TS), while any alternatives are at present just ink on a page. Because =
someone is actually implementing P0057, while nobody even has design agreem=
ent on an alternative, let alone a genuine implementation. Outside of P0099=
 of course, but that&#39;s a pure-library thing.<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/f9259329-7e00-4838-a365-e22cd2ea6879%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f9259329-7e00-4838-a365-e22cd2ea6879=
%40isocpp.org</a>.<br />

------=_Part_2827_649594074.1483586061438--

------=_Part_2826_1177337139.1483586061438--

.

------=_Part_1529_1719375698.1483586243584
Content-Type: multipart/alternative;
 boundary="----=_Part_1530_127222100.1483586243585"

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



On Wednesday, January 4, 2017 at 1:22:38 PM UTC-5, Dietmar K=C3=BChl wrote:
>
> > On 4 Jan 2017, at 14:39, m.ce...@gmail.com <javascript:> wrote:=20
> > I think committee should really prioritize its work, esp. on features=
=20
> that should have been there long time ago: modules, reflection and maybe=
=20
> concepts.=20
>
> ... and I can tell you what gets prioritized: what is in the interest of=
=20
> people participating and paying for the privilege to do the work. The cos=
t=20
> of membership is the marginal, unimportant cost. The time spent working o=
n=20
> papers (both reading and writing them) is the bulk, followed by the cost =
of=20
> attending meetings. You may not like this approach of deciding on=20
> priorities but you are welcome to address things you are interested in. I=
=20
> contributed on my own time and dime for multiple years when I had just a=
=20
> small income and zero company support (and I think it paid off=20
> dramatically), i.e., I don't buy any argument along the lines of "cannot=
=20
> afford": it is "do not want to afford".


.... you don't buy the argument that people in the programming profession=20
genuinely cannot afford to spend several thousand dollars and a week of=20
time off?

Not having money is a thing that happens, even to programmers. And if your=
=20
employer doesn't/can't give you that week off... then you don't get it.=20
That's also a thing that happens.

The fact that you happen to be in a position (both financially and=20
otherwise) to make it work out should not in any way be taken as proof that=
=20
everyone else in somehow in that same position.

--=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/6fc0d726-843b-4ef1-b92e-17df1f12d619%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Wednesday, January 4, 2017 at 1:22:38 PM UTC-5,=
 Dietmar K=C3=BChl wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; =
On 4 Jan 2017, at 14:39, <a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"8Owz9mbNCwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:=
&#39;;return true;">m.ce...@gmail.com</a> wrote:
<br>&gt; I think committee should really prioritize its work, esp. on featu=
res that should have been there long time ago: modules, reflection and mayb=
e concepts.
<br>
<br>... and I can tell you what gets prioritized: what is in the interest o=
f people participating and paying for the privilege to do the work. The cos=
t of membership is the marginal, unimportant cost. The time spent working o=
n papers (both reading and writing them) is the bulk, followed by the cost =
of attending meetings. You may not like this approach of deciding on priori=
ties but you are welcome to address things you are interested in. I contrib=
uted on my own time and dime for multiple years when I had just a small inc=
ome and zero company support (and I think it paid off dramatically), i.e., =
I don&#39;t buy any argument along the lines of &quot;cannot afford&quot;: =
it is &quot;do not want to afford&quot;.</blockquote><div><br>... you don&#=
39;t buy the argument that people in the programming profession genuinely c=
annot afford to spend several thousand dollars and a week of time off?<br><=
br>Not having money is a thing that happens, even to programmers. And if yo=
ur employer doesn&#39;t/can&#39;t give you that week off... then you don&#3=
9;t get it. That&#39;s also a thing that happens.<br><br>The fact that you =
happen to be in a position (both financially and otherwise) to make it work=
 out should not in any way be taken as proof that everyone else in somehow =
in that same position.<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/6fc0d726-843b-4ef1-b92e-17df1f12d619%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6fc0d726-843b-4ef1-b92e-17df1f12d619=
%40isocpp.org</a>.<br />

------=_Part_1530_127222100.1483586243585--

------=_Part_1529_1719375698.1483586243584--

.

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

El 11/8/2016 10:02, <looseonthestreet@gmail.com> escribi=C3=B3:

Is even ANY of this retardation fixed in C++17?


No, because nobody cared to write a proposal for this. Committee is
proposals-powered. Proposals are real_needs-powered. It seems you're the
only guy that cares about them.
If you do enough, write the proposals as any non retarded would do. Why to
expect others to work for your itch?



On Wednesday, June 12, 2013 at 1:10:52 AM UTC-7, looseont...@gmail.com
wrote:
>
> Hi,
>
>
> template <class X> void f() {}
> template <> void f<int>() {}
> COMPILES
>
>
> struct S {
>     template <class X> void f() {}
>     template <> void f<int>() {}
> };
> --> error: explicit specialization of 'f' in class scope
> FUCKING RETARDED
> WOW IT REALLY MAKES SENSE THAT THIS WORKS AT GLOBAL SCOPE BUT NOT IN-CLAS=
S
>
>
> struct S {
>     template <class X> struct Inner {};
>     template <> struct Inner<int> {};
> };
> --> error: explicit specialization of 'Inner' in class scope
> FUCKING RETARDED
>
>
> struct S {
>     template <class X, class =3D void> struct Inner {};
>     template <class bullshit> struct Inner<int, bullshit> {};
> };
> WOW, RETARDS, WORKS WITH A STUPID-RETARDED WORKAROUND
>
>
> struct S {
>     template <class X, class=3Dvoid> void f() {}
>     template <class bullshit> void f<int, bullshit>() {}
> };
> --> function template partial specialization is not allowed
> FUCKING RETARDED
> WOW THE RETARDED WORKAROUND DOESN'T WORK FOR FUNCTIONS
>
>
> template <class X> void f(X x) {}
> template <class X> void f(X* x) {}
> OH, OK THIS GOOD
>
>
> template <class X, class Y> void f() {}
> template <class Y> void f<int, Y>() {}
> --> function template partial specialization is not allowed
> FUCKING RETARDED.
>
>
> I don't even want to hear 1 piece of bullshit out of a single one of you
> people's mouths about this one.
> If you give me one piece of bullshit, you're a fucking n00b.
>
> Every one of these things is used for metaprogramming.
>
> After 15 years of awareness about these problems, nothing was fixed.
> And now with C++14, yet another oversight release, we're heading for 20
> years of fucking retardation.
>
> Thank you standards body people for your retarded level of awareness, you
> fucking retards.
> Can you fix the holes you fucking retards?
>
> --
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/76e37e62-147b-4bec-
8ab5-15f0051787b3%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/76e37e62-147b=
-4bec-8ab5-15f0051787b3%40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter=
>
..

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

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

<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">El 11/8/2016 10:02,  &lt;<a href=3D"mailto:looseonthestreet@gmail=
..com">looseonthestreet@gmail.com</a>&gt; escribi=C3=B3:<br type=3D"attribut=
ion"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"ltr">Is even ANY of this retardat=
ion fixed in C++17?<br></div></blockquote></div></div></div><div dir=3D"aut=
o"><br></div><div dir=3D"auto">No, because nobody cared to write a proposal=
 for this. Committee is proposals-powered. Proposals are real_needs-powered=
.. It seems you&#39;re the only guy that cares about them.</div><div dir=3D"=
auto">If you do enough, write the proposals as any non retarded would do. W=
hy to expect others to work for your itch?</div><div dir=3D"auto"><br></div=
><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_extra"><=
div class=3D"gmail_quote"><blockquote class=3D"quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>On =
Wednesday, June 12, 2013 at 1:10:52 AM UTC-7, <a href=3D"mailto:looseont...=
@gmail.com" target=3D"_blank">looseont...@gmail.com</a> wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div>Hi,</div><div><br></div><div><br></div><div=
>template &lt;class X&gt; void f() {}</div><div>template &lt;&gt; void f&lt=
;int&gt;() {}</div><div>COMPILES</div><div><br></div><div><br></div><div>st=
ruct S {</div><div>=C2=A0 =C2=A0 template &lt;class X&gt; void f() {}</div>=
<div>=C2=A0 =C2=A0 template &lt;&gt; void f&lt;int&gt;() {}</div><div>};</d=
iv><div>--&gt; error: explicit specialization of &#39;f&#39; in class scope=
</div><div>FUCKING RETARDED</div><div>WOW IT REALLY MAKES SENSE THAT THIS W=
ORKS AT GLOBAL SCOPE BUT NOT IN-CLASS</div><div><br></div><div><br></div><d=
iv>struct S {</div><div>=C2=A0 =C2=A0 template &lt;class X&gt; struct Inner=
 {};</div><div>=C2=A0 =C2=A0 template &lt;&gt; struct Inner&lt;int&gt; {};<=
/div><div>};</div><div>--&gt; error: explicit specialization of &#39;Inner&=
#39; in class scope</div><div>FUCKING RETARDED</div><div><br></div><div><br=
></div><div>struct S {</div><div>=C2=A0 =C2=A0 template &lt;class X, class =
=3D void&gt; struct Inner {};</div><div>=C2=A0 =C2=A0 template &lt;class bu=
llshit&gt; struct Inner&lt;int, bullshit&gt; {};</div><div>};</div><div>WOW=
, RETARDS, WORKS WITH A STUPID-RETARDED WORKAROUND</div><div><br></div><div=
><br></div><div>struct S {</div><div>=C2=A0 =C2=A0 template &lt;class X, cl=
ass=3Dvoid&gt; void f() {}</div><div>=C2=A0 =C2=A0 template &lt;class bulls=
hit&gt; void f&lt;int, bullshit&gt;() {}</div><div>};</div><div>--&gt; func=
tion template partial specialization is not allowed</div><div>FUCKING RETAR=
DED</div><div>WOW THE RETARDED WORKAROUND DOESN&#39;T WORK FOR FUNCTIONS</d=
iv><div><br></div><div><br></div><div>template &lt;class X&gt; void f(X x) =
{}</div><div>template &lt;class X&gt; void f(X* x) {}</div><div>OH, OK THIS=
 GOOD</div><div><br></div><div><br></div><div>template &lt;class X, class Y=
&gt; void f() {}</div><div>template &lt;class Y&gt; void f&lt;int, Y&gt;() =
{}</div><div>--&gt; function template partial specialization is not allowed=
</div><div>FUCKING RETARDED.</div><div><br></div><div><br></div><div>I don&=
#39;t even want to hear 1 piece of bullshit out of a single one of you peop=
le&#39;s mouths about this one.</div><div>If you give me one piece of bulls=
hit, you&#39;re a fucking n00b.</div><div><br></div><div>Every one of these=
 things is used for metaprogramming.</div><div><br></div><div>After 15 year=
s of awareness about these problems, nothing was fixed.</div><div>And now w=
ith C++14, yet another oversight release, we&#39;re heading for 20 years of=
 fucking retardation.</div><div><br></div><div>Thank you standards body peo=
ple for your retarded level of awareness, you fucking retards.<br></div><di=
v>Can you fix the holes you fucking retards?</div><div><br></div></blockquo=
te></div><div class=3D"quoted-text">

<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></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/76e37e62-147b-4bec-8ab5-15f0051787b3%=
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/76e3=
7e62-147b-4bec-<wbr>8ab5-15f0051787b3%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></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/CAFdMc-1U6kicv6aupjDPjEXO7Pv1a25iUAnb=
vXhipPvOTPJmuA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1U6kicv6au=
pjDPjEXO7Pv1a25iUAnbvXhipPvOTPJmuA%40mail.gmail.com</a>.<br />

--001a114ac424c870e7054550b2fc--

.

------=_Part_3933_959741317.1483588041900
Content-Type: multipart/alternative;
 boundary="----=_Part_3934_889544017.1483588041900"

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

On Wednesday, January 4, 2017 at 1:41:13 PM UTC-5, m.ce...@gmail.com wrote:
>
> W dniu =C5=9Broda, 4 stycznia 2017 17:01:20 UTC+1 u=C5=BCytkownik Nicol B=
olas=20
> napisa=C5=82:
>>
>> On Wednesday, January 4, 2017 at 9:39:30 AM UTC-5, m.ce...@gmail.com=20
>> wrote:
>>>
>>> W dniu =C5=9Broda, 4 stycznia 2017 11:42:12 UTC+1 u=C5=BCytkownik Arthu=
r=20
>>> Tchaikovsky napisa=C5=82:
>>>>
>>>> >Please stop complaining about this or that, most of the people that=
=20
>>>> participates on the elaboration of the standard are doing it on their =
free=20
>>>> time.
>>>>
>>>> I simply don't understand that argument. I thought people are there no=
t=20
>>>> for the money but for the love and passion to language and they don't=
=20
>>>> expect to be paid for it?=20
>>>> So following, that people are doing it for free they mustn't be ever=
=20
>>>> criticized for it?=20
>>>> I'm sorry but you are being judged by the work you produced not by the=
=20
>>>> money you are being paid for that work. That's how real world works.
>>>>
>>>> If your work is of poor quality (and C++17 in many people's eyes is)=
=20
>>>> you (the people who are responsible, the committee) should get critici=
zed=20
>>>> and I'm glad to see that happening. Let's stop that 'patting each othe=
r on=20
>>>> the back' and saying to yourselves that yet again, you did great job. =
No=20
>>>> you didn't. You blew it.=20
>>>> As for asking:
>>>> >Who care if it was a good or a bad release, a minor or major=20
>>>> release[...]
>>>> I'm pretty certain that there are lots of people who actually care a=
=20
>>>> lot.
>>>>
>>>> This situation reminds me of a scene where engineer of certain brand=
=20
>>>> of car was arguing with the people (the regular users of that car) tha=
t=20
>>>> they shouldn't criticize the engineer for his work because they (the u=
sers)=20
>>>> are incapable of actually making even worse car than that produced by =
those=20
>>>> engineers.
>>>>
>>>> I'm sorry but it doesn't work that way. I, as a user, even though I'm=
=20
>>>> unable to have any impact (nor I'm admittedly capable of making it) on=
 a=20
>>>> car being produced, have every right to express my disappointment with=
 a=20
>>>> car. Is it poorly made? If so I have right to criticize it. And I real=
ly=20
>>>> don't care how much(or how little) those people involved in production=
 of=20
>>>> this car were paid. This (the wages) is totally different issue.
>>>> And if there are more and more voices from users that the car is of=20
>>>> poor quality, well, I think there is something on the matter. Even tho=
ugh=20
>>>> engineers think that yet again they've produced something great and pa=
t=20
>>>> each other on the back.
>>>> Same goes for films, clothes, food... If something is of poor quality=
=20
>>>> users have right to criticize it even though the people making it were=
n't=20
>>>> paid as much as they should and despite the fact that the users are=20
>>>> incapable of producing such item themselves.
>>>>
>>>
>>> While I don't disagree with this point of view, I'd rather say that the=
y=20
>>> did good job, just not what was most wished for.
>>>
>>> I think committee should really prioritize its work, esp. on features=
=20
>>> that should have been there long time ago: modules, reflection and mayb=
e=20
>>> concepts.
>>>
>> I get it, modules are really ungrateful piece of functionality to work o=
n=20
>>> (due to legacy cruft), but users craved for it for more than 10 years=
=20
>>> already.
>>> Same for reflection and concepts.
>>>
>>
>> Yeah, this is what I mean when I talk about proper judgement of the=20
>> committee's process. In that this criticism doesn't really show that.
>>
>> Modules has not been delayed because it is a "really ungrateful piece of=
=20
>> functionality to work on". People have been working on modules. *A lot=
=20
>> of people* have been working on modules. We have two in-progress=20
>> implementations *right now*. It even has its own study group.
>>
>
> It is really hard to believe that as you say given 'a lot of people'=20
> working on modules and a decade of time the reason we have no modules=20
> support in C++ standard is because 'it is hard'.
>

That's what happens when work essentially shuts down for several years.=20
Between 2012 and 2014, nothing in modules moved forward. It took Gabriel=20
Dos Reis to resuscitate the effort in 2014.

And yes, a lot of people have been working on modules. The people writing=
=20
the implementations. The Microsoft group who wrote the proposals. The Clang=
=20
group who wrote commentary on those proposals. And so forth. That's quite a=
=20
few people.

It's not hundreds, but it's not meant to be.
=20

> I'm following the isocpp forum, website, read most proposals, watch C++=
=20
> conference videos and follow Clang development mailing lists and really=
=20
> don't see that horde of people working on this feature.
> I see mainly Gabriel Dos Reis and Richard Smith - hopefully there are way=
=20
> more people working 'behind the scenes'.
> But even if there are, one just cannot excuse lack of this feature for=20
> such a long time by saying 'it is hard'. These guys are brilliant=20
> engineers, I refuse to believe they couldn't find a solution for such a=
=20
> long time.
> How come clang have modules support for years?!
>

If they did, how come they didn't start actually writing proposals until=20
Microsoft made it abundantly clear that they were going to implement=20
Gabriel Dos Reis's proposal? It wasn't until 2016 that Clang people decided=
=20
to get into the game. If Clang was sitting on a fully-formed modules=20
implementation that actually worked, then it's their responsibility to=20
stand up and actually submit it for standardization.

From my point of view, the problem is not technical. It's about management=
=20
> - resources, planning and decision making.
> Maybe 'management' part got better in recent years, but all the previous=
=20
> years are lost.
> People are just tired of hearing yet again that we won't have modules,=20
> reflection or concept in next C++ version, and that's why (at least=20
> partially) they're saying that C++17 is a let-down.
>
> Again about the priorities. I see many proposals, most of them seem to=20
> live their own lives - i.e. there doesn't seem to be any push from=20
> committee to finish them, who cares if they miss next version deadline.
> I've yet to see a document stating what is committee's overall vision on=
=20
> C++ near future.
>

That's because there is no "vision on C++". That's not how the process=20
works.

The committee doesn't even work on proposals; it votes to approve or not=20
approve proposals. People write proposals, and those proposals get=20
considered. Any "vision" therefore is merely an aggregation of "whatever=20
people propose".

Expecting a unified direction from a process that *by design* is=20
directionless is an unreasonable expectation.

Also, I don't think ISO standardization is even *allowed* to be driven in a=
=20
top-down fashion, where some group of "elites" decide that we're solving=20
problems X, Y and Z for this release, then tell others to actually solve=20
those problems. And to be honest, in most cases, it's a benefit.

The problem with "vision" is that it ignores *utility*. It presumes that=20
those with "vision" know what needs to be improved in the language and that=
=20
everything outside that vision should be secondary.

Things that C++17 got that didn't fit into Stroustrup's "vision" include=20
fold expressions, structured binding, and guaranteed elision. These are all=
=20
very good C++17 features that actual C++ programmers will use.

But a top-down design like you're talking about would likely have never=20
gotten them into the language. Similarly, C++20 is off to an interesting=20
start, with designated initializers; again, not something that someone's=20
"vision" says we need, but I very much appreciate the feature. I hope to=20
see other general purpose features in C++20 too, like product type=20
unpacking.

That's what happens when you focus so much on what we didn't get. You=20
forget to appreciate the importance of what we *did* get.

All I see is status reports on specific proposals/features. Bjarne=20
> Stroustrup is the one with the vision, but I doubt that whole committee
> actually backs it, or acts actively to make that whole vision come true.
>
> Maybe someone is able to tell us (non-committee people) what are committe=
e=20
> priorities? What do they plan to do to make C++ a language with features=
=20
> that most modern programming languages have since many years?
> Do they somehow encourage (hire?) people to work on most important=20
> features or are they just 'passively' waiting for features to be finished=
=20
> in their study groups so they can give their final approved/not-approved=
=20
> vote.
>
>

--=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/aa8e927e-a9cc-47d5-a705-ae9af02ac225%40isocpp.or=
g.

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

<div dir=3D"ltr">On Wednesday, January 4, 2017 at 1:41:13 PM UTC-5, m.ce...=
@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">W dniu =C5=9Broda, 4 stycznia 2017 17:01:20 UTC+1 u=C5=BCytkownik Nicol=
 Bolas napisa=C5=82:<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=
">On Wednesday, January 4, 2017 at 9:39:30 AM UTC-5, <a>m.ce...@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">W dniu =
=C5=9Broda, 4 stycznia 2017 11:42:12 UTC+1 u=C5=BCytkownik Arthur Tchaikovs=
ky napisa=C5=82:<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"><d=
iv>&gt;Please stop complaining about this or that, most of the people that =
   participates on the elaboration of the standard are doing it on    their=
 free time.</div><div><br></div><div>I simply don&#39;t understand that arg=
ument. I thought people are there not for the money but for the love and pa=
ssion to language and they don&#39;t expect to be paid for it? </div><div>S=
o following, that people are doing it for free they mustn&#39;t be ever cri=
ticized for it? </div><div>I&#39;m sorry but=C2=A0you are being judged by t=
he work you produced not by the money you are being paid for that work. Tha=
t&#39;s how real world works.</div><div><br></div><div>If your work is of p=
oor quality (and C++17 in many people&#39;s eyes is) you (the people who ar=
e responsible, the committee) should get criticized and I&#39;m glad to see=
 that happening. Let&#39;s stop that &#39;patting each other on the back&#3=
9; and saying to yourselves that yet again, you did great job. No you didn&=
#39;t. You blew it. </div><div>As for asking:</div><div>&gt;Who care if it =
was a good or a bad release, a minor or major    release[...]</div><div>I&#=
39;m pretty certain that there are lots of people who actually care a lot.<=
/div><div><br></div><div>This situation reminds me=C2=A0of a=C2=A0scene whe=
re engineer of certain brand of=C2=A0car was arguing with the people (the r=
egular users of that car) that they shouldn&#39;t criticize the engineer fo=
r his work because they (the users) are incapable of actually making even w=
orse car than that produced by those engineers.</div><div><br></div><div>I&=
#39;m sorry but=C2=A0it doesn&#39;t work that way. I, as a user, even thoug=
h I&#39;m unable to have any impact (nor I&#39;m admittedly capable of maki=
ng it)=C2=A0on a car being produced, have every right to express my disappo=
intment with a car. Is it poorly made? If so I have right to criticize it. =
And I really don&#39;t care how much(or how little) those people involved i=
n production of this car were paid. This (the wages)=C2=A0is totally differ=
ent issue.</div><div>And if there are more and more voices from users that =
the car is of poor quality, well, I think there is something on the matter.=
 Even though engineers think that yet again they&#39;ve produced something =
great and pat each other on the back.</div><div>Same goes for films, clothe=
s, food... If something is of poor quality users have right to criticize it=
 even though the people making it weren&#39;t paid as much as they should a=
nd despite the fact that the users are incapable of producing such item the=
mselves.</div></div></blockquote><div><br></div><div>While I don&#39;t disa=
gree with this point of view, I&#39;d rather say that they did good job, ju=
st not what was most wished for.</div><div><br></div><div>I think committee=
 should really prioritize its work, esp. on features that should have been =
there long time ago: modules, reflection and maybe concepts.</div></div></b=
lockquote><div></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"lt=
r"><div>I get it, modules are really ungrateful piece of functionality to w=
ork on (due to legacy cruft), but users craved for it for more than 10 year=
s already.</div><div>Same for reflection and concepts.</div></div></blockqu=
ote><div><br>Yeah, this is what I mean when I talk about proper judgement o=
f the committee&#39;s process. In that this criticism doesn&#39;t really sh=
ow that.<br><br>Modules has not been delayed because it is a &quot;really u=
ngrateful piece of functionality to work on&quot;. People have been working=
 on modules. <i>A lot of people</i> have been working on modules. We have t=
wo in-progress implementations <i>right now</i>. It even has its own study =
group.<br></div></div></blockquote><div><br>It is really hard to believe th=
at as you say given &#39;a lot of people&#39; working on modules and a deca=
de of time the reason we have no modules support in C++ standard is because=
 &#39;it is hard&#39;.<br></div></div></blockquote><div><br>That&#39;s what=
 happens when work essentially shuts down for several years. Between 2012 a=
nd 2014, nothing in modules moved forward. It took Gabriel Dos Reis to resu=
scitate the effort in 2014.<br><br>And yes, a lot of people have been worki=
ng on modules. The people writing the implementations. The Microsoft group =
who wrote the proposals. The Clang group who wrote commentary on those prop=
osals. And so forth. That&#39;s quite a few people.<br><br>It&#39;s not hun=
dreds, but it&#39;s not meant to be.<br>=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>I&#39;m following the isocpp fo=
rum, website, read most proposals, watch C++ conference videos and follow C=
lang development mailing lists and really don&#39;t see that horde of peopl=
e working on this feature.<br>I see mainly Gabriel Dos Reis and Richard Smi=
th - hopefully there are way more people working &#39;behind the scenes&#39=
;.<br>But even if there are, one just cannot excuse lack of this feature fo=
r such a long time by saying &#39;it is hard&#39;. These guys are brilliant=
 engineers, I refuse to believe they couldn&#39;t find a solution for such =
a long time.<br>How come clang have modules support for years?!<br></div></=
div></blockquote><div><br>If they did, how come they didn&#39;t start actua=
lly writing proposals until Microsoft made it abundantly clear that they we=
re going to implement Gabriel Dos Reis&#39;s proposal? It wasn&#39;t until =
2016 that Clang people decided to get into the game. If Clang was sitting o=
n a fully-formed modules implementation that actually worked, then it&#39;s=
 their responsibility to stand up and actually submit it for standardizatio=
n.<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"lt=
r"><div>From my point of view, the problem is not technical. It&#39;s about=
 management - resources, planning and decision making.<br>Maybe &#39;manage=
ment&#39; part got better in recent years, but all the previous years are l=
ost.<br>People are just tired of hearing yet again that we won&#39;t have m=
odules, reflection or concept in next C++ version, and that&#39;s why (at l=
east partially) they&#39;re saying that C++17 is a let-down.<br><br>Again a=
bout the priorities. I see many proposals, most of them seem to live their =
own lives - i.e. there doesn&#39;t seem to be any push from committee to fi=
nish them, who cares if they miss next version deadline.<br>I&#39;ve yet to=
 see a document stating what is committee&#39;s overall vision on C++ near =
future.</div></div></blockquote><div><br>That&#39;s because there is no &qu=
ot;vision on C++&quot;. That&#39;s not how the process works.<br><br>The co=
mmittee doesn&#39;t even work on proposals; it votes to approve or not appr=
ove proposals. People write proposals, and those proposals get considered. =
Any &quot;vision&quot; therefore is merely an aggregation of &quot;whatever=
 people propose&quot;.<br><br>Expecting a unified direction from a process =
that <i>by design</i> is directionless is an unreasonable expectation.<br><=
br>Also, I don&#39;t think ISO standardization is even <i>allowed</i> to be=
 driven in a top-down fashion, where some group of &quot;elites&quot; decid=
e that we&#39;re solving problems X, Y and Z for this release, then tell ot=
hers to actually solve those problems. And to be honest, in most cases, it&=
#39;s a benefit.<br><br>The problem with &quot;vision&quot; is that it igno=
res <i>utility</i>. It presumes that those with &quot;vision&quot; know wha=
t needs to be improved in the language and that everything outside that vis=
ion should be secondary.<br><br>Things that C++17 got that didn&#39;t fit i=
nto Stroustrup&#39;s &quot;vision&quot; include fold expressions, structure=
d binding, and guaranteed elision. These are all very good C++17 features t=
hat actual C++ programmers will use.<br><br>But a top-down design like you&=
#39;re talking about would likely have never gotten them into the language.=
 Similarly, C++20 is off to an interesting start, with designated initializ=
ers; again, not something that someone&#39;s &quot;vision&quot; says we nee=
d, but I very much appreciate the feature. I hope to see other general purp=
ose features in C++20 too, like product type unpacking.<br><br>That&#39;s w=
hat happens when you focus so much on what we didn&#39;t get. You forget to=
 appreciate the importance of what we <i>did</i> get.<br><br></div><blockqu=
ote 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> All I see is st=
atus reports on specific proposals/features. Bjarne Stroustrup is the one w=
ith the vision, but I doubt that whole committee<br>actually backs it, or a=
cts actively to make that whole vision come true.<br><br>Maybe someone is a=
ble to tell us (non-committee people) what are committee priorities? What d=
o they plan to do to make C++ a language with features that most modern pro=
gramming languages have since many years?<br>Do they somehow encourage (hir=
e?) people to work on most important features or are they just &#39;passive=
ly&#39; waiting for features to be finished in their study groups so they c=
an give their final approved/not-approved vote.</div><br></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/aa8e927e-a9cc-47d5-a705-ae9af02ac225%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/aa8e927e-a9cc-47d5-a705-ae9af02ac225=
%40isocpp.org</a>.<br />

------=_Part_3934_889544017.1483588041900--

------=_Part_3933_959741317.1483588041900--

.

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

On 4 January 2017 at 19:14, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Wednesday, January 4, 2017 at 3:49:00 PM UTC-5, Jens Maurer wrote:
>
>> On 01/04/2017 07:41 PM, m.ce...@gmail.com wrote:
>> > Maybe someone is able to tell us (non-committee people) what are
>> committee priorities? What do they plan to do to make C++ a language with
>> features that most modern programming languages have since many years?
>> > Do they somehow encourage (hire?) people to work on most important
>> features or are they just 'passively' waiting for features to be finished
>> in their study groups so they can give their final approved/not-approved
>> vote.
>>
>> The committee is set of people more or less tangentially involved with
>> C++,
>> but otherwise from very diverse backgrounds.  There are about 100 people
>> in
>> attendance for a meeting.  Is there a vision?  Not one, but several, some
>> of them possibly disjoint.
>>
>> Some people are paid to attend, others attend on their own dime.
>> All put substantially more hours into the standardization process than
>> what they're actually paid for, and everyone sets his/her own priorities.
>>
>> Sometimes, a feature is added because a company selling C++-related
>> products is compelled by their users to offer a certain feature, and
>> the company is responsible enough to actually standardize the feature
>> instead of having a vendor extension.  My unverified guess is that this
>> happened with the operator new/delete extensions allowing to specify
>> alignment.  Intel certainly has an interest to make their SIMD stuff
>> work, and it's kind of a roadblock not to be able to allocate suitably
>> aligned memory in the first place.
>>
>> Sometimes, a feature is added because an individual (possibly triggered
>> by her daily work) saw a need for a feature and decided to invest
>> enough time to see it through.  This is what happened with
>> to_chars() / from_chars().
>>
>> Sometimes, a feature is discussed and progressed, but a substantial part
>> of the committee has sustained reservations against the shape of the
>> feature, thus failing to achieve consensus.  This happened with defaulted
>> comparison operators (until now) and unified call syntax.
>>
>
> I think these are probably my biggest concerns, in terms of
> standardization. Particularly for UCS.
>
> I say that because, while the "sustained reservation" people may have a
> point, that point cannot change the fact that *we need UCS*. One form,
> the other, or both. But this is functionality that we as C++ users
> absolutely need.
>

The people with sustained reservations obviously disagree, or at least
think the harm this feature does to the language outweighs the benefit. And
the current levels of adoption of the standard clearly demonstrate that we
do not *need* this feature, or indeed any feature. It has merit, sure, but
that must be weighed against other things.

Every time you have to do `using std::swap` before `swap`ing some object,
> you're doing something that UCS ought to handle. The same goes for global
> `begin`, `end`, `size`, etc. This is a growing problem, one with Ranges TS
> is only going to exacerbate. And "sustained reservations" don't actually
> fix problems.
>

The counterargument to that is that using unqualified names as extension
points is a major mistake that significantly harms the benefits that
namespaces are supposed to provide. ADL for non-operators is harmful to the
language, and UCS makes that harm significantly worse by applying it in
more cases.

The full UCS proposal also makes lots of previously-safe routine library
maintenance (such as adding member functions) a potential source-breaking
change for API consumers (which might previously have been calling their
own declarations of non-members via member syntax). The half-UCS approach
at least only affects the cases that are already maligned by ADL, but it
still has this characteristic that extending a library in natural ways
becomes a potentially breaking change for API consumers. We do not need
more features in C++ that make it hard to maintain large-scale codebases.

What we really *should* add is a language feature that provides support for
sane, principled, named, scoped extension points. UCS isn't that.

This is where I think it would be good to be able to separate technical
> reservations (ie: the feature is broken and/or doesn't work to achieve its
> stated goal) from other reservations. And that if a feature is going to
> solve a problem that the language really needs to solve, then I believe
> that non-technical reservations should not be counted as strongly as
> technical reservations.
>

I have not heard any non-technical reservations be brought up as
counterarguments to the UCS proposal.

Now, that's not to say that the concerns about UCS were all non-technical.
> There were good technical reasons to ditch member-to-global transformation
> (though I really wish someone had taken the time to work around them). But
> looking at the minutes from Jacksonville, the arguments against it don't
> seem to be technical so much as *fear*.
>
> And where was all that fear when list-initialization's rules were being
> put together ;)
>
> Essentially, the committee doesn't focus so much on problems as proposals.
> Motivations are important only in measuring whether a proposal achieves
> something worthwhile; the idea that a proposal could be "too important to
> fail" (or at least "too important to fail for any reason other than serious
> technical flaws") is not dealt with. And that isn't good.
>

Problems can be important to solve, but I find the suggestion that a
particular /approach/ to a problem could be "too important to fail" to be
very odd. If some fatal flaw is found, or a better proposal is presented,
any proposal can, and should, be able to be discarded. (I don't think that
counts as "failure" if it helps progress the language, though.)


> Regarding modules in particular, the #include model has shown its age
>> since 25+ years, but nobody actually (dared to?) attack the problem
>> in the sense of trying an implementation and writing a paper until fairly
>> recently.  I'm sure we'd have modules since 5 years or so if someone
>> had started working on them in earnest 10-15 years ago.
>>
>
> I think this really needs to be emphasized.
>
> Back in 2007, modules was being talked about. But there wasn't really an
> implementation of it anywhere. Not even as a proof-of-concept. Even C++11's
> insane concept stuff had a proof-of-concept implementation. But modules
> didn't seem to be moving towards an implementation.
>
> What makes me feel like modules is really going to happen is not the fact
> that there's a proposal. It was when Microsoft basically said, "hey, we're
> implementing this. Right now. Our compiler's next version will have a
> first-pass implementation of it."
>

Well, Clang had had an implementation of a modules feature for several
years before this, and the lead Clang maintainer at the time was chairing
the Modules SG within the C++ committee. But you're right, what we didn't
have was a complete proposal and a matching implementation to focus that
discussion, and that has been *hugely* valuable in pushing that feature
forwards. (That said, I did throw away a design paper for modules that I'd
been working on when MS' proposal arrived, so we would likely have made
progress regardless.)

For highly complex proposals like modules, implementations are absolutely
> key for getting them moving forward. And this is a good thing. It makes
> sure that complicated proposals can't just create things out of whole cloth
> without proving that they work.
>
> This is also unfortunately the reason why P0057 is moving forward (though
> in a TS), while any alternatives are at present just ink on a page. Because
> someone is actually implementing P0057, while nobody even has design
> agreement on an alternative, let alone a genuine implementation. Outside of
> P0099 of course, but that's a pure-library thing.
>
> --
> 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/f9259329-7e00-4838-
> a365-e22cd2ea6879%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f9259329-7e00-4838-a365-e22cd2ea6879%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/CAOfiQqmbBF7%2BeX_oS6W5XMvG7epUvrVEqp8aG4toE%3DRwS-n-9A%40mail.gmail.com.

--001a1146fba28fd547054550e107
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 4=
 January 2017 at 19:14, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto=
:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr=
">On Wednesday, January 4, 2017 at 3:49:00 PM UTC-5, Jens Maurer wrote:<div=
><div class=3D"gmail-h5"><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
On 01/04/2017 07:41 PM, <a rel=3D"nofollow">m.ce...@gmail.com</a> wrote:
<br>&gt; Maybe someone is able to tell us (non-committee people) what are c=
ommittee priorities? What do they plan to do to make C++ a language with fe=
atures that most modern programming languages have since many years?
<br>&gt; Do they somehow encourage (hire?) people to work on most important=
 features or are they just &#39;passively&#39; waiting for features to be f=
inished in their study groups so they can give their final approved/not-app=
roved vote.
<br>
<br>The committee is set of people more or less tangentially involved with =
C++,
<br>but otherwise from very diverse backgrounds.=C2=A0 There are about 100 =
people in
<br>attendance for a meeting.=C2=A0 Is there a vision?=C2=A0 Not one, but s=
everal, some
<br>of them possibly disjoint.
<br>
<br>Some people are paid to attend, others attend on their own dime.
<br>All put substantially more hours into the standardization process than
<br>what they&#39;re actually paid for, and everyone sets his/her own prior=
ities.
<br>
<br>Sometimes, a feature is added because a company selling C++-related
<br>products is compelled by their users to offer a certain feature, and
<br>the company is responsible enough to actually standardize the feature
<br>instead of having a vendor extension.=C2=A0 My unverified guess is that=
 this
<br>happened with the operator new/delete extensions allowing to specify
<br>alignment.=C2=A0 Intel certainly has an interest to make their SIMD stu=
ff
<br>work, and it&#39;s kind of a roadblock not to be able to allocate suita=
bly
<br>aligned memory in the first place.
<br>
<br>Sometimes, a feature is added because an individual (possibly triggered
<br>by her daily work) saw a need for a feature and decided to invest
<br>enough time to see it through.=C2=A0 This is what happened with
<br>to_chars() / from_chars().
<br>
<br>Sometimes, a feature is discussed and progressed, but a substantial par=
t
<br>of the committee has sustained reservations against the shape of the
<br>feature, thus failing to achieve consensus.=C2=A0 This happened with de=
faulted
<br>comparison operators (until now) and unified call syntax.<br></blockquo=
te></div></div><div><br>I think these are probably my biggest concerns, in =
terms of standardization. Particularly for UCS.<br><br>I say that because, =
while the &quot;sustained reservation&quot; people may have a point, that p=
oint cannot change the fact that <i>we need UCS</i>. One form, the other, o=
r both. But this is functionality that we as C++ users absolutely need.<br>=
</div></div></blockquote><div><br></div><div>The people with sustained rese=
rvations obviously disagree, or at least think the harm this feature does t=
o the language outweighs the benefit. And the current levels of adoption of=
 the standard clearly demonstrate that we do not *need* this feature, or in=
deed any feature. It has merit, sure, but that must be weighed against othe=
r things.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex"><div dir=3D"ltr"><div>Every time you have to do `using std::swap` befo=
re `swap`ing some object, you&#39;re doing something that UCS ought to hand=
le. The same goes for global `begin`, `end`, `size`, etc. This is a growing=
 problem, one with Ranges TS is only going to exacerbate. And &quot;sustain=
ed reservations&quot; don&#39;t actually fix problems.<br></div></div></blo=
ckquote><div><br></div><div>The counterargument to that is that using unqua=
lified names as extension points is a major mistake that significantly harm=
s the benefits that namespaces are supposed to provide. ADL for non-operato=
rs is harmful to the language, and UCS makes that harm significantly worse =
by applying it in more cases.</div><div><br></div><div>The full UCS proposa=
l also makes lots of previously-safe routine library maintenance (such as a=
dding member functions) a potential source-breaking change for API consumer=
s (which might previously have been calling their own declarations of non-m=
embers via member syntax). The half-UCS approach at least only affects the =
cases that are already maligned by ADL, but it still has this characteristi=
c that extending a library in natural ways becomes a potentially breaking c=
hange for API consumers. We do not need more features in C++ that make it h=
ard to maintain large-scale codebases.</div><div><br></div><div>What we rea=
lly *should* add is a language feature that provides support for sane, prin=
cipled, named, scoped extension points. UCS isn&#39;t that.</div><div><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><di=
v>This is where I think it would be good to be able to separate technical r=
eservations (ie: the feature is broken and/or doesn&#39;t work to achieve i=
ts stated goal) from other reservations. And that if a feature is going to =
solve a problem that the language really needs to solve, then I believe tha=
t non-technical reservations should not be counted as strongly as technical=
 reservations.<br></div></div></blockquote><div><br></div><div>I have not h=
eard any non-technical reservations be brought up as counterarguments to th=
e UCS proposal.</div><div><br></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>Now, that&#39;s not to say that the concer=
ns about UCS were all non-technical. There were good technical reasons to d=
itch member-to-global transformation (though I really wish someone had take=
n the time to work around them). But looking at the minutes from Jacksonvil=
le, the arguments against it don&#39;t seem to be technical so much as <i>f=
ear</i>.<br><br>And where was all that fear when list-initialization&#39;s =
rules were being put together ;)<br><br>Essentially, the committee doesn&#3=
9;t focus so much on problems as proposals. Motivations are important only =
in measuring whether a proposal achieves something worthwhile; the idea tha=
t a proposal could be &quot;too important to fail&quot; (or at least &quot;=
too important to fail for any reason other than serious technical flaws&quo=
t;) is not dealt with. And that isn&#39;t good.<br></div></div></blockquote=
><div><br></div><div>Problems can be important to solve, but I find the sug=
gestion that a particular /approach/ to a problem could be &quot;too import=
ant to fail&quot; to be very odd. If some fatal flaw is found, or a better =
proposal is presented, any proposal can, and should, be able to be discarde=
d. (I don&#39;t think that counts as &quot;failure&quot; if it helps progre=
ss the language, though.)</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><span class=3D"gmail-"><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">
Regarding modules in particular, the #include model has shown its age
<br>since 25+ years, but nobody actually (dared to?) attack the problem
<br>in the sense of trying an implementation and writing a paper until fair=
ly
<br>recently.=C2=A0 I&#39;m sure we&#39;d have modules since 5 years or so =
if someone
<br>had started working on them in earnest 10-15 years ago.<br></blockquote=
></span><div><br>I think this really needs to be emphasized.<br><br>Back in=
 2007, modules was being talked about. But there wasn&#39;t really an imple=
mentation of it anywhere. Not even as a proof-of-concept. Even C++11&#39;s =
insane concept stuff had a proof-of-concept implementation. But modules did=
n&#39;t seem to be moving towards an implementation.<br><br>What makes me f=
eel like modules is really going to happen is not the fact that there&#39;s=
 a proposal. It was when Microsoft basically said, &quot;hey, we&#39;re imp=
lementing this. Right now. Our compiler&#39;s next version will have a firs=
t-pass implementation of it.&quot;<br></div></div></blockquote><div><br></d=
iv><div>Well, Clang had had an implementation of a modules feature for seve=
ral years before this, and the lead Clang maintainer at the time was chairi=
ng the Modules SG within the C++ committee. But you&#39;re right, what we d=
idn&#39;t have was a complete proposal and a matching implementation to foc=
us that discussion, and that has been *hugely* valuable in pushing that fea=
ture forwards. (That said, I did throw away a design paper for modules that=
 I&#39;d been working on when MS&#39; proposal arrived, so we would likely =
have made progress regardless.)</div><div><br></div><blockquote class=3D"gm=
ail_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>For highly complex proposa=
ls like modules, implementations are absolutely key for getting them moving=
 forward. And this is a good thing. It makes sure that complicated proposal=
s can&#39;t just create things out of whole cloth without proving that they=
 work.<br><br>This is also unfortunately the reason why P0057 is moving for=
ward (though in a TS), while any alternatives are at present just ink on a =
page. Because someone is actually implementing P0057, while nobody even has=
 design agreement on an alternative, let alone a genuine implementation. Ou=
tside of P0099 of course, but that&#39;s a pure-library thing.<br></div></d=
iv><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/f9259329-7e00-4838-a365-e22cd2ea6879%=
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/f925=
9329-7e00-4838-<wbr>a365-e22cd2ea6879%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></div>

<p></p>

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

--001a1146fba28fd547054550e107--

.

This is a multi-part message in MIME format.
--------------783EF4D430E187C2E8C3E1CD
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 05/01/2017 =C3=A0 04:55, Richard Smith a =C3=A9crit :
> On 4 January 2017 at 19:14, Nicol Bolas <jmckesson@gmail.com=20
> <mailto:jmckesson@gmail.com>> wrote:
>
>     On Wednesday, January 4, 2017 at 3:49:00 PM UTC-5, Jens Maurer wrote:
>
>         On 01/04/2017 07:41 PM, m.ce...@gmail.com wrote:
>         > Maybe someone is able to tell us (non-committee people) what
>         are committee priorities? What do they plan to do to make C++
>         a language with features that most modern programming
>         languages have since many years?
>         > Do they somehow encourage (hire?) people to work on most
>         important features or are they just 'passively' waiting for
>         features to be finished in their study groups so they can give
>         their final approved/not-approved vote.
>
>         The committee is set of people more or less tangentially
>         involved with C++,
>         but otherwise from very diverse backgrounds. There are about
>         100 people in
>         attendance for a meeting.  Is there a vision?  Not one, but
>         several, some
>         of them possibly disjoint.
>
>         Some people are paid to attend, others attend on their own dime.
>         All put substantially more hours into the standardization
>         process than
>         what they're actually paid for, and everyone sets his/her own
>         priorities.
>
>         Sometimes, a feature is added because a company selling
>         C++-related
>         products is compelled by their users to offer a certain
>         feature, and
>         the company is responsible enough to actually standardize the
>         feature
>         instead of having a vendor extension.  My unverified guess is
>         that this
>         happened with the operator new/delete extensions allowing to
>         specify
>         alignment.  Intel certainly has an interest to make their SIMD
>         stuff
>         work, and it's kind of a roadblock not to be able to allocate
>         suitably
>         aligned memory in the first place.
>
>         Sometimes, a feature is added because an individual (possibly
>         triggered
>         by her daily work) saw a need for a feature and decided to invest
>         enough time to see it through.  This is what happened with
>         to_chars() / from_chars().
>
>         Sometimes, a feature is discussed and progressed, but a
>         substantial part
>         of the committee has sustained reservations against the shape
>         of the
>         feature, thus failing to achieve consensus.  This happened
>         with defaulted
>         comparison operators (until now) and unified call syntax.
>
>
>     I think these are probably my biggest concerns, in terms of
>     standardization. Particularly for UCS.
>
>     I say that because, while the "sustained reservation" people may
>     have a point, that point cannot change the fact that /we need
>     UCS/. One form, the other, or both. But this is functionality that
>     we as C++ users absolutely need.
>
>
> The people with sustained reservations obviously disagree, or at least=20
> think the harm this feature does to the language outweighs the=20
> benefit. And the current levels of adoption of the standard clearly=20
> demonstrate that we do not *need* this feature, or indeed any feature.=20
> It has merit, sure, but that must be weighed against other things.
+1
>
>     Every time you have to do `using std::swap` before `swap`ing some
>     object, you're doing something that UCS ought to handle. The same
>     goes for global `begin`, `end`, `size`, etc. This is a growing
>     problem, one with Ranges TS is only going to exacerbate. And
>     "sustained reservations" don't actually fix problems.
>
>
> The counterargument to that is that using unqualified names as=20
> extension points is a major mistake that significantly harms the=20
> benefits that namespaces are supposed to provide. ADL for=20
> non-operators is harmful to the language,
+1
> and UCS makes that harm significantly worse by applying it in more cases.
>
> The full UCS proposal also makes lots of previously-safe routine=20
> library maintenance (such as adding member functions) a potential=20
> source-breaking change for API consumers (which might previously have=20
> been calling their own declarations of non-members via member syntax).=20
> The half-UCS approach at least only affects the cases that are already=20
> maligned by ADL, but it still has this characteristic that extending a=20
> library in natural ways becomes a potentially breaking change for API=20
> consumers. We do not need more features in C++ that make it hard to=20
> maintain large-scale codebases.
>
> What we really *should* add is a language feature that provides=20
> support for sane, principled, named, scoped extension points.
+1
> UCS isn't that.
>
Vicente

--=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/536f3a15-be66-7dfb-55cb-013676018c05%40wanadoo.f=
r.

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 05/01/2017 =C3=A0 04:55, Richard Smit=
h a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
cite=3D"mid:CAOfiQqmbBF7+eX_oS6W5XMvG7epUvrVEqp8aG4toE=3DRwS-n-9A@mail.gmai=
l.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">On 4 January 2017 at 19:14, Nicol
            Bolas <span dir=3D"ltr">&lt;<a moz-do-not-send=3D"true"
                href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmcke=
sson@gmail.com</a>&gt;</span>
            wrote:<br>
            <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">On Wednesday, January 4, 2017 at 3:49:00 PM
                UTC-5, Jens Maurer wrote:
                <div>
                  <div class=3D"gmail-h5">
                    <blockquote class=3D"gmail_quote" style=3D"margin:0px
                      0px 0px 0.8ex;border-left:1px solid
                      rgb(204,204,204);padding-left:1ex">On 01/04/2017
                      07:41 PM, <a moz-do-not-send=3D"true"
                        rel=3D"nofollow">m.ce...@gmail.com</a> wrote:
                      <br>
                      &gt; Maybe someone is able to tell us
                      (non-committee people) what are committee
                      priorities? What do they plan to do to make C++ a
                      language with features that most modern
                      programming languages have since many years?
                      <br>
                      &gt; Do they somehow encourage (hire?) people to
                      work on most important features or are they just
                      'passively' waiting for features to be finished in
                      their study groups so they can give their final
                      approved/not-approved vote.
                      <br>
                      <br>
                      The committee is set of people more or less
                      tangentially involved with C++,
                      <br>
                      but otherwise from very diverse backgrounds.=C2=A0
                      There are about 100 people in
                      <br>
                      attendance for a meeting.=C2=A0 Is there a vision?=C2=
=A0 Not
                      one, but several, some
                      <br>
                      of them possibly disjoint.
                      <br>
                      <br>
                      Some people are paid to attend, others attend on
                      their own dime.
                      <br>
                      All put substantially more hours into the
                      standardization process than
                      <br>
                      what they're actually paid for, and everyone sets
                      his/her own priorities.
                      <br>
                      <br>
                      Sometimes, a feature is added because a company
                      selling C++-related
                      <br>
                      products is compelled by their users to offer a
                      certain feature, and
                      <br>
                      the company is responsible enough to actually
                      standardize the feature
                      <br>
                      instead of having a vendor extension.=C2=A0 My
                      unverified guess is that this
                      <br>
                      happened with the operator new/delete extensions
                      allowing to specify
                      <br>
                      alignment.=C2=A0 Intel certainly has an interest to
                      make their SIMD stuff
                      <br>
                      work, and it's kind of a roadblock not to be able
                      to allocate suitably
                      <br>
                      aligned memory in the first place.
                      <br>
                      <br>
                      Sometimes, a feature is added because an
                      individual (possibly triggered
                      <br>
                      by her daily work) saw a need for a feature and
                      decided to invest
                      <br>
                      enough time to see it through.=C2=A0 This is what
                      happened with
                      <br>
                      to_chars() / from_chars().
                      <br>
                      <br>
                      Sometimes, a feature is discussed and progressed,
                      but a substantial part
                      <br>
                      of the committee has sustained reservations
                      against the shape of the
                      <br>
                      feature, thus failing to achieve consensus.=C2=A0 Thi=
s
                      happened with defaulted
                      <br>
                      comparison operators (until now) and unified call
                      syntax.<br>
                    </blockquote>
                  </div>
                </div>
                <div><br>
                  I think these are probably my biggest concerns, in
                  terms of standardization. Particularly for UCS.<br>
                  <br>
                  I say that because, while the "sustained reservation"
                  people may have a point, that point cannot change the
                  fact that <i>we need UCS</i>. One form, the other, or
                  both. But this is functionality that we as C++ users
                  absolutely need.<br>
                </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>The people with sustained reservations obviously
              disagree, or at least think the harm this feature does to
              the language outweighs the benefit. And the current levels
              of adoption of the standard clearly demonstrate that we do
              not *need* this feature, or indeed any feature. It has
              merit, sure, but that must be weighed against other
              things.</div>
          </div>
        </div>
      </div>
    </blockquote>
    +1<br>
    <blockquote
cite=3D"mid:CAOfiQqmbBF7+eX_oS6W5XMvG7epUvrVEqp8aG4toE=3DRwS-n-9A@mail.gmai=
l.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <div><br>
            </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>Every time you have to do `using std::swap` before
                  `swap`ing some object, you're doing something that UCS
                  ought to handle. The same goes for global `begin`,
                  `end`, `size`, etc. This is a growing problem, one
                  with Ranges TS is only going to exacerbate. And
                  "sustained reservations" don't actually fix problems.<br>
                </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>The counterargument to that is that using unqualified
              names as extension points is a major mistake that
              significantly harms the benefits that namespaces are
              supposed to provide. ADL for non-operators is harmful to
              the language, </div>
          </div>
        </div>
      </div>
    </blockquote>
    +1<br>
    <blockquote
cite=3D"mid:CAOfiQqmbBF7+eX_oS6W5XMvG7epUvrVEqp8aG4toE=3DRwS-n-9A@mail.gmai=
l.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <div>and UCS makes that harm significantly worse by applying
              it in more cases.</div>
            <div><br>
            </div>
            <div>The full UCS proposal also makes lots of
              previously-safe routine library maintenance (such as
              adding member functions) a potential source-breaking
              change for API consumers (which might previously have been
              calling their own declarations of non-members via member
              syntax). The half-UCS approach at least only affects the
              cases that are already maligned by ADL, but it still has
              this characteristic that extending a library in natural
              ways becomes a potentially breaking change for API
              consumers. We do not need more features in C++ that make
              it hard to maintain large-scale codebases.</div>
            <div><br>
            </div>
            <div>What we really *should* add is a language feature that
              provides support for sane, principled, named, scoped
              extension points. </div>
          </div>
        </div>
      </div>
    </blockquote>
    +1
    <blockquote
cite=3D"mid:CAOfiQqmbBF7+eX_oS6W5XMvG7epUvrVEqp8aG4toE=3DRwS-n-9A@mail.gmai=
l.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <div>UCS isn't that.</div>
            <div><br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    Vicente<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/536f3a15-be66-7dfb-55cb-013676018c05%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/536f3a15-be66-7dfb-55cb-013676018c05=
%40wanadoo.fr</a>.<br />

--------------783EF4D430E187C2E8C3E1CD--

.

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

2017-01-05 0:49 GMT+01:00 Fabio Fracassi <f.fracassi@gmx.net>:

> Especially in complex and where controversial approaches are proposed
> (like e.g. coroutines) it is almost impossible to assess the merits if the
> authors are not there to defend the paper.
>

.... and this emphases my previous statement - without support by your
employer you are forced to sponsor the travels by yourself
IMHO this is suboptimal

--
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%2Bwfc18NHGfApmqbAmdmkyjOHcOHMV1AQg4-esmg%2Ba9VBhR_%3DQ%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
2017-01-05 0:49 GMT+01:00 Fabio Fracassi <span dir=3D"ltr">&lt;<a target=3D=
"_blank" href=3D"mailto:f.fracassi@gmx.net">f.fracassi@gmx.net</a>&gt;</spa=
n>:<br><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF">Especially in complex and where controversial ap=
proaches are
    proposed (like e.g. coroutines) it is almost impossible to assess
    the merits if the authors are not there to defend the paper.<br></div><=
/blockquote></div><br></div><div class=3D"gmail_extra">... and this emphase=
s my previous statement - without support by your employer you are forced t=
o sponsor the travels by yourself<br></div><div class=3D"gmail_extra">IMHO =
this is suboptimal <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/CA%2Bwfc18NHGfApmqbAmdmkyjOHcOHMV1AQg=
4-esmg%2Ba9VBhR_%3DQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc18N=
HGfApmqbAmdmkyjOHcOHMV1AQg4-esmg%2Ba9VBhR_%3DQ%40mail.gmail.com</a>.<br />

--94eb2c0327204cd9d40545538bf5--

.

On 5 January 2017 at 09:06, Oliver Kowalke <oliver.kowalke@gmail.com> wrote:
>
> 2017-01-05 0:49 GMT+01:00 Fabio Fracassi <f.fracassi@gmx.net>:
>>
>> Especially in complex and where controversial approaches are proposed
>> (like e.g. coroutines) it is almost impossible to assess the merits if the
>> authors are not there to defend the paper.
>
>
> ... and this emphases my previous statement - without support by your
> employer you are forced to sponsor the travels by yourself
> IMHO this is suboptimal


See https://isocpp.org/about/financial-assistance-policy

I wouldn't expect it to be all that hard to gain support for a
stackful library coroutine proposal author to get
travel assistance, if your employer allows an absence from work.

--
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/CAFk2RUaOXf1qgHPOQzqaAX_zCHx1j9DK4R-tHeLqYD%2BbvNh9iQ%40mail.gmail.com.

.

------=_Part_5138_1690703580.1483600626008
Content-Type: multipart/alternative;
 boundary="----=_Part_5139_1302437911.1483600626009"

------=_Part_5139_1302437911.1483600626009
Content-Type: text/plain; charset=UTF-8


Shouldn't isocpp.org consider sponsoring trips to important meetings for
individuals of significant proposals where the author cannot attend
otherwise and can demonstrate in good faith that such assistance to attend
is essential.

On Thursday, January 5, 2017 at 8:06:47 PM UTC+13, Oliver Kowalke wrote:

>
> 2017-01-05 0:49 GMT+01:00 Fabio Fracassi <f.fra...@gmx.net <javascript:>>:
>
>> Especially in complex and where controversial approaches are proposed
>> (like e.g. coroutines) it is almost impossible to assess the merits if the
>> authors are not there to defend the paper.
>>
>
> ... and this emphases my previous statement - without support by your
> employer you are forced to sponsor the travels by yourself
> IMHO this is suboptimal
>

--
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/90d6f7fe-d5c1-4ebb-af0a-3044e38deddf%40isocpp.org.

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

<div dir=3D"ltr"><div><br></div><div>Shouldn&#39;t=C2=A0isocpp.org=C2=A0con=
sider sponsoring=C2=A0trips to important meetings for individuals=C2=A0of s=
ignificant proposals where the author cannot attend otherwise and can=C2=A0=
demonstrate in good faith that=C2=A0such assistance=C2=A0to attend is essen=
tial.<br><br>On Thursday, January 5, 2017 at 8:06:47 PM UTC+13, Oliver Kowa=
lke wrote:</div><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-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><br><div=
 class=3D"gmail_quote">2017-01-05 0:49 GMT+01:00 Fabio Fracassi <span dir=
=3D"ltr">&lt;<a onmousedown=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;" href=3D"java=
script:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"tdlmxx=
n3CwAJ">f.fra...@gmx.net</a>&gt;</span>:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color=
: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF">Especially in complex and where controversial ap=
proaches are
    proposed (like e.g. coroutines) it is almost impossible to assess
    the merits if the authors are not there to defend the paper.<br></div><=
/blockquote></div><br></div><div>... and this emphases my previous statemen=
t - without support by your employer you are forced to sponsor the travels =
by yourself<br></div><div>IMHO this is suboptimal <br></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/90d6f7fe-d5c1-4ebb-af0a-3044e38deddf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/90d6f7fe-d5c1-4ebb-af0a-3044e38deddf=
%40isocpp.org</a>.<br />

------=_Part_5139_1302437911.1483600626009--

------=_Part_5138_1690703580.1483600626008--

.

------=_Part_3234_41361386.1483600707239
Content-Type: multipart/alternative;
 boundary="----=_Part_3235_1128133908.1483600707239"

------=_Part_3235_1128133908.1483600707239
Content-Type: text/plain; charset=UTF-8

You answered my question just as I posted. Thanks. That's a good result.

On Thursday, January 5, 2017 at 8:13:28 PM UTC+13, Ville Voutilainen wrote:
>
> On 5 January 2017 at 09:06, Oliver Kowalke <oliver....@gmail.com
> <javascript:>> wrote:
> >
> > 2017-01-05 0:49 GMT+01:00 Fabio Fracassi <f.fra...@gmx.net <javascript:>>:
>
> >>
> >> Especially in complex and where controversial approaches are proposed
> >> (like e.g. coroutines) it is almost impossible to assess the merits if
> the
> >> authors are not there to defend the paper.
> >
> >
> > ... and this emphases my previous statement - without support by your
> > employer you are forced to sponsor the travels by yourself
> > IMHO this is suboptimal
>
>
> See https://isocpp.org/about/financial-assistance-policy
>
> I wouldn't expect it to be all that hard to gain support for a
> stackful library coroutine proposal author to get
> travel assistance, if your employer allows an absence from work.
>

--
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/c9baaa77-a01c-4056-9642-ed97ac4fac7f%40isocpp.org.

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

<div dir=3D"ltr">You=C2=A0answered my question just as I posted. Thanks. Th=
at&#39;s a good result.<br><br>On Thursday, January 5, 2017 at 8:13:28 PM U=
TC+13, Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 20=
4, 204); border-left-width: 1px; border-left-style: solid;">On 5 January 20=
17 at 09:06, Oliver Kowalke &lt;<a onmousedown=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return =
true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscat=
ed-mailto=3D"MOcjXXf3CwAJ">oliver....@gmail.com</a>&gt; wrote:
<br>&gt;
<br>&gt; 2017-01-05 0:49 GMT+01:00 Fabio Fracassi &lt;<a onmousedown=3D"thi=
s.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;ja=
vascript:&#39;;return true;" href=3D"javascript:" target=3D"_blank" rel=3D"=
nofollow" gdf-obfuscated-mailto=3D"MOcjXXf3CwAJ">f.fra...@gmx.net</a>&gt;:
<br>&gt;&gt;
<br>&gt;&gt; Especially in complex and where controversial approaches are p=
roposed
<br>&gt;&gt; (like e.g. coroutines) it is almost impossible to assess the m=
erits if the
<br>&gt;&gt; authors are not there to defend the paper.
<br>&gt;
<br>&gt;
<br>&gt; ... and this emphases my previous statement - without support by y=
our
<br>&gt; employer you are forced to sponsor the travels by yourself
<br>&gt; IMHO this is suboptimal
<br>
<br>
<br>See <a onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\x3d=
https%3A%2F%2Fisocpp.org%2Fabout%2Ffinancial-assistance-policy\x26sa\x3dD\x=
26sntz\x3d1\x26usg\x3dAFQjCNHyGIhD54X0TtHyZx3BDHg_1zKI6A&#39;;return true;"=
 onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2F=
isocpp.org%2Fabout%2Ffinancial-assistance-policy\x26sa\x3dD\x26sntz\x3d1\x2=
6usg\x3dAFQjCNHyGIhD54X0TtHyZx3BDHg_1zKI6A&#39;;return true;" href=3D"https=
://isocpp.org/about/financial-assistance-policy" target=3D"_blank" rel=3D"n=
ofollow">https://isocpp.org/about/<wbr>financial-assistance-policy</a>
<br>
<br>I wouldn&#39;t expect it to be all that hard to gain support for a
<br>stackful library coroutine proposal author to get
<br>travel assistance, if your employer allows an absence from work.
<br></blockquote></div>

<p></p>

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

------=_Part_3235_1128133908.1483600707239--

------=_Part_3234_41361386.1483600707239--

.

You might also consider a low-cost option - support participating by
video, e.g. via Skype.
If that is restricted to presenting and answering questions about a
minor proposal, it should be something you can live with.

/Peter

On Thu, Jan 5, 2017 at 8:18 AM,  <gmisocpp@gmail.com> wrote:
> You answered my question just as I posted. Thanks. That's a good result.
>
> On Thursday, January 5, 2017 at 8:13:28 PM UTC+13, Ville Voutilainen wrote:
>>
>> On 5 January 2017 at 09:06, Oliver Kowalke <oliver....@gmail.com> wrote:
>> >
>> > ... and this emphases my previous statement - without support by your
>> > employer you are forced to sponsor the travels by yourself
>> > IMHO this is suboptimal
>>
>>
>> See https://isocpp.org/about/financial-assistance-policy
>>
>> I wouldn't expect it to be all that hard to gain support for a
>> stackful library coroutine proposal author to get
>> travel assistance, if your employer allows an absence from work.
>

--
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/CANPtkny8LVgkgvri_Xyi_SjLjsU6zSh6ZOOTF-RzcPjjp-_2vA%40mail.gmail.com.

.

On 1/5/17 6:01 AM, Peter Koch Larsen wrote:
> You might also consider a low-cost option - support participating by
> video, e.g. via Skype.
> If that is restricted to presenting and answering questions about a
> minor proposal, it should be something you can live with.
>

FYI - I participated in an SG-6 meeting via skype to promote my proposal
on a safe integer library.

I found this to be pretty practical and I think the committee should
consider encouraging this practice.

Robert Ramey


--
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/28dd4f51-99e2-4b0e-228f-ce6f4d6e73fc%40rrsd.com.

.

Em quinta-feira, 5 de janeiro de 2017, =C3=A0s 00:43:01 PST, dgutson . escr=
eveu:
> No, because nobody cared to write a proposal for this. Committee is
> proposals-powered. Proposals are real_needs-powered. It seems you're the
> only guy that cares about them.
> If you do enough, write the proposals as any non retarded would do. Why t=
o
> expect others to work for your itch?

Daniel

Don't bother answering the OP. If he can't take the time to write an educat=
ed=20
and non-insulting email, we shouldn't take the time to read it.

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

--=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/1641623.gYaY76q4qI%40tjmaciei-mobl1.

.

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

On Wed, Jan 4, 2017 at 7:55 PM, Richard Smith <richard@metafoo.co.uk> wrote=
:

> On 4 January 2017 at 19:14, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>> On Wednesday, January 4, 2017 at 3:49:00 PM UTC-5, Jens Maurer wrote:
>>
>>>
>>> Sometimes, a feature is discussed and progressed, but a substantial par=
t
>>> of the committee has sustained reservations against the shape of the
>>> feature, thus failing to achieve consensus.  This happened with
>>> defaulted
>>> comparison operators (until now) and unified call syntax.
>>>
>>
>> I think these are probably my biggest concerns, in terms of
>> standardization. Particularly for UCS.
>>
>> I say that because, while the "sustained reservation" people may have a
>> point, that point cannot change the fact that *we need UCS*. One form,
>> the other, or both. But this is functionality that we as C++ users
>> absolutely need.
>>
>
> The people with sustained reservations obviously disagree, or at least
> think the harm this feature does to the language outweighs the benefit. A=
nd
> the current levels of adoption of the standard clearly demonstrate that w=
e
> do not *need* this feature, or indeed any feature. It has merit, sure, bu=
t
> that must be weighed against other things.
>
> Every time you have to do `using std::swap` before `swap`ing some object,
>> [...]
>>
>
> The counterargument to that is that using unqualified names as extension
> points is a major mistake that significantly harms the benefits that
> namespaces are supposed to provide. ADL for non-operators is harmful to t=
he
> language, and UCS makes that harm significantly worse by applying it in
> more cases.
>
> The full UCS proposal also makes lots of previously-safe routine library
> maintenance (such as adding member functions) a potential source-breaking
> change for API consumers (which might previously have been calling their
> own declarations of non-members via member syntax). The half-UCS approach
> at least only affects the cases that are already maligned by ADL, but it
> still has this characteristic that extending a library in natural ways
> becomes a potentially breaking change for API consumers. We do not need
> more features in C++ that make it hard to maintain large-scale codebases.
>
> What we really *should* add is a language feature that provides support
> for sane, principled, named, scoped extension points. UCS isn't that.
>

I'll throw in my two cents. From the above it sounds like Richard's
position is roughly "anti-UCS, anti-ADL, pro-customization-points". My own
position is roughly "anti-UCS, pro-ADL, pro-customization-points."

I *love* ADL. It seems very straightforward to me; I believe I understand
it; I appreciate that it makes operator overloading Just Work (and keeps
plain old functions working the same way as operator functions, by applying
the same ADL rules to both). I appreciate that in C++98 it allowed us to
reach into other namespaces to implement customization points like 'swap' *=
at
all*, even though I believe that we have learned a lot about *better*
interfaces for customization points in the intervening ~20 years.

For me, ADL is "just confusing enough". Adding UCS to the mix would make
the situation *so much more confusing* that I think I would be unhappy with
it. (Similarly, I think I am unhappy with class template constructor type
deduction in C++17.)  And what's the point of UCS? Just to allow one syntax
to "do everything"?  I *like* having different syntaxes for different
purposes =E2=80=94 having code-that-does-X look fundamentally different fro=
m
code-that-does-Y.

Re customization points, I would love it if std::swap(x,y) just Did The
Right Thing for any x and y (by hiding the ADL inside itself). But adding
UCS won't help with that problem at all.



>
> This is where I think it would be good to be able to separate technical
>> reservations (ie: the feature is broken and/or doesn't work to achieve i=
ts
>> stated goal) from other reservations. And that if a feature is going to
>> solve a problem that the language really needs to solve, then I believe
>> that non-technical reservations should not be counted as strongly as
>> technical reservations.
>>
>
> I have not heard any non-technical reservations be brought up as
> counterarguments to the UCS proposal.
>

There, I just made a couple. ;)  But then I ended by saying "adding UCS
won't help with [customization points] at all", which Nicol is counting as
a technical reservation: the feature doesn't work to achieve its stated
goal, if UCS's stated goal is really to help with customization points.
(I'm sure there must be other stated goals too.)

my $.02,
=E2=80=93Arthur

--=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/CAN-YmNORbWVB_ffuu%3Dh8o%2BMwUwW44AOSmnRXO0g50c_=
A6XXTOQ%40mail.gmail.com.

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

<div dir=3D"ltr">On Wed, Jan 4, 2017 at 7:55 PM, Richard Smith <span dir=3D=
"ltr">&lt;<a href=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">richar=
d@metafoo.co.uk</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div cl=
ass=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 cl=
ass=3D"gmail_extra"><div class=3D"gmail_quote"><div><div class=3D"h5">On 4 =
January 2017 at 19:14, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto:=
jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
>On Wednesday, January 4, 2017 at 3:49:00 PM UTC-5, Jens Maurer wrote:<div>=
<div class=3D"m_-7828000702212658719gmail-h5"><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"><br>Sometimes, a feature is discussed and progressed, =
but a substantial part
<br>of the committee has sustained reservations against the shape of the
<br>feature, thus failing to achieve consensus.=C2=A0 This happened with de=
faulted
<br>comparison operators (until now) and unified call syntax.<br></blockquo=
te></div></div><div><br>I think these are probably my biggest concerns, in =
terms of standardization. Particularly for UCS.<br><br>I say that because, =
while the &quot;sustained reservation&quot; people may have a point, that p=
oint cannot change the fact that <i>we need UCS</i>. One form, the other, o=
r both. But this is functionality that we as C++ users absolutely need.<br>=
</div></div></blockquote><div><br></div></div></div><div>The people with su=
stained reservations obviously disagree, or at least think the harm this fe=
ature does to the language outweighs the benefit. And the current levels of=
 adoption of the standard clearly demonstrate that we do not *need* this fe=
ature, or indeed any feature. It has merit, sure, but that must be weighed =
against other things.</div><span class=3D""><div><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Every time you have=
 to do `using std::swap` before `swap`ing some object, [...]<br></div></div=
></blockquote><div><br></div></span><div>The counterargument to that is tha=
t using unqualified names as extension points is a major mistake that signi=
ficantly harms the benefits that namespaces are supposed to provide. ADL fo=
r non-operators is harmful to the language, and UCS makes that harm signifi=
cantly worse by applying it in more cases.</div><div><br></div><div>The ful=
l UCS proposal also makes lots of previously-safe routine library maintenan=
ce (such as adding member functions) a potential source-breaking change for=
 API consumers (which might previously have been calling their own declarat=
ions of non-members via member syntax). The half-UCS approach at least only=
 affects the cases that are already maligned by ADL, but it still has this =
characteristic that extending a library in natural ways becomes a potential=
ly breaking change for API consumers. We do not need more features in C++ t=
hat make it hard to maintain large-scale codebases.</div><div><br></div><di=
v>What we really *should* add is a language feature that provides support f=
or sane, principled, named, scoped extension points. UCS isn&#39;t that.</d=
iv></div></div></div></blockquote><div><br></div><div>I&#39;ll throw in my =
two cents. From the above it sounds like Richard&#39;s position is roughly =
&quot;anti-UCS, anti-ADL, pro-customization-points&quot;. My own position i=
s roughly &quot;anti-UCS, pro-ADL, pro-customization-points.&quot;</div><di=
v><br></div><div>I <i>love</i> ADL. It seems very straightforward to me; I =
believe I understand it; I appreciate that it makes operator overloading Ju=
st Work (and keeps plain old functions working the same way as operator fun=
ctions, by applying the same ADL rules to both). I appreciate that in C++98=
 it allowed us to reach into other namespaces to implement customization po=
ints like &#39;swap&#39;=C2=A0<i>at all</i>, even though I believe that we =
have learned a lot about <i>better</i> interfaces for customization points =
in the intervening ~20 years.</div><div><br></div><div>For me, ADL is &quot=
;just confusing enough&quot;. Adding UCS to the mix would make the situatio=
n <i>so much more confusing</i> that I think I would be unhappy with it. (S=
imilarly, I think I am unhappy with class template constructor type deducti=
on in C++17.) =C2=A0And what&#39;s the point of UCS? Just to allow one synt=
ax to &quot;do everything&quot;?=C2=A0 I <i>like</i> having different synta=
xes for different purposes =E2=80=94 having code-that-does-X look fundament=
ally different from code-that-does-Y.</div><div><br></div><div>Re customiza=
tion points, I would love it if std::swap(x,y) just Did The Right Thing for=
 any x and y (by hiding the ADL inside itself). But adding UCS won&#39;t he=
lp with that problem at all.</div><div><br></div><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote"><span class=3D""><div><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><div dir=3D"ltr"><div>This is where I think it wou=
ld be good to be able to separate technical reservations (ie: the feature i=
s broken and/or doesn&#39;t work to achieve its stated goal) from other res=
ervations. And that if a feature is going to solve a problem that the langu=
age really needs to solve, then I believe that non-technical reservations s=
hould not be counted as strongly as technical reservations.<br></div></div>=
</blockquote><div><br></div></span><div>I have not heard any non-technical =
reservations be brought up as counterarguments to the UCS proposal.</div></=
div></div></div></blockquote><div><br></div><div>There, I just made a coupl=
e. ;) =C2=A0But then I ended by saying &quot;adding UCS won&#39;t help with=
 [customization points] at all&quot;, which Nicol is counting as a technica=
l reservation: the feature doesn&#39;t work to achieve its stated goal, if =
UCS&#39;s stated goal is really to help with customization points. (I&#39;m=
 sure there must be other stated goals too.)</div><div><br></div><div>my $.=
02,</div><div>=E2=80=93Arthur</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/CAN-YmNORbWVB_ffuu%3Dh8o%2BMwUwW44AOS=
mnRXO0g50c_A6XXTOQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAN-YmNORbWVB=
_ffuu%3Dh8o%2BMwUwW44AOSmnRXO0g50c_A6XXTOQ%40mail.gmail.com</a>.<br />

--001a1146b25082857f05455fc644--

.

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

On 5 January 2017 at 13:42, Arthur O'Dwyer <arthur.odwyer@mixpanel.com>
wrote:

> On Wed, Jan 4, 2017 at 7:55 PM, Richard Smith <richard@metafoo.co.uk>
> wrote:
>
>> On 4 January 2017 at 19:14, Nicol Bolas <jmckesson@gmail.com> wrote:
>>
>>> On Wednesday, January 4, 2017 at 3:49:00 PM UTC-5, Jens Maurer wrote:
>>>
>>>>
>>>> Sometimes, a feature is discussed and progressed, but a substantial
>>>> part
>>>> of the committee has sustained reservations against the shape of the
>>>> feature, thus failing to achieve consensus.  This happened with
>>>> defaulted
>>>> comparison operators (until now) and unified call syntax.
>>>>
>>>
>>> I think these are probably my biggest concerns, in terms of
>>> standardization. Particularly for UCS.
>>>
>>> I say that because, while the "sustained reservation" people may have a
>>> point, that point cannot change the fact that *we need UCS*. One form,
>>> the other, or both. But this is functionality that we as C++ users
>>> absolutely need.
>>>
>>
>> The people with sustained reservations obviously disagree, or at least
>> think the harm this feature does to the language outweighs the benefit. =
And
>> the current levels of adoption of the standard clearly demonstrate that =
we
>> do not *need* this feature, or indeed any feature. It has merit, sure, b=
ut
>> that must be weighed against other things.
>>
>> Every time you have to do `using std::swap` before `swap`ing some object=
,
>>> [...]
>>>
>>
>> The counterargument to that is that using unqualified names as extension
>> points is a major mistake that significantly harms the benefits that
>> namespaces are supposed to provide. ADL for non-operators is harmful to =
the
>> language, and UCS makes that harm significantly worse by applying it in
>> more cases.
>>
>> The full UCS proposal also makes lots of previously-safe routine library
>> maintenance (such as adding member functions) a potential source-breakin=
g
>> change for API consumers (which might previously have been calling their
>> own declarations of non-members via member syntax). The half-UCS approac=
h
>> at least only affects the cases that are already maligned by ADL, but it
>> still has this characteristic that extending a library in natural ways
>> becomes a potentially breaking change for API consumers. We do not need
>> more features in C++ that make it hard to maintain large-scale codebases=
..
>>
>> What we really *should* add is a language feature that provides support
>> for sane, principled, named, scoped extension points. UCS isn't that.
>>
>
> I'll throw in my two cents. From the above it sounds like Richard's
> position is roughly "anti-UCS, anti-ADL, pro-customization-points". My ow=
n
> position is roughly "anti-UCS, pro-ADL, pro-customization-points."
>

I think ADL is a pretty decent solution for operator lookup, since for the
most part we don't think of operators as being associated with a namespace.
(Sure, some people do overload binary * to mean something other than
multiplication, and it might be useful to have some way to scope a use of *
to mean only that other thing and never accidentally pick up a
multiplication operator, but that doesn't seem especially common in the
code I work with.)

If you think of operators as not really being associated with a namespace
(so that ADL makes sense for them), there's another solution to the
problem: all operator lookups find all declarations of the operator. And
then ADL is just a performance hack to cut down on the set of overloads the
compiler needs to consider.

I *love* ADL. It seems very straightforward to me; I believe I understand
> it; I appreciate that it makes operator overloading Just Work (and keeps
> plain old functions working the same way as operator functions, by applyi=
ng
> the same ADL rules to both).
>

The consistency argument between function calls and operator lookup is good
as far as it goes, but even with ADL for non-operator-syntax it is not the
case that "operator*(a, b)" means the same thing as "a * b" (and that's not
the case with any of the UCS approaches on the table either, for several
reasons).

I appreciate that in C++98 it allowed us to reach into other namespaces to
> implement customization points like 'swap' *at all*, even though I
> believe that we have learned a lot about *better* interfaces for
> customization points in the intervening ~20 years.
>
> For me, ADL is "just confusing enough". Adding UCS to the mix would make
> the situation *so much more confusing* that I think I would be unhappy
> with it. (Similarly, I think I am unhappy with class template constructor
> type deduction in C++17.)  And what's the point of UCS? Just to allow one
> syntax to "do everything"?  I *like* having different syntaxes for
> different purposes =E2=80=94 having code-that-does-X look fundamentally d=
ifferent
> from code-that-does-Y.
>

+1 to having different syntax for different purposes.

Re customization points, I would love it if std::swap(x,y) just Did The
> Right Thing for any x and y (by hiding the ADL inside itself). But adding
> UCS won't help with that problem at all.
>
>
> This is where I think it would be good to be able to separate technical
>>> reservations (ie: the feature is broken and/or doesn't work to achieve =
its
>>> stated goal) from other reservations. And that if a feature is going to
>>> solve a problem that the language really needs to solve, then I believe
>>> that non-technical reservations should not be counted as strongly as
>>> technical reservations.
>>>
>>
>> I have not heard any non-technical reservations be brought up as
>> counterarguments to the UCS proposal.
>>
>
> There, I just made a couple. ;)
>

=3D)


> But then I ended by saying "adding UCS won't help with [customization
> points] at all", which Nicol is counting as a technical reservation: the
> feature doesn't work to achieve its stated goal, if UCS's stated goal is
> really to help with customization points. (I'm sure there must be other
> stated goals too.)
>
> my $.02,
> =E2=80=93Arthur
>
> --
> 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/CAN-YmNORbWVB_ffuu%
> 3Dh8o%2BMwUwW44AOSmnRXO0g50c_A6XXTOQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAN-YmNORbW=
VB_ffuu%3Dh8o%2BMwUwW44AOSmnRXO0g50c_A6XXTOQ%40mail.gmail.com?utm_medium=3D=
email&utm_source=3Dfooter>
> .
>

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

--001a114e17b2fb50d9054561e0cd
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 5=
 January 2017 at 13:42, Arthur O&#39;Dwyer <span dir=3D"ltr">&lt;<a href=3D=
"mailto:arthur.odwyer@mixpanel.com" target=3D"_blank">arthur.odwyer@mixpane=
l.com</a>&gt;</span> wrote:<br><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"><span class=3D"">On Wed, Jan 4, 2017 at 7:55 PM, Richard Smith <span di=
r=3D"ltr">&lt;<a href=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">ri=
chard@metafoo.co.uk</a>&gt;</span> wrote:<br></span><div class=3D"gmail_ext=
ra"><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 class=3D"gmail_extra"><div class=3D"gmail_quote"><div><div class=
=3D"m_2436501573777307044h5"><span class=3D"">On 4 January 2017 at 19:14, N=
icol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.com" tar=
get=3D"_blank">jmckesson@gmail.com</a>&gt;</span> wrote:<br></span><blockqu=
ote 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"><span class=3D""=
>On Wednesday, January 4, 2017 at 3:49:00 PM UTC-5, Jens Maurer wrote:</spa=
n><span class=3D""><div><div class=3D"m_2436501573777307044m_-7828000702212=
658719gmail-h5"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>Somet=
imes, a feature is discussed and progressed, but a substantial part
<br>of the committee has sustained reservations against the shape of the
<br>feature, thus failing to achieve consensus.=C2=A0 This happened with de=
faulted
<br>comparison operators (until now) and unified call syntax.<br></blockquo=
te></div></div><div><br>I think these are probably my biggest concerns, in =
terms of standardization. Particularly for UCS.<br><br>I say that because, =
while the &quot;sustained reservation&quot; people may have a point, that p=
oint cannot change the fact that <i>we need UCS</i>. One form, the other, o=
r both. But this is functionality that we as C++ users absolutely need.<br>=
</div></span></div></blockquote><div><br></div></div></div><span class=3D""=
><div>The people with sustained reservations obviously disagree, or at leas=
t think the harm this feature does to the language outweighs the benefit. A=
nd the current levels of adoption of the standard clearly demonstrate that =
we do not *need* this feature, or indeed any feature. It has merit, sure, b=
ut that must be weighed against other things.</div></span><span><div><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div=
>Every time you have to do `using std::swap` before `swap`ing some object, =
[...]<br></div></div></blockquote><div><br></div></span><span class=3D""><d=
iv>The counterargument to that is that using unqualified names as extension=
 points is a major mistake that significantly harms the benefits that names=
paces are supposed to provide. ADL for non-operators is harmful to the lang=
uage, and UCS makes that harm significantly worse by applying it in more ca=
ses.</div><div><br></div><div>The full UCS proposal also makes lots of prev=
iously-safe routine library maintenance (such as adding member functions) a=
 potential source-breaking change for API consumers (which might previously=
 have been calling their own declarations of non-members via member syntax)=
.. The half-UCS approach at least only affects the cases that are already ma=
ligned by ADL, but it still has this characteristic that extending a librar=
y in natural ways becomes a potentially breaking change for API consumers. =
We do not need more features in C++ that make it hard to maintain large-sca=
le codebases.</div><div><br></div><div>What we really *should* add is a lan=
guage feature that provides support for sane, principled, named, scoped ext=
ension points. UCS isn&#39;t that.</div></span></div></div></div></blockquo=
te><div><br></div><div>I&#39;ll throw in my two cents. From the above it so=
unds like Richard&#39;s position is roughly &quot;anti-UCS, anti-ADL, pro-c=
ustomization-points&quot;. My own position is roughly &quot;anti-UCS, pro-A=
DL, pro-customization-points.&quot;</div></div></div></div></blockquote><di=
v><br></div><div>I think ADL is a pretty decent solution for operator looku=
p, since for the most part we don&#39;t think of operators as being associa=
ted with a namespace. (Sure, some people do overload binary * to mean somet=
hing other than multiplication, and it might be useful to have some way to =
scope a use of * to mean only that other thing and never accidentally pick =
up a multiplication operator, but that doesn&#39;t seem especially common i=
n the code I work with.)<br></div><div><br></div><div>If you think of opera=
tors as not really being associated with a namespace (so that ADL makes sen=
se for them), there&#39;s another solution to the problem: all operator loo=
kups find all declarations of the operator. And then ADL is just a performa=
nce hack to cut down on the set of overloads the compiler needs to consider=
..</div><div><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"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><div>I <i>love</i> ADL. It=
 seems very straightforward to me; I believe I understand it; I appreciate =
that it makes operator overloading Just Work (and keeps plain old functions=
 working the same way as operator functions, by applying the same ADL rules=
 to both).</div></div></div></div></blockquote><div><br></div><div>The cons=
istency argument between function calls and operator lookup is good as far =
as it goes, but even with ADL for non-operator-syntax it is not the case th=
at &quot;operator*(a, b)&quot; means the same thing as &quot;a * b&quot; (a=
nd that&#39;s not the case with any of the UCS approaches on the table eith=
er, for several reasons).</div><div><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><d=
iv>I appreciate that in C++98 it allowed us to reach into other namespaces =
to implement customization points like &#39;swap&#39;=C2=A0<i>at all</i>, e=
ven though I believe that we have learned a lot about <i>better</i> interfa=
ces for customization points in the intervening ~20 years.</div><div><br></=
div><div>For me, ADL is &quot;just confusing enough&quot;. Adding UCS to th=
e mix would make the situation <i>so much more confusing</i> that I think I=
 would be unhappy with it. (Similarly, I think I am unhappy with class temp=
late constructor type deduction in C++17.) =C2=A0And what&#39;s the point o=
f UCS? Just to allow one syntax to &quot;do everything&quot;?=C2=A0 I <i>li=
ke</i> having different syntaxes for different purposes =E2=80=94 having co=
de-that-does-X look fundamentally different from code-that-does-Y.</div></d=
iv></div></div></blockquote><div><br></div><div>+1 to having different synt=
ax for different purposes.</div><div><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><=
div>Re customization points, I would love it if std::swap(x,y) just Did The=
 Right Thing for any x and y (by hiding the ADL inside itself). But adding =
UCS won&#39;t help with that problem at all.</div><span class=3D""><div><br=
></div><div><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"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><span><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex"><div dir=3D"ltr"><div>This is where I think i=
t would be good to be able to separate technical reservations (ie: the feat=
ure is broken and/or doesn&#39;t work to achieve its stated goal) from othe=
r reservations. And that if a feature is going to solve a problem that the =
language really needs to solve, then I believe that non-technical reservati=
ons should not be counted as strongly as technical reservations.<br></div><=
/div></blockquote><div><br></div></span><div>I have not heard any non-techn=
ical reservations be brought up as counterarguments to the UCS proposal.</d=
iv></div></div></div></blockquote><div><br></div></span><div>There, I just =
made a couple. ;)</div></div></div></div></blockquote><div><br></div><div>=
=3D)</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>But then I ended=
 by saying &quot;adding UCS won&#39;t help with [customization points] at a=
ll&quot;, which Nicol is counting as a technical reservation: the feature d=
oesn&#39;t work to achieve its stated goal, if UCS&#39;s stated goal is rea=
lly to help with customization points. (I&#39;m sure there must be other st=
ated goals too.)</div><div><br></div><div>my $.02,</div><div>=E2=80=93Arthu=
r</div></div></div></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<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/CAN-YmNORbWVB_ffuu%3Dh8o%2BMwUwW44AOS=
mnRXO0g50c_A6XXTOQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/=
std-<wbr>proposals/CAN-YmNORbWVB_ffuu%<wbr>3Dh8o%2BMwUwW44AOSmnRXO0g50c_<wb=
r>A6XXTOQ%40mail.gmail.com</a>.<br>
</blockquote></div><br></div></div>

<p></p>

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

--001a114e17b2fb50d9054561e0cd--

.

------=_Part_204_205345586.1483716993669
Content-Type: multipart/alternative;
 boundary="----=_Part_205_463633533.1483716993669"

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

On Thursday, January 5, 2017 at 9:42:20 PM UTC, Arthur O'Dwyer wrote:
>
> [...]
> For me, ADL is "just confusing enough". Adding UCS to the mix would make=
=20
> the situation *so much more confusing* that I think I would be unhappy=20
> with it. (Similarly, I think I am unhappy with class template constructor=
=20
> type deduction in C++17.)  And what's the point of UCS? Just to allow one=
=20
> syntax to "do everything"?  I *like* having different syntaxes for=20
> different purposes =E2=80=94 having code-that-does-X look fundamentally d=
ifferent=20
> from code-that-does-Y.
>
>
well, the thing is invoking a member function is not fundamentally=20
different than invoking a free function. The former, at least in the=20
non-virtual case, is very thin syntactic sugar over the later.

-- gpd

--=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/66a14a80-82d6-48cd-a726-a7a7ef957638%40isocpp.or=
g.

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

<div dir=3D"ltr">On Thursday, January 5, 2017 at 9:42:20 PM UTC, Arthur O&#=
39;Dwyer 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 class=3D"gmail_quote">[...]<br><div>For me, ADL is &quot;just c=
onfusing enough&quot;. Adding UCS to the mix would make the situation <i>so=
 much more confusing</i> that I think I would be unhappy with it. (Similarl=
y, I think I am unhappy with class template constructor type deduction in C=
++17.) =C2=A0And what&#39;s the point of UCS? Just to allow one syntax to &=
quot;do everything&quot;?=C2=A0 I <i>like</i> having different syntaxes for=
 different purposes =E2=80=94 having code-that-does-X look fundamentally di=
fferent from code-that-does-Y.</div><br></div></div></div></blockquote><div=
><br>well, the thing is invoking a member function is not fundamentally dif=
ferent than invoking a free function. The former, at least in the non-virtu=
al case, is very thin syntactic sugar over the later.<br><br>-- gpd<br></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/66a14a80-82d6-48cd-a726-a7a7ef957638%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/66a14a80-82d6-48cd-a726-a7a7ef957638=
%40isocpp.org</a>.<br />

------=_Part_205_463633533.1483716993669--

------=_Part_204_205345586.1483716993669--

.

On 01/06/2017 04:36 PM, Giovanni Piero Deretta wrote:
> well, the thing is invoking a member function is not fundamentally different than invoking a free function. The former, at least in the non-virtual case, is very thin syntactic sugar over the later.

Name lookup is totally different.

Jens

--
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/586FF0F4.6000408%40gmx.net.

.

------=_Part_409_1892422407.1483810220061
Content-Type: multipart/alternative;
 boundary="----=_Part_410_1106831095.1483810220062"

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

On Thursday, January 5, 2017 at 4:42:20 PM UTC-5, Arthur O'Dwyer wrote:
>
> On Wed, Jan 4, 2017 at 7:55 PM, Richard Smith <ric...@metafoo.co.uk=20
> <javascript:>> wrote:
>
>> On 4 January 2017 at 19:14, Nicol Bolas <jmck...@gmail.com <javascript:>=
>=20
>> wrote:
>>
>>> On Wednesday, January 4, 2017 at 3:49:00 PM UTC-5, Jens Maurer wrote:
>>>
>>>>
>>>> Sometimes, a feature is discussed and progressed, but a substantial=20
>>>> part=20
>>>> of the committee has sustained reservations against the shape of the=
=20
>>>> feature, thus failing to achieve consensus.  This happened with=20
>>>> defaulted=20
>>>> comparison operators (until now) and unified call syntax.
>>>>
>>>
>>> I think these are probably my biggest concerns, in terms of=20
>>> standardization. Particularly for UCS.
>>>
>>> I say that because, while the "sustained reservation" people may have a=
=20
>>> point, that point cannot change the fact that *we need UCS*. One form,=
=20
>>> the other, or both. But this is functionality that we as C++ users=20
>>> absolutely need.
>>>
>>
>> The people with sustained reservations obviously disagree, or at least=
=20
>> think the harm this feature does to the language outweighs the benefit. =
And=20
>> the current levels of adoption of the standard clearly demonstrate that =
we=20
>> do not *need* this feature, or indeed any feature. It has merit, sure, b=
ut=20
>> that must be weighed against other things.
>>
>> Every time you have to do `using std::swap` before `swap`ing some object=
,=20
>>> [...]
>>>
>>
>> The counterargument to that is that using unqualified names as extension=
=20
>> points is a major mistake that significantly harms the benefits that=20
>> namespaces are supposed to provide. ADL for non-operators is harmful to =
the=20
>> language, and UCS makes that harm significantly worse by applying it in=
=20
>> more cases.
>>
>> The full UCS proposal also makes lots of previously-safe routine library=
=20
>> maintenance (such as adding member functions) a potential source-breakin=
g=20
>> change for API consumers (which might previously have been calling their=
=20
>> own declarations of non-members via member syntax). The half-UCS approac=
h=20
>> at least only affects the cases that are already maligned by ADL, but it=
=20
>> still has this characteristic that extending a library in natural ways=
=20
>> becomes a potentially breaking change for API consumers. We do not need=
=20
>> more features in C++ that make it hard to maintain large-scale codebases=
..
>>
>> What we really *should* add is a language feature that provides support=
=20
>> for sane, principled, named, scoped extension points. UCS isn't that.
>>
>
> I'll throw in my two cents. From the above it sounds like Richard's=20
> position is roughly "anti-UCS, anti-ADL, pro-customization-points". My ow=
n=20
> position is roughly "anti-UCS, pro-ADL, pro-customization-points."
>

From a standardization perspective, this goes back to the P0057 vs. the=20
world issue.

Namely, a lot of people really dislike P0057: co_await and its ilk. They=20
think it's a terrible way to do async coding, and some of them have=20
experience with similar features in other languages which create a=20
nightmare of unmaintainable code. All of the opponents of P0057 agree that=
=20
there has to be a better alternative.

The problem is... they don't know what that is. Nor do they have the=20
resources to actually research it. They can produce a lot of paper, but=20
none of them have the ability and/or the time to implement these ideas in a=
=20
compiler. To actually prove that they can work and do the things they say=
=20
it can do.

By contrast, P0057 moves forward because, despite the opposition... it=20
works. It has an implementation in a real compiler. It's something more=20
than just a few sketches of ideas; it's a firm proposal with both standard=
=20
wording and a rapidly maturing implementation.

I see UCS in a similar light. There's opposition to it, but the opposition=
=20
doesn't have any proposals for actually solving any of the problems that=20
UCS solves.

You talk about customization points. But you have no proposals for=20
integrating those into the language, of defining a consistent way for=20
people to write their own. You have no proposals for fixing the problems in=
=20
the existing customization points in the standard library or adding new=20
ones that lack those problems.

I do not like P0057. I think it is a silly, limited feature, and I agree=20
with the arguments that widespread use of it can lead to painful code. But=
=20
it solves a problem the language genuinely needs solving. So unless the=20
alternatives can mature into something more than paper ideas, then despite=
=20
its problems, I would have to support P0057 *for the good of the language*.

And I feel the same way about UCS. I do not agree with everything in it.=20
But it does solve a significant problem the language has. And any potential=
=20
harm it causes is based on potential harm that already exists (re: ADL).=20
Since C++ needs a solution to those problems, unless some other solution=20
arises that also solves them, we should move forward with what we have now=
=20
for the good of the language.

These kinds of problem-based compromises are the sorts of things that I=20
feel are lacking from the committee at this time. The recognition that C++=
=20
really needs something to deal with X, and proposal Y deals with X, so=20
unless there is a proposal Z that also solves X, then you should support Y.

I know that sounds ironic, considering my opposition to Concepts TS=20
integration into C++17. But that's because I feel the proposal hasn't=20
cooked enough yet, that it needs refactoring. Not because I'm opposed to it=
=20
on a fundamental level.

I *love* ADL. It seems very straightforward to me; I believe I understand=
=20
> it; I appreciate that it makes operator overloading Just Work (and keeps=
=20
> plain old functions working the same way as operator functions, by applyi=
ng=20
> the same ADL rules to both). I appreciate that in C++98 it allowed us to=
=20
> reach into other namespaces to implement customization points like 'swap'=
 *at=20
> all*, even though I believe that we have learned a lot about *better*=20
> interfaces for customization points in the intervening ~20 years.
>
=20
>
For me, ADL is "just confusing enough". Adding UCS to the mix would make=20
> the situation *so much more confusing* that I think I would be unhappy=20
> with it. (Similarly, I think I am unhappy with class template constructor=
=20
> type deduction in C++17.)  And what's the point of UCS? Just to allow one=
=20
> syntax to "do everything"?  I *like* having different syntaxes for=20
> different purposes =E2=80=94 having code-that-does-X look fundamentally d=
ifferent=20
> from code-that-does-Y.
>

The problem with this kind of thinking is that it encourages the=20
proliferation of syntaxes for doing the same thing, but in ways whose=20
differences are things that only experts know about. Because at the end of=
=20
the day, most users do not want to, or *need to*, think about the=20
distinction between member call and non-member call.

Re customization points, I would love it if std::swap(x,y) just Did The=20
> Right Thing for any x and y (by hiding the ADL inside itself). But adding=
=20
> UCS won't help with that problem at all.
>

UCS doesn't solve the problem of writing a `std::swap` that calls the right=
=20
function. But that's not its goal. Its goal is to let `swap(x, y)` *by=20
itself* call the right function, to bypass `std::swap` entirely.

UCS helps with customization points by *making them obsolete* ;)

It should also be noted that your "Did The Right Thing" for `std::swap`=20
still requires me to write both member-`swap` and non-member `swap`=20
functions (since you said `std::swap` should use ADL to find the right=20
`swap` function). ADL-based customization points require lots of needless=
=20
repetition.

One of the main purposes of UCS in this regard is to promote DRY=20
principles: you write *one function*. You choose for yourself whether it is=
=20
a member or non-member function, based on your needs. And the user has a=20
way to call it, regardless of how you choose to expose it.

Or do you really like writing the 12 functions it takes to make a proper=20
ADL-based container class=20
<http://stackoverflow.com/questions/39231664/what-is-the-preferred-way-to-e=
xpose-custom-stl-style-iteration>
?

--=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/fb3436c7-1d7b-478f-b476-50f2a2ef09eb%40isocpp.or=
g.

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

<div dir=3D"ltr">On Thursday, January 5, 2017 at 4:42:20 PM UTC-5, Arthur O=
&#39;Dwyer 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">On Wed, Jan 4, 2017 at 7:55 PM, Richard Smith <span dir=3D"ltr">&lt;<a =
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"6o8SGuEmDAA=
J" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return=
 true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">ric...@m=
etafoo.co.uk</a>&gt;</span> wrote:<br><div><div class=3D"gmail_quote"><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">=
<div><div>On 4 January 2017 at 19:14, Nicol Bolas <span dir=3D"ltr">&lt;<a =
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"6o8SGuEmDAA=
J" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return=
 true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">jmck...@=
gmail.com</a>&gt;</span> wrote:<br><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">On Wednesday, January 4, 2017 at 3:49:00 PM UTC=
-5, Jens Maurer wrote:<div><div><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"><br>Sometimes, a feature is discussed and progressed, but a substant=
ial part
<br>of the committee has sustained reservations against the shape of the
<br>feature, thus failing to achieve consensus.=C2=A0 This happened with de=
faulted
<br>comparison operators (until now) and unified call syntax.<br></blockquo=
te></div></div><div><br>I think these are probably my biggest concerns, in =
terms of standardization. Particularly for UCS.<br><br>I say that because, =
while the &quot;sustained reservation&quot; people may have a point, that p=
oint cannot change the fact that <i>we need UCS</i>. One form, the other, o=
r both. But this is functionality that we as C++ users absolutely need.<br>=
</div></div></blockquote><div><br></div></div></div><div>The people with su=
stained reservations obviously disagree, or at least think the harm this fe=
ature does to the language outweighs the benefit. And the current levels of=
 adoption of the standard clearly demonstrate that we do not *need* this fe=
ature, or indeed any feature. It has merit, sure, but that must be weighed =
against other things.</div><span><div><br></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>Every time you have to do `usi=
ng std::swap` before `swap`ing some object, [...]<br></div></div></blockquo=
te><div><br></div></span><div>The counterargument to that is that using unq=
ualified names as extension points is a major mistake that significantly ha=
rms the benefits that namespaces are supposed to provide. ADL for non-opera=
tors is harmful to the language, and UCS makes that harm significantly wors=
e by applying it in more cases.</div><div><br></div><div>The full UCS propo=
sal also makes lots of previously-safe routine library maintenance (such as=
 adding member functions) a potential source-breaking change for API consum=
ers (which might previously have been calling their own declarations of non=
-members via member syntax). The half-UCS approach at least only affects th=
e cases that are already maligned by ADL, but it still has this characteris=
tic that extending a library in natural ways becomes a potentially breaking=
 change for API consumers. We do not need more features in C++ that make it=
 hard to maintain large-scale codebases.</div><div><br></div><div>What we r=
eally *should* add is a language feature that provides support for sane, pr=
incipled, named, scoped extension points. UCS isn&#39;t that.</div></div></=
div></div></blockquote><div><br></div><div>I&#39;ll throw in my two cents. =
From the above it sounds like Richard&#39;s position is roughly &quot;anti-=
UCS, anti-ADL, pro-customization-points&quot;. My own position is roughly &=
quot;anti-UCS, pro-ADL, pro-customization-points.&quot;</div></div></div></=
div></blockquote><div><br>From a standardization perspective, this goes bac=
k to the P0057 vs. the world issue.<br><br>Namely, a lot of people really d=
islike P0057: co_await and its ilk. They think it&#39;s a terrible way to d=
o async coding, and some of them have experience with similar features in o=
ther languages which create a nightmare of unmaintainable code. All of the =
opponents of P0057 agree that there has to be a better alternative.<br><br>=
The problem is... they don&#39;t know what that is. Nor do they have the re=
sources to actually research it. They can produce a lot of paper, but none =
of them have the ability and/or the time to implement these ideas in a comp=
iler. To actually prove that they can work and do the things they say it ca=
n do.<br><br>By contrast, P0057 moves forward because, despite the oppositi=
on... it works. It has an implementation in a real compiler. It&#39;s somet=
hing more than just a few sketches of ideas; it&#39;s a firm proposal with =
both standard wording and a rapidly maturing implementation.<br><br>I see U=
CS in a similar light. There&#39;s opposition to it, but the opposition doe=
sn&#39;t have any proposals for actually solving any of the problems that U=
CS solves.<br><br>You talk about customization points. But you have no prop=
osals for integrating those into the language, of defining a consistent way=
 for people to write their own. You have no proposals for fixing the proble=
ms in the existing customization points in the standard library or adding n=
ew ones that lack those problems.<br><br>I do not like P0057. I think it is=
 a silly, limited feature, and I agree with the arguments that widespread u=
se of it can lead to painful code. But it solves a problem the language gen=
uinely needs solving. So unless the alternatives can mature into something =
more than paper ideas, then despite its problems, I would have to support P=
0057 <i>for the good of the language</i>.<br><br>And I feel the same way ab=
out UCS. I do not agree with everything in it. But it does solve a signific=
ant problem the language has. And any potential harm it causes is based on =
potential harm that already exists (re: ADL). Since C++ needs a solution to=
 those problems, unless some other solution arises that also solves them, w=
e should move forward with what we have now for the good of the language.<b=
r><br>These kinds of problem-based compromises are the sorts of things that=
 I feel are lacking from the committee at this time. The recognition that C=
++ really needs something to deal with X, and proposal Y deals with X, so u=
nless there is a proposal Z that also solves X, then you should support Y.<=
br><br>I know that sounds ironic, considering my opposition to Concepts TS =
integration into C++17. But that&#39;s because I feel the proposal hasn&#39=
;t cooked enough yet, that it needs refactoring. Not because I&#39;m oppose=
d to it on a fundamental level.<br><br></div><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"><div><div class=3D"gmail_quote"><div></div>=
<div>I <i>love</i> ADL. It seems very straightforward to me; I believe I un=
derstand it; I appreciate that it makes operator overloading Just Work (and=
 keeps plain old functions working the same way as operator functions, by a=
pplying the same ADL rules to both). I appreciate that in C++98 it allowed =
us to reach into other namespaces to implement customization points like &#=
39;swap&#39;=C2=A0<i>at all</i>, even though I believe that we have learned=
 a lot about <i>better</i> interfaces for customization points in the inter=
vening ~20 years.</div></div></div></div></blockquote><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>=C2=A0</div></blockquote><blockqu=
ote 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 class=3D"gm=
ail_quote"><div>For me, ADL is &quot;just confusing enough&quot;. Adding UC=
S to the mix would make the situation <i>so much more confusing</i> that I =
think I would be unhappy with it. (Similarly, I think I am unhappy with cla=
ss template constructor type deduction in C++17.) =C2=A0And what&#39;s the =
point of UCS? Just to allow one syntax to &quot;do everything&quot;?=C2=A0 =
I <i>like</i> having different syntaxes for different purposes =E2=80=94 ha=
ving code-that-does-X look fundamentally different from code-that-does-Y.</=
div></div></div></div></blockquote><div><br>The problem with this kind of t=
hinking is that it encourages the proliferation of syntaxes for doing the s=
ame thing, but in ways whose differences are things that only experts know =
about. Because at the end of the day, most users do not want to, or <i>need=
 to</i>, think about the distinction between member call and non-member cal=
l.<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"lt=
r"><div><div class=3D"gmail_quote"><div>Re customization points, I would lo=
ve it if std::swap(x,y) just Did The Right Thing for any x and y (by hiding=
 the ADL inside itself). But adding UCS won&#39;t help with that problem at=
 all.</div></div></div></div></blockquote><div><br>UCS doesn&#39;t solve th=
e problem of writing a `std::swap` that calls the right function. But that&=
#39;s not its goal. Its goal is to let `swap(x, y)` <i>by itself</i> call t=
he right function, to bypass `std::swap` entirely.<br><br>UCS helps with cu=
stomization points by <i>making them obsolete</i> ;)<br><br>It should also =
be noted that your &quot;Did The Right Thing&quot; for `std::swap` still re=
quires me to write both member-`swap` and non-member `swap` functions (sinc=
e you said `std::swap` should use ADL to find the right `swap` function). A=
DL-based customization points require lots of needless repetition.<br><br>O=
ne of the main purposes of UCS in this regard is to promote DRY principles:=
 you write <i>one function</i>. You choose for yourself whether it is a mem=
ber or non-member function, based on your needs. And the user has a way to =
call it, regardless of how you choose to expose it.<br><br>Or do you really=
 like writing <a href=3D"http://stackoverflow.com/questions/39231664/what-i=
s-the-preferred-way-to-expose-custom-stl-style-iteration">the 12 functions =
it takes to make a proper ADL-based container class</a>?</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/fb3436c7-1d7b-478f-b476-50f2a2ef09eb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fb3436c7-1d7b-478f-b476-50f2a2ef09eb=
%40isocpp.org</a>.<br />

------=_Part_410_1106831095.1483810220062--

------=_Part_409_1892422407.1483810220061--

.

On 01/07/2017 06:30 PM, Nicol Bolas wrote:
> Namely, a lot of people really dislike P0057: co_await and its ilk. They =
think it's a terrible way to do async coding, and some of them have experie=
nce with similar features in other languages which create a nightmare of un=
maintainable code. All of the opponents of P0057 agree that there has to be=
 a better alternative.
>=20
> The problem is... they don't know what that is. Nor do they have the reso=
urces to actually research it. They can produce a lot of paper, but none of=
 them have the ability and/or the time to implement these ideas in a compil=
er. To actually prove that they can work and do the things they say it can =
do.

That's not entirely accurate.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0099r1.pdf

has a pure library interface, has been implemented and used,
doesn't require viral annotations of function call stacks, and
reportedly has similar performance as P0057.

> I see UCS in a similar light. There's opposition to it, but the oppositio=
n doesn't have any proposals for actually solving any of the problems that =
UCS solves.

Sure; see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0301r1.h=
tml.
This went down in EWG in Oulu.

This is one example of call-site opt-in; other syntax is also conceivable.

I have no objection against a unified call syntax.  For initialization,
a rarely-used syntax using braces was extended with new features.
Why can't we do the same for function calls? If we want new feature,
let's use new syntax.

Even something like @f(x, y) for a unified call is conceivable.
(@ has character set issues, but you get the idea).
Maybe lots of code will use @f in the future; mine won't except
when I actually mean "call via customization point".

Again, I took the Oulu result as discouraging call-site opt-in
in general. If you feel you want to try again with a different
syntax, please go ahead.

Jens

--=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/58714CD9.5050506%40gmx.net.

.

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

On 7 January 2017 at 09:30, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Thursday, January 5, 2017 at 4:42:20 PM UTC-5, Arthur O'Dwyer wrote:
>>
>> On Wed, Jan 4, 2017 at 7:55 PM, Richard Smith <ric...@metafoo.co.uk>
>> wrote:
>>
>>> On 4 January 2017 at 19:14, Nicol Bolas <jmck...@gmail.com> wrote:
>>>
>>>> On Wednesday, January 4, 2017 at 3:49:00 PM UTC-5, Jens Maurer wrote:
>>>>
>>>>>
>>>>> Sometimes, a feature is discussed and progressed, but a substantial
>>>>> part
>>>>> of the committee has sustained reservations against the shape of the
>>>>> feature, thus failing to achieve consensus.  This happened with
>>>>> defaulted
>>>>> comparison operators (until now) and unified call syntax.
>>>>>
>>>>
>>>> I think these are probably my biggest concerns, in terms of
>>>> standardization. Particularly for UCS.
>>>>
>>>> I say that because, while the "sustained reservation" people may have =
a
>>>> point, that point cannot change the fact that *we need UCS*. One form,
>>>> the other, or both. But this is functionality that we as C++ users
>>>> absolutely need.
>>>>
>>>
>>> The people with sustained reservations obviously disagree, or at least
>>> think the harm this feature does to the language outweighs the benefit.=
 And
>>> the current levels of adoption of the standard clearly demonstrate that=
 we
>>> do not *need* this feature, or indeed any feature. It has merit, sure, =
but
>>> that must be weighed against other things.
>>>
>>> Every time you have to do `using std::swap` before `swap`ing some
>>>> object, [...]
>>>>
>>>
>>> The counterargument to that is that using unqualified names as extensio=
n
>>> points is a major mistake that significantly harms the benefits that
>>> namespaces are supposed to provide. ADL for non-operators is harmful to=
 the
>>> language, and UCS makes that harm significantly worse by applying it in
>>> more cases.
>>>
>>> The full UCS proposal also makes lots of previously-safe routine librar=
y
>>> maintenance (such as adding member functions) a potential source-breaki=
ng
>>> change for API consumers (which might previously have been calling thei=
r
>>> own declarations of non-members via member syntax). The half-UCS approa=
ch
>>> at least only affects the cases that are already maligned by ADL, but i=
t
>>> still has this characteristic that extending a library in natural ways
>>> becomes a potentially breaking change for API consumers. We do not need
>>> more features in C++ that make it hard to maintain large-scale codebase=
s.
>>>
>>> What we really *should* add is a language feature that provides support
>>> for sane, principled, named, scoped extension points. UCS isn't that.
>>>
>>
>> I'll throw in my two cents. From the above it sounds like Richard's
>> position is roughly "anti-UCS, anti-ADL, pro-customization-points". My o=
wn
>> position is roughly "anti-UCS, pro-ADL, pro-customization-points."
>>
>
> From a standardization perspective, this goes back to the P0057 vs. the
> world issue.
>
> Namely, a lot of people really dislike P0057: co_await and its ilk. They
> think it's a terrible way to do async coding, and some of them have
> experience with similar features in other languages which create a
> nightmare of unmaintainable code. All of the opponents of P0057 agree tha=
t
> there has to be a better alternative.
>
> The problem is... they don't know what that is. Nor do they have the
> resources to actually research it. They can produce a lot of paper, but
> none of them have the ability and/or the time to implement these ideas in=
 a
> compiler. To actually prove that they can work and do the things they say
> it can do.
>
> By contrast, P0057 moves forward because, despite the opposition... it
> works. It has an implementation in a real compiler. It's something more
> than just a few sketches of ideas; it's a firm proposal with both standar=
d
> wording and a rapidly maturing implementation.
>
> I see UCS in a similar light. There's opposition to it, but the oppositio=
n
> doesn't have any proposals for actually solving any of the problems that
> UCS solves.
>
> You talk about customization points. But you have no proposals for
> integrating those into the language, of defining a consistent way for
> people to write their own. You have no proposals for fixing the problems =
in
> the existing customization points in the standard library or adding new
> ones that lack those problems.
>
> I do not like P0057. I think it is a silly, limited feature, and I agree
> with the arguments that widespread use of it can lead to painful code. Bu=
t
> it solves a problem the language genuinely needs solving. So unless the
> alternatives can mature into something more than paper ideas, then despit=
e
> its problems, I would have to support P0057 *for the good of the language=
*
> .
>
> And I feel the same way about UCS. I do not agree with everything in it.
> But it does solve a significant problem the language has. And any potenti=
al
> harm it causes is based on potential harm that already exists (re: ADL).
>

That's not true with the full UCS feature. If I don't want to use P0057, I
don't use it, and move on with my life. If I don't want to use UCS, and I'm
a library vendor, I still have to deal with the pain that it imposes on
everyone. I can't add a new member function foo to my class without risking
breaking people who were using "my_class.foo()" to find a non-member "foo"
by UCS.

And that's why there was strong technical opposition to the full UCS
proposal. The half-UCS proposal, as you say, has only the same potential
problems as ADL (as it only affects the same expressions where ADL would
have been performed) -- and indeed I made that point during discussion in
plenary. The technical opposition that seemed to carry the room was that a
proper UCS proposal should (a) consider members and non-members equally,
rather than preferring one over the other, (b) not be the default behavior;
calling an extension point is a special exception, not the common case, (c)
not change the meaning of existing code, and (d) not require extra lookup
and overload resolution cost for every function call. These all point to
using a new syntax.

Since C++ needs a solution to those problems, unless some other solution
> arises that also solves them, we should move forward with what we have no=
w
> for the good of the language.
>

Actually, another solution has been proposed: use a new syntax, such as
swap.(x, y), to express a UDL call. (This means that extension point names
can't be meaningfully namespaced, but maybe that's OK, since they should be
rare.)

These kinds of problem-based compromises are the sorts of things that I
> feel are lacking from the committee at this time. The recognition that C+=
+
> really needs something to deal with X, and proposal Y deals with X, so
> unless there is a proposal Z that also solves X, then you should support =
Y.
>

You are assuming that there is consensus that C++ needs to deal with X in
this case. I do not think there is.

I know that sounds ironic, considering my opposition to Concepts TS
> integration into C++17. But that's because I feel the proposal hasn't
> cooked enough yet, that it needs refactoring. Not because I'm opposed to =
it
> on a fundamental level.
>
> I *love* ADL. It seems very straightforward to me; I believe I understand
>> it; I appreciate that it makes operator overloading Just Work (and keeps
>> plain old functions working the same way as operator functions, by apply=
ing
>> the same ADL rules to both). I appreciate that in C++98 it allowed us to
>> reach into other namespaces to implement customization points like 'swap=
' *at
>> all*, even though I believe that we have learned a lot about *better*
>> interfaces for customization points in the intervening ~20 years.
>>
>
>>
> For me, ADL is "just confusing enough". Adding UCS to the mix would make
>> the situation *so much more confusing* that I think I would be unhappy
>> with it. (Similarly, I think I am unhappy with class template constructo=
r
>> type deduction in C++17.)  And what's the point of UCS? Just to allow on=
e
>> syntax to "do everything"?  I *like* having different syntaxes for
>> different purposes =E2=80=94 having code-that-does-X look fundamentally =
different
>> from code-that-does-Y.
>>
>
> The problem with this kind of thinking is that it encourages the
> proliferation of syntaxes for doing the same thing, but in ways whose
> differences are things that only experts know about. Because at the end o=
f
> the day, most users do not want to, or *need to*, think about the
> distinction between member call and non-member call.
>
> Re customization points, I would love it if std::swap(x,y) just Did The
>> Right Thing for any x and y (by hiding the ADL inside itself). But addin=
g
>> UCS won't help with that problem at all.
>>
>
> UCS doesn't solve the problem of writing a `std::swap` that calls the
> right function. But that's not its goal. Its goal is to let `swap(x, y)` =
*by
> itself* call the right function, to bypass `std::swap` entirely.
>
> UCS helps with customization points by *making them obsolete* ;)
>

To the extent it does that, it also destroys the benefits of namespaces.

It should also be noted that your "Did The Right Thing" for `std::swap`
> still requires me to write both member-`swap` and non-member `swap`
> functions (since you said `std::swap` should use ADL to find the right
> `swap` function). ADL-based customization points require lots of needless
> repetition.
>
> One of the main purposes of UCS in this regard is to promote DRY
> principles: you write *one function*. You choose for yourself whether it
> is a member or non-member function, based on your needs. And the user has=
 a
> way to call it, regardless of how you choose to expose it.
>
> Or do you really like writing the 12 functions it takes to make a proper
> ADL-based container class
> <http://stackoverflow.com/questions/39231664/what-is-the-preferred-way-to=
-expose-custom-stl-style-iteration>
> ?
>
> --
> 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/fb3436c7-1d7b-478f-
> b476-50f2a2ef09eb%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fb3436c7-1d=
7b-478f-b476-50f2a2ef09eb%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/CAOfiQqnP7mrFLBo1z7ck-dSUvxh9nCpZzYTjAMv05QuEcQX=
O%3Dw%40mail.gmail.com.

--001a1148f9f0b669af054586f7d6
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 7=
 January 2017 at 09:30, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto=
:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Thursday, Janu=
ary 5, 2017 at 4:42:20 PM UTC-5, Arthur O&#39;Dwyer wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">On Wed, Jan 4, 2017 at 7:55 PM, Ric=
hard Smith <span dir=3D"ltr">&lt;<a rel=3D"nofollow">ric...@metafoo.co.uk</=
a>&gt;</span> wrote:<span class=3D""><br><div><div class=3D"gmail_quote"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quot=
e"><div><div>On 4 January 2017 at 19:14, Nicol Bolas <span dir=3D"ltr">&lt;=
<a rel=3D"nofollow">jmck...@gmail.com</a>&gt;</span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">On Wednesday, Januar=
y 4, 2017 at 3:49:00 PM UTC-5, Jens Maurer wrote:<div><div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex"><br>Sometimes, a feature is discussed and=
 progressed, but a substantial part
<br>of the committee has sustained reservations against the shape of the
<br>feature, thus failing to achieve consensus.=C2=A0 This happened with de=
faulted
<br>comparison operators (until now) and unified call syntax.<br></blockquo=
te></div></div><div><br>I think these are probably my biggest concerns, in =
terms of standardization. Particularly for UCS.<br><br>I say that because, =
while the &quot;sustained reservation&quot; people may have a point, that p=
oint cannot change the fact that <i>we need UCS</i>. One form, the other, o=
r both. But this is functionality that we as C++ users absolutely need.<br>=
</div></div></blockquote><div><br></div></div></div><div>The people with su=
stained reservations obviously disagree, or at least think the harm this fe=
ature does to the language outweighs the benefit. And the current levels of=
 adoption of the standard clearly demonstrate that we do not *need* this fe=
ature, or indeed any feature. It has merit, sure, but that must be weighed =
against other things.</div><span><div><br></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>Every time you have to do `usi=
ng std::swap` before `swap`ing some object, [...]<br></div></div></blockquo=
te><div><br></div></span><div>The counterargument to that is that using unq=
ualified names as extension points is a major mistake that significantly ha=
rms the benefits that namespaces are supposed to provide. ADL for non-opera=
tors is harmful to the language, and UCS makes that harm significantly wors=
e by applying it in more cases.</div><div><br></div><div>The full UCS propo=
sal also makes lots of previously-safe routine library maintenance (such as=
 adding member functions) a potential source-breaking change for API consum=
ers (which might previously have been calling their own declarations of non=
-members via member syntax). The half-UCS approach at least only affects th=
e cases that are already maligned by ADL, but it still has this characteris=
tic that extending a library in natural ways becomes a potentially breaking=
 change for API consumers. We do not need more features in C++ that make it=
 hard to maintain large-scale codebases.</div><div><br></div><div>What we r=
eally *should* add is a language feature that provides support for sane, pr=
incipled, named, scoped extension points. UCS isn&#39;t that.</div></div></=
div></div></blockquote><div><br></div><div>I&#39;ll throw in my two cents. =
From the above it sounds like Richard&#39;s position is roughly &quot;anti-=
UCS, anti-ADL, pro-customization-points&quot;. My own position is roughly &=
quot;anti-UCS, pro-ADL, pro-customization-points.&quot;</div></div></div></=
span></div></blockquote><div><br>From a standardization perspective, this g=
oes back to the P0057 vs. the world issue.<br><br>Namely, a lot of people r=
eally dislike P0057: co_await and its ilk. They think it&#39;s a terrible w=
ay to do async coding, and some of them have experience with similar featur=
es in other languages which create a nightmare of unmaintainable code. All =
of the opponents of P0057 agree that there has to be a better alternative.<=
br><br>The problem is... they don&#39;t know what that is. Nor do they have=
 the resources to actually research it. They can produce a lot of paper, bu=
t none of them have the ability and/or the time to implement these ideas in=
 a compiler. To actually prove that they can work and do the things they sa=
y it can do.<br><br>By contrast, P0057 moves forward because, despite the o=
pposition... it works. It has an implementation in a real compiler. It&#39;=
s something more than just a few sketches of ideas; it&#39;s a firm proposa=
l with both standard wording and a rapidly maturing implementation.<br><br>=
I see UCS in a similar light. There&#39;s opposition to it, but the opposit=
ion doesn&#39;t have any proposals for actually solving any of the problems=
 that UCS solves.<br><br>You talk about customization points. But you have =
no proposals for integrating those into the language, of defining a consist=
ent way for people to write their own. You have no proposals for fixing the=
 problems in the existing customization points in the standard library or a=
dding new ones that lack those problems.<br><br>I do not like P0057. I thin=
k it is a silly, limited feature, and I agree with the arguments that wides=
pread use of it can lead to painful code. But it solves a problem the langu=
age genuinely needs solving. So unless the alternatives can mature into som=
ething more than paper ideas, then despite its problems, I would have to su=
pport P0057 <i>for the good of the language</i>.<br><br>And I feel the same=
 way about UCS. I do not agree with everything in it. But it does solve a s=
ignificant problem the language has. And any potential harm it causes is ba=
sed on potential harm that already exists (re: ADL).</div></div></blockquot=
e><div><br></div><div>That&#39;s not true with the full UCS feature. If I d=
on&#39;t want to use P0057, I don&#39;t use it, and move on with my life. I=
f I don&#39;t want to use UCS, and I&#39;m a library vendor, I still have t=
o deal with the pain that it imposes on everyone. I can&#39;t add a new mem=
ber function foo to my class without risking breaking people who were using=
 &quot;my_class.foo()&quot; to find a non-member &quot;foo&quot; by UCS.</d=
iv><div><br></div><div>And that&#39;s why there was strong technical opposi=
tion to the full UCS proposal. The half-UCS proposal, as you say, has only =
the same potential problems as ADL (as it only affects the same expressions=
 where ADL would have been performed) -- and indeed I made that point durin=
g discussion in plenary. The technical opposition that seemed to carry the =
room was that a proper UCS proposal should (a) consider members and non-mem=
bers equally, rather than preferring one over the other, (b) not be the def=
ault behavior; calling an extension point is a special exception, not the c=
ommon case, (c) not change the meaning of existing code, and (d) not requir=
e extra lookup and overload resolution cost for every function call. These =
all point to using a new syntax.</div><div><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div>Since C++ needs a solution to those problems=
, unless some other solution arises that also solves them, we should move f=
orward with what we have now for the good of the language.<br></div></div><=
/blockquote><div><br></div><div>Actually, another solution has been propose=
d: use a new syntax, such as swap.(x, y), to express a UDL call. (This mean=
s that extension point names can&#39;t be meaningfully namespaced, but mayb=
e that&#39;s OK, since they should be rare.)</div><div><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr"><div>These kinds of problem-based com=
promises are the sorts of things that I feel are lacking from the committee=
 at this time. The recognition that C++ really needs something to deal with=
 X, and proposal Y deals with X, so unless there is a proposal Z that also =
solves X, then you should support Y.<br></div></div></blockquote><div><br><=
/div><div>You are assuming that there is consensus that C++ needs to deal w=
ith X in this case. I do not think there is.</div><div><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr"><div>I know that sounds ironic, consi=
dering my opposition to Concepts TS integration into C++17. But that&#39;s =
because I feel the proposal hasn&#39;t cooked enough yet, that it needs ref=
actoring. Not because I&#39;m opposed to it on a fundamental level.<br><br>=
</div><span class=3D""><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 class=3D"gmail_quote"><div></div><div>I <i>love</i> ADL. It =
seems very straightforward to me; I believe I understand it; I appreciate t=
hat it makes operator overloading Just Work (and keeps plain old functions =
working the same way as operator functions, by applying the same ADL rules =
to both). I appreciate that in C++98 it allowed us to reach into other name=
spaces to implement customization points like &#39;swap&#39;=C2=A0<i>at all=
</i>, even though I believe that we have learned a lot about <i>better</i> =
interfaces for customization points in the intervening ~20 years.</div></di=
v></div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div>=C2=A0</div></blockquote><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote"><div>For me, ADL is &quot;jus=
t confusing enough&quot;. Adding UCS to the mix would make the situation <i=
>so much more confusing</i> that I think I would be unhappy with it. (Simil=
arly, I think I am unhappy with class template constructor type deduction i=
n C++17.) =C2=A0And what&#39;s the point of UCS? Just to allow one syntax t=
o &quot;do everything&quot;?=C2=A0 I <i>like</i> having different syntaxes =
for different purposes =E2=80=94 having code-that-does-X look fundamentally=
 different from code-that-does-Y.</div></div></div></div></blockquote></spa=
n><div><br>The problem with this kind of thinking is that it encourages the=
 proliferation of syntaxes for doing the same thing, but in ways whose diff=
erences are things that only experts know about. Because at the end of the =
day, most users do not want to, or <i>need to</i>, think about the distinct=
ion between member call and non-member call.<br><br></div><span class=3D"">=
<blockquote 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"><div>Re customization points, I would love it if std::swap(x,=
y) just Did The Right Thing for any x and y (by hiding the ADL inside itsel=
f). But adding UCS won&#39;t help with that problem at all.</div></div></di=
v></div></blockquote></span><div><br>UCS doesn&#39;t solve the problem of w=
riting a `std::swap` that calls the right function. But that&#39;s not its =
goal. Its goal is to let `swap(x, y)` <i>by itself</i> call the right funct=
ion, to bypass `std::swap` entirely.<br><br>UCS helps with customization po=
ints by <i>making them obsolete</i> ;)<br></div></div></blockquote><div><br=
></div><div>To the extent it does that, it also destroys the benefits of na=
mespaces.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div>It should also be noted that your &quot;Did The Right Thing&quot; f=
or `std::swap` still requires me to write both member-`swap` and non-member=
 `swap` functions (since you said `std::swap` should use ADL to find the ri=
ght `swap` function). ADL-based customization points require lots of needle=
ss repetition.<br><br>One of the main purposes of UCS in this regard is to =
promote DRY principles: you write <i>one function</i>. You choose for yours=
elf whether it is a member or non-member function, based on your needs. And=
 the user has a way to call it, regardless of how you choose to expose it.<=
br><br>Or do you really like writing <a href=3D"http://stackoverflow.com/qu=
estions/39231664/what-is-the-preferred-way-to-expose-custom-stl-style-itera=
tion" target=3D"_blank">the 12 functions it takes to make a proper ADL-base=
d container class</a>?</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/fb3436c7-1d7b-478f-b476-50f2a2ef09eb%=
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/fb34=
36c7-1d7b-478f-<wbr>b476-50f2a2ef09eb%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></div>

<p></p>

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

--001a1148f9f0b669af054586f7d6--

.

On 07/01/2017 18:30, Nicol Bolas wrote:

> The problem with this kind of thinking is that it encourages the
> proliferation of syntaxes for doing the same thing, but in ways whose
> differences are things that only experts know about. Because at the end
> of the day, most users do not want to, or /need to/, think about the
> distinction between member call and non-member call.

I do not agree. Defining the interface of a class is an important
decision. A member call syntax is an important message to the code
reader, (s)he knows where the function declaration is (usually in the
corresponding .h header), it that function can be virtual or not, etc.
It makes code more readable and maintanable, IMHO.

When the reader sees a free function, then he/she knows that function
(except for swap or other well-known operators) is not part of the
interface the class designer defined.

If we have problems with customization points, then universal UCS is too
general. To fix customization points we only need a special call to
explicitly state we are calling a function using non-usual rules (maybe
"unifies" as it could target member and non-member functions). That
would be backwards compatible and explicit (which means easy
understanding and increased safety).

> It should also be noted that your "Did The Right Thing" for `std::swap`
> still requires me to write both member-`swap` and non-member `swap`
> functions (since you said `std::swap` should use ADL to find the right
> `swap` function). ADL-based customization points require lots of
> needless repetition.

True. But I don't think this repetition is a huge problem in the
language, and different solutions could be developed just to simplify
that duplication without UCS.

> One of the main purposes of UCS in this regard is to promote DRY
> principles: you write /one function/. You choose for yourself whether it
> is a member or non-member function, based on your needs. And the user
> has a way to call it, regardless of how you choose to expose it.
>
> Or do you really like writing the 12 functions it takes to make a proper
> ADL-based container class
> <http://stackoverflow.com/questions/39231664/what-is-the-preferred-way-to-expose-custom-stl-style-iteration>?

The problem is not in the writer, but in the caller. The writer has
already chosen the most appropriate signature.

The caller does not want to limit the customization point to a concrete
syntax, s(he) wants to try several options, until a viable function is
found. In that case, I'd like to explicitly state there is a
customization point, with unusual but well-known lookup rules, so that
any reviewer knows what code is doing:

template<class ForwardIt1, class ForwardIt2>
ForwardIt2 swap_ranges(ForwardIt1 first1,
                              ForwardIt1 last1,
                              ForwardIt2 first2)
{
     while (first1 != last1) {
         //Call (*first1).swap(*first2) if it exists and its viable,
 //swap(*first1, *first2) otherwise
         [[customization_point]] swap(*first1, *first2);
         ++first1;
         ++first2;
     }
     return first2;
}

[[customization_point]] is not a proposal, just wanted to make the
customization point more visible. A shorter syntax could also work,
although it could be easy to miss (e.g. "swap::(a, b)", "swap->(a, b)",
"swap.(a,b)", ...)

Best,

Ion

--
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/066fe6fb-7031-b866-6e4e-5cdea4122112%40gmail.com.

.

------=_Part_498_817057938.1483887835958
Content-Type: multipart/alternative;
 boundary="----=_Part_499_1074548096.1483887835958"

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

On Saturday, January 7, 2017 at 3:58:06 PM UTC-5, Ion Gazta=C3=B1aga wrote:
>
> On 07/01/2017 18:30, Nicol Bolas wrote:=20
>
> > The problem with this kind of thinking is that it encourages the=20
> > proliferation of syntaxes for doing the same thing, but in ways whose=
=20
> > differences are things that only experts know about. Because at the end=
=20
> > of the day, most users do not want to, or /need to/, think about the=20
> > distinction between member call and non-member call.=20
>
> I do not agree. Defining the interface of a class is an important=20
> decision. A member call syntax is an important message to the code=20
> reader, (s)he knows where the function declaration is (usually in the=20
> corresponding .h header), it that function can be virtual or not, etc.=20
> It makes code more readable and maintanable, IMHO.=20
>
> When the reader sees a free function, then he/she knows that function=20
> (except for swap or other well-known operators) is not part of the=20
> interface the class designer defined.
>

No, it's not a member of that class. But there are *plenty* of non-member=
=20
functions that effectively form the interface to the class, and the class=
=20
designer frequently has a hand in them. Non-member functions are the only=
=20
way to build on the interface of a class you don't control. Indeed, we have=
=20
lots of people out there telling users to only make a function a member if=
=20
it is *essential* to the class; otherwise, it should be a non-member=20
function.

Furthermore, why does the user *care* what "the class designer defined"? I=
=20
don't think the user really does. It doesn't matter if the class designer=
=20
implemented member `begin/end` iterators, or that someone else came along=
=20
and forced the container to abide by standard conventions. What matters to=
=20
the user is that they can do this:

for(auto &val : your_container)

Whether "the class designer" got involved in that process or not is=20
irrelevant.

If we have problems with customization points, then universal UCS is too=20
> general. To fix customization points we only need a special call to=20
> explicitly state we are calling a function using non-usual rules (maybe=
=20
> "unifies" as it could target member and non-member functions). That=20
> would be backwards compatible and explicit (which means easy=20
> understanding and increased safety).=20
>
> > It should also be noted that your "Did The Right Thing" for `std::swap`=
=20
> > still requires me to write both member-`swap` and non-member `swap`=20
> > functions (since you said `std::swap` should use ADL to find the right=
=20
> > `swap` function). ADL-based customization points require lots of=20
> > needless repetition.=20
>
> True. But I don't think this repetition is a huge problem in the=20
> language, and different solutions could be developed just to simplify=20
> that duplication without UCS.=20
>
> > One of the main purposes of UCS in this regard is to promote DRY=20
> > principles: you write /one function/. You choose for yourself whether i=
t=20
> > is a member or non-member function, based on your needs. And the user=
=20
> > has a way to call it, regardless of how you choose to expose it.=20
> >=20
> > Or do you really like writing the 12 functions it takes to make a prope=
r=20
> > ADL-based container class=20
> > <
> http://stackoverflow.com/questions/39231664/what-is-the-preferred-way-to-=
expose-custom-stl-style-iteration>?=20
>
>
> The problem is not in the writer, but in the caller. The writer has=20
> already chosen the most appropriate signature.
>

Then you're not really understanding the purpose of these customization=20
points.

Let's take a container class that already exists. It's perfectly valid,=20
functional, and useful. However, there's just one problem: it doesn't fit=
=20
C++'s standard library requirements for containers. It's not a proper range=
=20
or anything. Also, you are not in control of the class's implementation, so=
=20
you cannot simply give it a standard library interface.

So what do you do? You give it non-member functions that mirror the=20
appearance of the standard library containers. This is the *whole point* of=
=20
having customization points.

The writer did not choose "the most appropriate signature"; the writer=20
choose the *only signature available*.

The problem is this: they're non-member functions. So you have to call them=
=20
like non-member functions. But if you're writing code that expects member=
=20
functions, you have to call them like member functions. Your supposedly=20
generic code now has to make a decision: member call or non-member call.

The purpose of the std::non_member functions (besides `std::swap`) is to=20
convert a non-member call into a member call for containers that don't have=
=20
non-member functions. So you do `using std::begin; begin(X);` If X has a=20
non-member one that can be found via ADL, then it will call that.=20
Otherwise, it'll find `std::begin`, which will call `X`'s member `begin`.=
=20
And if it doesn't have one, you get a compile error.

But if you're writing a class from scratch, adding both member and=20
non-member `begin` is a big pain. So you're hoping that the caller=20
remembers the `using std::begin;` trick, which has to be learned=20
idiomatically.

UCS allows the caller to just use `begin(X)` and not have to worry about it=
..

The caller does not want to limit the customization point to a concrete=20
> syntax, s(he) wants to try several options, until a viable function is=20
> found. In that case, I'd like to explicitly state there is a=20
> customization point, with unusual but well-known lookup rules, so that=20
> any reviewer knows what code is doing:
>

Why should such lookup rules be "unusual"?
=20

> template<class ForwardIt1, class ForwardIt2>=20
> ForwardIt2 swap_ranges(ForwardIt1 first1,=20
>                               ForwardIt1 last1,=20
>                               ForwardIt2 first2)=20
> {=20
>      while (first1 !=3D last1) {=20
>          //Call (*first1).swap(*first2) if it exists and its viable,=20
>         //swap(*first1, *first2) otherwise=20
>          [[customization_point]] swap(*first1, *first2);=20
>          ++first1;=20
>          ++first2;=20
>      }=20
>      return first2;=20
> }=20
>
> [[customization_point]] is not a proposal, just wanted to make the=20
> customization point more visible. A shorter syntax could also work,=20
> although it could be easy to miss (e.g. "swap::(a, b)", "swap->(a, b)",=
=20
> "swap.(a,b)", ...)
>

Here's something I don't understand about the "lets use a special call=20
syntax" idea. You believe that we cannot use existing non-member call=20
syntax to invoke UCS, because if we did, it would cause unmaintainability=
=20
problems. Not that it would break existing code (it won't); it would simply=
=20
inhibit the ability of people to maintain their code.

Well... if you give people a specific syntax to invoke UCS, this only helps=
=20
maintainability if you assume that *nobody is using it*. Otherwise, it=20
still has all the same problems you claim that UCS does, where adding a new=
=20
function can change the meaning of code.

--=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/1cdf7d0e-0445-41b8-aa01-a626c3f79e78%40isocpp.or=
g.

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

<div dir=3D"ltr">On Saturday, January 7, 2017 at 3:58:06 PM UTC-5, Ion Gazt=
a=C3=B1aga wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 07/01/2017=
 18:30, Nicol Bolas wrote:
<br>
<br>&gt; The problem with this kind of thinking is that it encourages the
<br>&gt; proliferation of syntaxes for doing the same thing, but in ways wh=
ose
<br>&gt; differences are things that only experts know about. Because at th=
e end
<br>&gt; of the day, most users do not want to, or /need to/, think about t=
he
<br>&gt; distinction between member call and non-member call.
<br>
<br>I do not agree. Defining the interface of a class is an important=20
<br>decision. A member call syntax is an important message to the code=20
<br>reader, (s)he knows where the function declaration is (usually in the=
=20
<br>corresponding .h header), it that function can be virtual or not, etc.=
=20
<br>It makes code more readable and maintanable, IMHO.
<br>
<br>When the reader sees a free function, then he/she knows that function=
=20
<br>(except for swap or other well-known operators) is not part of the=20
<br>interface the class designer defined.<br></blockquote><div><br>No, it&#=
39;s not a member of that class. But there are <i>plenty</i> of non-member =
functions that effectively form the interface to the class, and the class d=
esigner frequently has a hand in them. Non-member functions are the only wa=
y to build on the interface of a class you don&#39;t control. Indeed, we ha=
ve lots of people out there telling users to only make a function a member =
if it is <i>essential</i> to the class; otherwise, it should be a non-membe=
r function.<br><br>Furthermore, why does the user <i>care</i> what &quot;th=
e class designer defined&quot;? I don&#39;t think the user really does. It =
doesn&#39;t matter if the class designer implemented member `begin/end` ite=
rators, or that someone else came along and forced the container to abide b=
y standard conventions. What matters to the user is that they can do this:<=
br><br><div style=3D"background-color: rgb(250, 250, 250); border-color: rg=
b(187, 187, 187); border-style: solid; border-width: 1px; overflow-wrap: br=
eak-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"=
subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">f=
or</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">val </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> your_container</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br></span></div></code></div><br>Whether &quot;the cla=
ss designer&quot; got involved in that process or not is irrelevant.<br><br=
></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
If we have problems with customization points, then universal UCS is too=20
<br>general. To fix customization points we only need a special call to=20
<br>explicitly state we are calling a function using non-usual rules (maybe=
=20
<br>&quot;unifies&quot; as it could target member and non-member functions)=
.. That=20
<br>would be backwards compatible and explicit (which means easy=20
<br>understanding and increased safety).
<br>
<br>&gt; It should also be noted that your &quot;Did The Right Thing&quot; =
for `std::swap`
<br>&gt; still requires me to write both member-`swap` and non-member `swap=
`
<br>&gt; functions (since you said `std::swap` should use ADL to find the r=
ight
<br>&gt; `swap` function). ADL-based customization points require lots of
<br>&gt; needless repetition.
<br>
<br>True. But I don&#39;t think this repetition is a huge problem in the=20
<br>language, and different solutions could be developed just to simplify=
=20
<br>that duplication without UCS.
<br>
<br>&gt; One of the main purposes of UCS in this regard is to promote DRY
<br>&gt; principles: you write /one function/. You choose for yourself whet=
her it
<br>&gt; is a member or non-member function, based on your needs. And the u=
ser
<br>&gt; has a way to call it, regardless of how you choose to expose it.
<br>&gt;
<br>&gt; Or do you really like writing the 12 functions it takes to make a =
proper
<br>&gt; ADL-based container class
<br>&gt; &lt;<a href=3D"http://stackoverflow.com/questions/39231664/what-is=
-the-preferred-way-to-expose-custom-stl-style-iteration" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?=
q\x3dhttp%3A%2F%2Fstackoverflow.com%2Fquestions%2F39231664%2Fwhat-is-the-pr=
eferred-way-to-expose-custom-stl-style-iteration\x26sa\x3dD\x26sntz\x3d1\x2=
6usg\x3dAFQjCNFSNHVhmyqOA2blskEArLI-CbIgVQ&#39;;return true;" onclick=3D"th=
is.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fstackoverflow.co=
m%2Fquestions%2F39231664%2Fwhat-is-the-preferred-way-to-expose-custom-stl-s=
tyle-iteration\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFSNHVhmyqOA2blskEArL=
I-CbIgVQ&#39;;return true;">http://stackoverflow.com/<wbr>questions/3923166=
4/what-is-<wbr>the-preferred-way-to-expose-<wbr>custom-stl-style-iteration<=
/a>&gt;?
<br>
<br>The problem is not in the writer, but in the caller. The writer has=20
<br>already chosen the most appropriate signature.<br></blockquote><div><br=
>Then you&#39;re not really understanding the purpose of these customizatio=
n points.<br><br>Let&#39;s take a container class that already exists. It&#=
39;s perfectly valid, functional, and useful. However, there&#39;s just one=
 problem: it doesn&#39;t fit C++&#39;s standard library requirements for co=
ntainers. It&#39;s not a proper range or anything. Also, you are not in con=
trol of the class&#39;s implementation, so you cannot simply give it a stan=
dard library interface.<br><br>So what do you do? You give it non-member fu=
nctions that mirror the appearance of the standard library containers. This=
 is the <i>whole point</i> of having customization points.<br><br>The write=
r did not choose &quot;the most appropriate signature&quot;; the writer cho=
ose the <i>only signature available</i>.<br><br>The problem is this: they&#=
39;re non-member functions. So you have to call them like non-member functi=
ons. But if you&#39;re writing code that expects member functions, you have=
 to call them like member functions. Your supposedly generic code now has t=
o make a decision: member call or non-member call.<br><br>The purpose of th=
e std::non_member functions (besides `std::swap`) is to convert a non-membe=
r call into a member call for containers that don&#39;t have non-member fun=
ctions. So you do `using std::begin; begin(X);` If X has a non-member one t=
hat can be found via ADL, then it will call that. Otherwise, it&#39;ll find=
 `std::begin`, which will call `X`&#39;s member `begin`. And if it doesn&#3=
9;t have one, you get a compile error.<br><br>But if you&#39;re writing a c=
lass from scratch, adding both member and non-member `begin` is a big pain.=
 So you&#39;re hoping that the caller remembers the `using std::begin;` tri=
ck, which has to be learned idiomatically.<br><br>UCS allows the caller to =
just use `begin(X)` and not have to worry about it.<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;">
The caller does not want to limit the customization point to a concrete=20
<br>syntax, s(he) wants to try several options, until a viable function is=
=20
<br>found. In that case, I&#39;d like to explicitly state there is a=20
<br>customization point, with unusual but well-known lookup rules, so that=
=20
<br>any reviewer knows what code is doing:<br></blockquote><div><br>Why sho=
uld such lookup rules be &quot;unusual&quot;?<br>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;">
template&lt;class ForwardIt1, class ForwardIt2&gt;
<br>ForwardIt2 swap_ranges(ForwardIt1 first1,
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ForwardIt1 last1,
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ForwardIt2 first2)
<br>{
<br>=C2=A0 =C2=A0 =C2=A0while (first1 !=3D last1) {
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0//Call (*first1).swap(*first2) if it =
exists and its viable,
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0//swap(*first1, *first2=
) otherwise
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[[customization_point]] swap(*first1,=
 *first2);
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0++first1;
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0++first2;
<br>=C2=A0 =C2=A0 =C2=A0}
<br>=C2=A0 =C2=A0 =C2=A0return first2;
<br>}
<br>
<br>[[customization_point]] is not a proposal, just wanted to make the=20
<br>customization point more visible. A shorter syntax could also work,=20
<br>although it could be easy to miss (e.g. &quot;swap::(a, b)&quot;, &quot=
;swap-&gt;(a, b)&quot;,
<br>&quot;swap.(a,b)&quot;, ...)<br></blockquote><div><br>Here&#39;s someth=
ing I don&#39;t understand about the &quot;lets use a special call syntax&q=
uot; idea. You believe that we cannot use existing non-member call syntax t=
o invoke UCS, because if we did, it would cause unmaintainability problems.=
 Not that it would break existing code (it won&#39;t); it would simply inhi=
bit the ability of people to maintain their code.<br><br>Well... if you giv=
e people a specific syntax to invoke UCS, this only helps maintainability i=
f you assume that <i>nobody is using it</i>. Otherwise, it still has all th=
e same problems you claim that UCS does, where adding a new function can ch=
ange the meaning of code.<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/1cdf7d0e-0445-41b8-aa01-a626c3f79e78%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1cdf7d0e-0445-41b8-aa01-a626c3f79e78=
%40isocpp.org</a>.<br />

------=_Part_499_1074548096.1483887835958--

------=_Part_498_817057938.1483887835958--

.

Le 07/01/2017 =C3=A0 21:17, Jens Maurer a =C3=A9crit :
> On 01/07/2017 06:30 PM, Nicol Bolas wrote:
>
>
>
>> I see UCS in a similar light. There's opposition to it, but the oppositi=
on doesn't have any proposals for actually solving any of the problems that=
 UCS solves.
> Sure; see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0301r1=
..html.
> This went down in EWG in Oulu.
Thanks for the pointer, I missed this paper. I was not expecting a paper=20
named Wording ... to include a proposal change :)

Vicente

--=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/408e2cf3-4799-711d-219c-2050fa1802e1%40wanadoo.f=
r.

.

Hi Nicol,

On 08/01/2017 16:03, Nicol Bolas wrote:
>
> No, it's not a member of that class. But there are /plenty/ of
> non-member functions that effectively form the interface to the class,
> and the class designer frequently has a hand in them. Non-member
> functions are the only way to build on the interface of a class you
> don't control. Indeed, we have lots of people out there telling users to
> only make a function a member if it is /essential/ to the class;
> otherwise, it should be a non-member function.

Maybe we are calling the same thing with different names. We shouldn't
modify the "interface" of an existing class. Another user can add
another extension and then when both extensions are used together
problems arise. The designer of the class has also designed the proper
use mode, the interface. You can add begin(object), another user adds
also begin(object) with a different meaning and now the interface of the
class is a mess. There are options to extend the "interface" of a class,
e.g. creating a new class, derivation, encapsulation. I think what you
call "extended interface" is what I call "adaptors".

> Furthermore, why does the user /care/ what "the class designer defined"?
> I don't think the user really does. It doesn't matter if the class
> designer implemented member `begin/end` iterators, or that someone else
> came along and forced the container to abide by standard conventions.
> What matters to the user is that they can do this:

But the added begin() is not the interface of the class, it's
technically an "adaptor" in order to match a class with the "standard"
customization point. The designer of the algorithm designs the
customization point, the designer of the class designs the class'
interface. If both don't agree, we need an adaptor. begin()/end()/swap()
are not the only customization points, any algorithm or class designer
can invent new ones. We shouldn't add those calls to the "official class
interface".

> for(auto&val :your_container)
> |
>
> Whether "the class designer" got involved in that process or not is
> irrelevant.

The class designer might have designed container.start(), but the
language construct requires a free function call with a different name
(say, "begin(c)"), so an adaptor is needed. (Off-topic: we require a
free function because built-in arrays don't have member functions, the
language could have made an extension and make array.begin() well
formed). The adaptor is not the interface of the class, it's a glue code
to connect the required customization point with the class interface.

Free/Member function calls are not the only customization point, we have
virtual calls calling a registered abstract base pointer, we have
virtual calls to derived classes to reuse code of base classes, we have
link-time bindings and dynamic load libraries, etc.... All of them need
adaptation code to connect a class interface with the customization
point (wrapping the class in a new one that derives from the interface,
wrapping it with another that exports, symbols, etc...)

> Then you're not really understanding the purpose of these customization
> points.
>
> Let's take a container class that already exists. It's perfectly valid,
> functional, and useful. However, there's just one problem: it doesn't
> fit C++'s standard library requirements for containers. It's not a
> proper range or anything. Also, you are not in control of the class's
> implementation, so you cannot simply give it a standard library interface.

So you need an adaptor, that should not collide with an adaptor another
user needs.

> So what do you do? You give it non-member functions that mirror the
> appearance of the standard library containers. This is the /whole point/
> of having customization points.

Standard library "adaptors" (begin, end, swap, operator*(), ...) are the
easy part, and they could be added to many classes, but then we have
millions of customization points in user code that require different
names and signatures. UCS won't help us with these.

> But if you're writing a class from scratch, adding both member and
> non-member `begin` is a big pain. So you're hoping that the caller
> remembers the `using std::begin;` trick, which has to be learned
> idiomatically.
>
> UCS allows the caller to just use `begin(X)` and not have to worry about it.

Sure, but that only solves the problem of member vs non-member problem,
it does not solve other differences like the name of the function. UCS
eases customization points if the only difference is member vs.
nonmember. And to solve this, UCS is a giant hammer, as it opens the
door to less maintainable code in non-customization points. IMHO, an
explicit syntax serves better: it clearly says: this is a customization
point that expects a member or non-member function called X.

I understand your points, just wanted to expose my fears with a a
generalized use of UCS.

Best,

Ion

--
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/c04334a7-e7e4-61eb-d966-57b42daef36c%40gmail.com.

.

------=_Part_256_383846735.1484981990621
Content-Type: multipart/alternative;
 boundary="----=_Part_257_742412991.1484981990621"

------=_Part_257_742412991.1484981990621
Content-Type: text/plain; charset=UTF-8

I don't believe it is in C++14 or C++17, issue 727 is open (see here
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#727), I think
we need a proposal with the wording

On Wednesday, June 12, 2013 at 12:13:17 PM UTC-7, Nicol Bolas wrote:
>
> On Wednesday, June 12, 2013 11:43:22 AM UTC-7, faisalv wrote:
>>
>> I can not comment on whether it was originally an oversight, but having
>> proposed it to be changed, and being in the room when EWG approved the
>> change this past meeting - (and assuming my memory is serving me well), I
>> can tell you no one who was present had a good reason for why it was as it
>> was.  Let us see what happens in core.
>>
>>
>> Faisal Vali
>>
>
> So... this has already been fixed for C++14 (modulo not being able to do
> partial specialization on functions, which would be a far less trivial
> request).
>
> That's my fault for assuming a guy who named his thread "TOTAL
> RETARDATION" knew what he was talking about.
>
>

--
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/793ad886-efe4-45c1-839f-278a156adc7e%40isocpp.org.

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

<div dir=3D"ltr">I don&#39;t believe it is in C++14 or C++17, issue 727 is =
open (see here http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#=
727), I think we need a proposal with the wording<br><br>On Wednesday, June=
 12, 2013 at 12:13:17 PM UTC-7, Nicol Bolas wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;">On Wednesday, June 12, 2013 11:43:22 AM UTC-7, faisalv =
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 can not co=
mment on whether it was originally an oversight, but having proposed it to =
be changed, and being in the room when EWG approved the change this past me=
eting - (and assuming my memory is serving me well), I can tell you no one =
who was present had a good reason for why it was as it was.=C2=A0 Let us se=
e what happens in core.<br>
<br></div><div><br clear=3D"all"><div>Faisal Vali<br></div></div></blockquo=
te><div><br>So... this has already been fixed for C++14 (modulo not being a=
ble to do partial specialization on functions, which would be a far less tr=
ivial request).<br><br>That&#39;s my fault for assuming a guy who named his=
 thread &quot;TOTAL RETARDATION&quot; knew what he was talking about.</div>=
<br></blockquote></div>

<p></p>

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

------=_Part_257_742412991.1484981990621--

------=_Part_256_383846735.1484981990621--

.

------=_Part_1702_2029235540.1485812440670
Content-Type: multipart/alternative;
 boundary="----=_Part_1703_1480828287.1485812440670"

------=_Part_1703_1480828287.1485812440670
Content-Type: text/plain; charset=UTF-8

Holy shit, you guys are pretentious. Why don't you just man up and deal
with it? He very obviously doesn't expect you to listen to him no matter
what he does. Why do you think he's swearing at you in caps? You're just a
brick wall with a sensitive ego.

On Thursday, 11 August 2016 14:09:26 UTC+1, D. B. wrote:
>
> Get a load of this guy, who somehow thinks repeatedly insulting people
> somehow makes them *more* likely to listen to him.
>
> Recommend immediate address and IP block. No point even responding.
>
>

--
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/22d4cfb3-e20f-4650-8596-8dbf26e9947e%40isocpp.org.

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

<div dir=3D"ltr">Holy shit, you guys are pretentious. Why don&#39;t you jus=
t man up and deal with it? He very obviously doesn&#39;t expect you to list=
en to him no matter what he does. Why do you think he&#39;s swearing at you=
 in caps? You&#39;re just a brick wall with a sensitive ego.<br><br>On Thur=
sday, 11 August 2016 14:09:26 UTC+1, D. B.  wrote:<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>Get a load of this guy, who someh=
ow thinks repeatedly insulting people somehow makes them <i>more</i> likely=
 to listen to him.<br><br></div>Recommend immediate address and IP block. N=
o point even responding.<br><br></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/22d4cfb3-e20f-4650-8596-8dbf26e9947e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/22d4cfb3-e20f-4650-8596-8dbf26e9947e=
%40isocpp.org</a>.<br />

------=_Part_1703_1480828287.1485812440670--

------=_Part_1702_2029235540.1485812440670--

.