TOTAL RETARDATION in C++

[looseont...@gmail.com]

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?

[DeadMG]

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

[Ville Voutilainen]

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 those things.

Such changes have thus far been of low priority. I don't expect lunatic raving to have
an improving effect on that.

[looseont...@gmail.com]

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?

[looseont...@gmail.com]

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

[Jonathan Wakely]

Got it.  I'll start right away.

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

 

[Ville Voutilainen]

On 12 June 2013 13:53, Jonathan Wakely <c...@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.

[looseont...@gmail.com]

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

[Ville Voutilainen]

On 12 June 2013 13:59, <looseont...@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.

[DeadMG]

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

[Fernando Cacciola]

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

[louf...@gmail.com]

I thought partial function specialization was added already? 

[Daniel Krügler]

2013/6/12 <louf...@gmail.com>:

> Le mercredi 12 juin 2013 11:07:28 UTC+2, Ville Voutilainen a écrit :
> I thought partial function specialization was added already?

You are misinformed.

- Daniel

[VinceRev]

With type_traits and SFINAE you can easily emulate partial specialization with no fundamental problem :
-------------------------------------------------------
#include <iostream>
#include <type_traits>
struct S {
    template <class X, class = typename std::enable_if<!std::is_same<X, int>::value>::type> void f()
    {std::cout<<"not int"<<std::endl;}
    template <class X, class = typename std::enable_if<std::is_same<X, int>::value>::type, class = 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 to satisfy hundreds of thousands of programmers. So if you have a proposition to make, write a clear proposal in order to have a basis for further discussions.

Vincent

[Nicol Bolas]

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?

[Faisal Vali]

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 <jmck...@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-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
 
 

[Richard Smith]

On Wed, Jun 12, 2013 at 11:43 AM, Faisal Vali <fai...@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.

[Nicol Bolas]

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.

[stevenaw...@gmail.com]

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.

[pho...@gmail.com]

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.

[looseont...@gmail.com]

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

[Ville Voutilainen]

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

No.

[D. B.]

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.

[Faisal Vali]

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-proposal...@isocpp.org.
> To post to this group, send email to std-pr...@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.

[Victor Dyachenko]

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 Smith]

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.

[Victor Dyachenko]

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?

[Faisal Vali]

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-proposal...@isocpp.org.
> To post to this group, send email to std-pr...@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.

[Faisal Vali]

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-proposal...@isocpp.org.
> To post to this group, send email to std-pr...@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.

[Victor Dyachenko]

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(). But in this case context must be embedded to each lambda.

[Matthew Woehlke]

On 2016-08-11 10:03, Faisal Vali wrote:
> On 11 August 2016 at 16:02, <looseont...@gmail.com> wrote:
>> Is even ANY of this retardation fixed in C++17?
>

> 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 ;)

I found the OP's tone *extremely* motivating. It motivated me to not
even attempt to read whatever he was trying to say ;-).

If someone can't be bothered to be at least marginally polite, I can't
be bothered to listen to them. I'm sure I'm not the only person that
feels that way.

> 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

PDNFTT? ;-)

(It's also interesting to note that on a forum where many people use
their real names, the OP only uses a screen name...)

--
Matthew

[Patrice Roy]

I, for one, absolutely loved Ville's clear, concise answer. Could not be more appropriate.

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.

To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.

To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/noi1e5%24hbk%241%40blaine.gmane.org.

[Casey Carter]

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(). 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);
}

[Casey Carter]

*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.

[Victor Dyachenko]

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.

[looseont...@gmail.com]

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....

[D. B.]

@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.

[Arthur Tchaikovsky]

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. <db0...@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-pr...@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.

--

Yours sincerely
Artur Czajkowski

[Robert Ramey]

On 8/11/16 6:02 AM, looseont...@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

[Nicol Bolas]

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.

[ionto...@gmail.com]

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> {};

[Arthur Tchaikovsky]

@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.

--

You received this message because you are 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-pr...@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.

[Peter Koch Larsen]

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

>> email to std-proposal...@isocpp.org.

>> To post to this group, send email to std-pr...@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-proposal...@isocpp.org.

> To post to this group, send email to std-pr...@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.

[Arthur Tchaikovsky]

@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

>> email to std-proposals+unsubscribe@isocpp.org.

>> To post to this group, send email to std-pr...@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-pr...@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-pr...@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.

[Thiago Macieira]

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

[Nicol Bolas]

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, 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.

[Bo Persson]

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

[Nicol Bolas]

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.

[Bo Persson]

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

[Richard Smith]

On 3 January 2017 at 01:46, Arthur Tchaikovsky <atch...@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 <jmck...@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-pr...@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-pr...@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.

[Nicol Bolas]

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.

[Jonathan Coe]

On 3 Jan 2017, at 20:13, Nicol Bolas <jmck...@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?

Turning up to meetings is io some value. Providing implementations and usage 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 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-proposal...@isocpp.org.

To post to this group, send email to std-pr...@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.

[Matt Calabrese]

On Tue, Jan 3, 2017 at 3:13 PM, Nicol Bolas <jmck...@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.

[Jens Maurer]

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

[Vicente J. Botet Escriba]

Le 03/01/2017 à 15:49, Nicol Bolas a écrit :

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.

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.

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, ...

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.

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, 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.

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.

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.

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 about the global thread.

[Anthony Hall]

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

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

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

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

-Andy

[Nicol Bolas]

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?

[Ren Industries]

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?

--

You received this message because you are 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-pr...@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.

[Oliver Kowalke]

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.

[Vicente J. Botet Escriba]

Hi Oliver,

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 , ....
Note that there are some of feature in the standard proposed by people 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 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 could try to use the current implementation, make some libraries with it, write a blog about its experience, report issues he could find, ...
The same for other expected features.

Vicente

[Oliver Kowalke]

2017-01-04 8:33 GMT+01:00 Vicente J. Botet Escriba <vicent...@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

[Jens Maurer]

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

[Jens Maurer]

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 <mailto:vicent...@wanadoo.fr>>:

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

[Jens Maurer]

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

[Arthur Tchaikovsky]

>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....@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 <vicent...@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-pr...@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.

[Dietmar Kühl]

> On 4 Jan 2017, at 08:54, Jens Maurer <Jens....@gmx.net> wrote:
> There were several (many) C++ committee meetings where the comparison operators
> 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 out" 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 for change emerges with the positions staying unchanged.

[Jens Maurer]

On 01/04/2017 12:35 PM, Dietmar Kühl wrote:
>> On 4 Jan 2017, at 08:54, Jens Maurer <Jens....@gmx.net> wrote:
>> There were several (many) C++ committee meetings where the comparison operators
>> 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 out" 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".

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 == and != to be default
(opt-out) and < and friends to be opt-in. Arguably, anything that
can be copied has a meaningful ==.

Jens

[m.ce...@gmail.com]

W dniu środa, 4 stycznia 2017 11:42:12 UTC+1 użytkownik Arthur Tchaikovsky napisał:

>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.

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

I think committee should really prioritize its work, esp. on features that should have been there long time ago: modules, reflection and maybe concepts.

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.

Same for reflection and concepts.

If there are no volunteers to work on top prio features, committee should find money from corporate bakers and hire (=force) people to do the job. 

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.

Regards,

Maciej

 

 

On Wed, Jan 4, 2017 at 9:02 AM, Jens Maurer <Jens....@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 <vicent...@wanadoo.fr <mailto:vicent...@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-proposal...@isocpp.org.

To post to this group, send email to std-pr...@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.

[Nicol Bolas]

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.

[Nicol Bolas]

On Wednesday, January 4, 2017 at 9:39:30 AM UTC-5, m.ce...@gmail.com wrote:

W dniu środa, 4 stycznia 2017 11:42:12 UTC+1 użytkownik Arthur Tchaikovsky napisał:

>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.

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

I think committee should really prioritize its work, esp. on features that should have been there long time ago: modules, reflection and maybe concepts.

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.

Same for reflection and concepts.

Yeah, this is what I mean when I talk about proper judgement of the 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 functionality to work on". People have been working on modules. A lot of people have been working on modules. We have two in-progress implementations right now. It even has its own study group.

The same goes for concepts and reflection; both have their own study groups (though the concepts SG doesn'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 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.

These things haven't come to fruition because of people being lazy or lack of prioritization. They've been slow because it is hard. Because these are big, complex things that, unless you'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't mean you got it 100% right; some refactoring and adjustment needs to be taken after you get a proof-of-concept working.

[Bo Persson]

On 2017-01-04 08:05, Oliver Kowalke wrote:
> 2017-01-03 23:39 GMT+01:00 Vicente J. Botet Escriba

> <vicent...@wanadoo.fr <mailto:vicent...@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

[Dietmar Kühl]

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

... and I can tell you what gets prioritized: what is in the interest of people participating and paying for the privilege to do the work. The cost of membership is the marginal, unimportant cost. The time spent working on 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 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 don't buy any argument along the lines of "cannot afford": it is "do not want to afford".

[Oliver Kowalke]

2017-01-04 19:12 GMT+01:00 Bo Persson <b...@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.

[m.ce...@gmail.com]

W dniu środa, 4 stycznia 2017 17:01:20 UTC+1 użytkownik Nicol Bolas napisał:

On Wednesday, January 4, 2017 at 9:39:30 AM UTC-5, m.ce...@gmail.com wrote:

W dniu środa, 4 stycznia 2017 11:42:12 UTC+1 użytkownik Arthur Tchaikovsky napisał:

>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.

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

I think committee should really prioritize its work, esp. on features that should have been there long time ago: modules, reflection and maybe concepts.

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.

Same for reflection and concepts.

Yeah, this is what I mean when I talk about proper judgement of the 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 functionality to work on". People have been working on modules. A lot of people have been working on modules. We have two in-progress 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' working on modules and a decade of time the reason we have no modules support in C++ standard is because 'it is hard'.
I'm following the isocpp forum, website, read most proposals, watch C++ conference videos and follow Clang development mailing lists and really don't see that horde of people working on this feature.
I see mainly Gabriel Dos Reis and Richard Smith - hopefully there are way more people working 'behind the scenes'.
But even if there are, one just cannot excuse lack of this feature for such a long time by saying 'it is hard'. These guys are brilliant engineers, I 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 - resources, planning and decision making.
Maybe 'management' part got better in recent years, but all the previous years are lost.
People are just tired of hearing yet again that we won't have modules, reflection or concept in next C++ version, and that's why (at least 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 their own lives - i.e. there doesn't seem to be any push from 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 C++ near future. All I see is status reports on specific proposals/features. Bjarne 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 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.

 

[Jens Maurer]

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.

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

[arthur...@mixpanel.com]

On Wednesday, January 4, 2017 at 5:35:43 AM UTC-8, Jens Maurer wrote:

On 01/04/2017 12:35 PM, Dietmar Kühl wrote:
>> On 4 Jan 2017, at 08:54, Jens Maurer <Jens....@gmx.net> wrote:
>> There were several (many) C++ committee meetings where the comparison operators
>> were discussed, sometimes (it seems to me) not loop-free.

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

This is a total derailment, but if ever a thread was made to be derailed, this thread would be it. ;)

I will gladly take the other side of that "arguably", if anyone ever wants to argue about it. Namely, IEEE `float` and `double` are copiable but copies are not always == to each other.

    double nan = std::nan(nullptr);

    double other_nan = nan;  // make a "copy"

    assert(!(nan == other_nan));  // the copies are not == to each other

Philosophically this is fine; we just say that IEEE `float` and `double` 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 have to deal with really awkward cases like

    struct S { double x, y; };  // plus whatever gymnastics are needed to enable default comparisons

    S a = { std::nan(nullptr), 3.0 };

    S b = { std::nan(nullptr), 2.0 };

    assert(!(a < b) && !(a > b) && !(a == b));  // presumably, struct S has no strict total order

I will also happily take the role of explaining why after so many years we 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 constructor and an equality-comparison operator, doesn't mean it's a regular type.

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

–Arthur

[Fabio Fracassi]

On 04/01/2017 19:40, Oliver Kowalke wrote:

2017-01-04 19:12 GMT+01:00 Bo Persson <b...@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

[Nicol Bolas]

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.

[Nicol Bolas]

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

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

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.

[dgutson .]

El 11/8/2016 10:02, <looseont...@gmail.com> escribió:

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-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-pr...@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.

[Nicol Bolas]

On Wednesday, January 4, 2017 at 1:41:13 PM UTC-5, m.ce...@gmail.com wrote:

W dniu środa, 4 stycznia 2017 17:01:20 UTC+1 użytkownik Nicol Bolas napisał:

On Wednesday, January 4, 2017 at 9:39:30 AM UTC-5, m.ce...@gmail.com wrote:

W dniu środa, 4 stycznia 2017 11:42:12 UTC+1 użytkownik Arthur Tchaikovsky napisał:

>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.

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

I think committee should really prioritize its work, esp. on features that should have been there long time ago: modules, reflection and maybe concepts.

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.

Same for reflection and concepts.

Yeah, this is what I mean when I talk about proper judgement of the 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 functionality to work on". People have been working on modules. A lot of people have been working on modules. We have two in-progress 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' working on modules and a decade of time the reason we have no modules support in C++ standard is because 'it is hard'.

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

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

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

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

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

From my point of view, the problem is not technical. It's about management - resources, planning and decision making.
Maybe 'management' part got better in recent years, but all the previous years are lost.
People are just tired of hearing yet again that we won't have modules, reflection or concept in next C++ version, and that's why (at least 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 their own lives - i.e. there doesn't seem to be any push from 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 C++ near future.

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

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

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

Also, I don't think ISO standardization is even allowed to be driven in a top-down fashion, where some group of "elites" decide that we're solving problems X, Y and Z for this release, then tell others to actually solve 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 those with "vision" know what needs to be improved in the language and that everything outside that vision should be secondary.

Things that C++17 got that didn't fit into Stroustrup's "vision" include fold expressions, structured binding, and guaranteed elision. These are all 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 gotten them into the language. Similarly, C++20 is off to an interesting start, with designated initializers; again, not something that someone's "vision" says we need, but I very much appreciate the feature. I hope to see other general purpose features in C++20 too, like product type unpacking.

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

[Richard Smith]

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-pr...@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.

[Vicente J. Botet Escriba]

+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 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,

+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 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.

+1

UCS isn't that.

Vicente

[Oliver Kowalke]

2017-01-05 0:49 GMT+01:00 Fabio Fracassi <f.fra...@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

[Ville Voutilainen]

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.

[gmis...@gmail.com]

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.

[gmis...@gmail.com]

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

[Peter Koch Larsen]

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

[Robert Ramey]

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

[Thiago Macieira]

Em quinta-feira, 5 de janeiro de 2017, às 00:43:01 PST, dgutson . escreveu:
> 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?

Daniel

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

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

[Arthur O'Dwyer]

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 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.

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 — having code-that-does-X look fundamentally different from 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 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. ;)  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,

–Arthur

[Richard Smith]

On 5 January 2017 at 13:42, Arthur O'Dwyer <arthur...@mixpanel.com> 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 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.

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 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 applying 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 — having code-that-does-X look fundamentally different 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. ;)

=)

 

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,

–Arthur

--

You received this message because you are 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-pr...@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.

[Giovanni Piero Deretta]

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 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 — having code-that-does-X look fundamentally different from code-that-does-Y.

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.

-- gpd

[Jens Maurer]

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

[Nicol Bolas]

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 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.

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."

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 that 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 standard wording and a rapidly maturing implementation.

I see UCS in a similar light. There's opposition to it, but the opposition 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. But it solves a problem the language genuinely needs solving. So unless the alternatives can mature into something more than paper ideas, then despite 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 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, we should move forward with what we have now for the good of the language.

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.

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 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 — 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 of 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 adding 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 ;)

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?

[Jens Maurer]

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 experience with similar features 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.
>
> 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.

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 opposition 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.

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

[Richard Smith]

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 now 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 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 — 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 of 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 adding 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?

--

You received this message because you are 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-pr...@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.

[Ion Gaztañaga]

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