On Tue, Jul 23, 2019 at 8:31 PM Joshua Cannon via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

As a (contrived) example, let's say I have a class (called Foo) that takes in a const-reference to a vector. It is going to store a reversed copy of the vector with all of the elements also incremented as a member. Additionally, it is going to have a member of type Bar, which is constructed by taking in iterators to the reversed-and-incremented vector.
There's no easy way to do that today. Some solutions might be [...]

A proposal with this degree of "real-estate claimage" needs to have better motivation than a single contrived example where you already know how to work around it anyway.

I say that your proposal claims a lot of syntactic (and mental) real-estate because it appears to collide with the long-desired feature of "member-initializer-list with trailing comma." Consider:

struct S1 {
    int x, y, z;
    S1() : x(1), y(2), z(3),
    {}
};

Under your proposal, IIUC, this would be ill-formed code: the compiler would see `};` when it was expecting another `,` followed by a member-initializer. But there's already a fair bit of support (from the machine-generated-code crowd) for this to be well-formed and for the compiler to simply ignore the trailing `,` after z's member-initializer.

You could certainly deal with this by tweaking your proposed syntax — like maybe interpose some sort of keyword, or use `( ... )` instead of `{ ... }` to delimit your code blocks, or whatever. But that brings me back to the proposal's very weak motivation (about which, more below).

You also mentioned another syntactic issue that I think is a bigger deal than you're making it. Consider

struct S2 {
    int x, y, z;
    S2(int) : x(1), { ++x; }, y(2), z(3) {}
    S2(short) : x(1), { ++(this->x); }, y(2), z(3) {}
    S2(char) : x(1), { S2 *p = this; ++(p->x); }, y(2), z(3) {}
};

Is `S2(int)` well-formed? You'd say "yes," obviously.
Is `S2(short)` well-formed? It's just syntactic desugaring of `S2(int)`, right?
Is `S2(char)` well-formed? If so, then how do you propose to stop people from accessing `p->y`?

Lastly, you haven't mentioned what you'll do about

struct S3 {
    int x, y, z;
    S3(int) : z(3), { puts("hello"); }, y(2), { puts("world"); }, x(1) {}
};

nor

struct S4 {
    int x, y, z;
    S4(int) : x(1), { return; }, y(2), z(3) { puts("so this is never reached?"); }
};


Okay, now I want to return to the weak motivation, by showing how I'd refactor your example code to work in today's C++.

Example:

class Foo {
    std::vector<int> myVec;
    Bar bar;

public:
    Foo(const std::vector<int>& inVec):
        myVec(inVec.rbegin(), inVec.rend()),
        {
            std::transform
            (
                myVec.begin(),
                myVec.end(),
                myVec.begin(),
                &[](int i){return ++i;}
            );
        },
        bar(myVec.begin(), myVec.end())
    {}
};

I would write this as

class Foo {
    std::vector<int> myVec;
    Bar bar;
public:
    explicit Foo(const std::vector<int>& inVec) :
        myVec(rev_and_inc(inVec)),
        bar(myVec.begin(), myVec.end())
    {}
private:
    static std::vector<int> rev_and_inc(const std::vector<int>& inVec) {
        std::vector<int> result(inVec.rbegin(), inVec.rend());
        for (int& elt : result) ++elt;
        return result;
    }
};

This code is exactly as efficient as the code you wrote, thanks to copy elision. It's also easier to read. It's also portable to C++11 compilers. (In fact, the only reason it's not valid C++03 is because I turned your `std::transform` into a C++11 for-loop for readability's sake.)

I hesitate to claim that you'll never find any sufficient motivation for your proposal, but the code you've presented certainly isn't sufficient motivation to justify a language change (let alone a language change that claims so much useful real-estate).

HTH,
–Arthur