Placeholder within function-style object construction, syntactically solves vector construction uniformity.

[msadeqhe]

Let's make it short...

a: vector<int> = (1, 2);
b: = vector<int>(1, 2);

a will create a vector of (1, 2) (list initialization), but b will create a vector of (2)(direct initialization). b is instantiated by function-style object construction syntax. We could write it like this:

b: vector<int> = vector<int>(1, 2);

I suggest to allow to use placeholder (_ character) on the right-side like this:

b: vector<int> = _(1, 2);

In this way, we can construct a vector using one of the following uniform syntaxes in a consistent manner:

a: vector<int> = (1, 2);
b: vector<int> = _(1, 2);

a will create a vector of (1, 2) (list initialization), but b will create a vector of (2) (direct initialization). It's complementary to how we use placeholder on the left-side:

b: vector<int> = _(1, 2);
c: _ = vector<int>(1, 2);

Every type can be used instead of vector<int> in the above examples.

[AbhinavK00]

This has come up a number of times and everytime we just don't get to a solution. While I don't like this fix, a fix is definitely needed.

[msadeqhe]

You're right. Users already suggested many fixes in other discussions.

I hope to have a fix, no matter which one.

[SebastianTroy]

Could cpp2 have a shim layer between the std library that patches a small number of problems, so we could gain the benefit of the entire std library, but cover up some of the warts? Basically somethinf that imports the std library and reexports almost all of it unchanged with a few extra helpers or replacements for a few symbols? On 11 September 2023 07:08:55 Sadeq ***@***.***> wrote: You're right. Users already suggested many fixes in other discussions. I hope to have a fix, no matter of which one. — Reply to this email directly, view it on GitHub<#672 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQO7UCU46UYQWUWENHDXZ2THLANCNFSM6AAAAAA4SYI7X4>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[msadeqhe]

Could cpp2 have a shim layer between the std library that patches a small number of problems, so we could gain the benefit of the entire std library, but cover up some of the warts? Basically something that imports the std library and reexports almost all of it unchanged with a few extra helpers or replacements for a few symbols?

So to fix the Cpp1 std library, Cpp2 should:

• Forbid bad API in Cpp2
• Fix bad API from Cpp1 std library

To forbid bad API in Cpp2, it can make initializer_list to behave like a list of variable arguments. For example:

Seq: type = {
    operator=: (out this, a: int, more: initializer_list<int>) = {...}
}

x: Seq = (1, 2, 3); // Seq(a: = 1, more: = (2, 3))

What's the point? Cpp2 can produce an error if the user tries to make a bad API:

Seq: type = {
    operator=: (out this, all: initializer_list<int>) = {...}
    operator=: (out this, a: int, more: initializer_list<int>) = {...}
    operator=: (out this, a: int, b: int, c: int) = {...}
}

x: Seq = (1, 2, 3); // ERROR!
// It's ambiguous to call which constructor:
// Seq(all: = (1, 2, 3))
// Seq(a: = 1, more: = (2, 3))
// Seq(a: = 2, b: = 2, c: = 3)

It's ambiguous, because essentially all constructors have the same signature.

So after this change (forbidding bad API), it doesn't matter how the object is constructored (either by : syntax or function-style syntax), always the result would be the same:

Seq: type = {
    operator=: (out this, a: int, more: initializer_list<int>) = {...}
}

// These are completely the same:
x: Seq = (1, 2, 3); // Seq(a: = 1, more: = (2, 3))
y: =  Seq(1, 2, 3); // Seq(a: = 1, more: = (2, 3))

To fix bad API from Cpp1 std library, one way is to support extension methods and keyword (named) arguments in Cpp2:

// `+=` means we are adding methods to an already declared type `vector`.
vector: <T> type += {
    // `as` means we are assigning name `count` as a keyword to the argument `n`.
    operator=: (out this, n as count: size_type, value: T) = {
        // Implementation is here...
    }
}

// It calls the constructor from Cpp1 std library.
a: vector<int> = (1, 2); // A vector of (1, 2)

// It calls our declared constructor which has a keyword (named) argument.
b: vector<int> = (count: = 1, 2); // A vector of (2)

The syntax can be anything else that can integrate well within Cpp2 grammar.

[AbhinavK00]

Here's a cpp20 example

auto a = std::vector(1,2);    //[2]
auto b = std::vector({1,2}); //[1,2]

I find this very clear and so a solution in cpp2 could be of the form

a : std::vector = (1,2);    //[2]
b : std::vector = ([1,2]); //[1,2]

where [1,2] is not an initialiser list but cpp2 language array. It could be lowered to a class like cpp2::array which will be implicitly convertible to std::initializer_list and maybe(?) that would be enough(?).
Having one layer on top of standard library to fix some problems is a nice idea too.

[msadeqhe]

In Cpp1, parentheses are not necessary:

auto a = std::vector(1,2);  //[2]
auto b = std::vector{1,2}; //[1,2]

Similarly in Cpp2:

a : std::vector = (1,2);  //[2]
b : std::vector = [1,2]; //[1,2]

I like your suggestion.

On the other hand, if the plan is to unify lists and parameters with (), Cpp2 should forbid the programmer to write bad API, and it should make all construction syntaxes to always have the same result (so it leads to less surprises for new programmers).

[AbhinavK00]

Yes, parens are not necessary but that's what makes it clear for me. Without parens, it feels like changes of brackets just changes behaviour but with brackets, I can understand that I am passing an array (actually a std::initializer_list) in one case and 2 int parameters in the other. And that's what I hope to get translated to cpp2 with language arrays.
Edit:

On the other hand, if the plan is to unify lists and parameters with ()

Pls no, too much unification sometimes leads to confusion.

[jcanizales]

I thought the guidance and consensus was that C++'s std::vector::vector(size_t n, T val) was a mistake (*) and people shouldn't call it? If that's the case, why try to enable calling it from C++2?

(*) When looked at with modern eyes - at the time it was introduced there were no initializer lists for custom classes' constructors.

[jcanizales]

The proposal is how to make both calls look more consistent to each other?

[msadeqhe]

Yes, that's it. Make those constructors (both direct non-list initialization and list initialization) to look uniform, but if you think that direct non-list initialization for vector is a mistake, then forbid it and fix it.

[gregmarr]

Why do you want two things which produce vastly different results to look uniform?

[jcanizales]

if you think that direct non-list initialization for vector is a mistake, then forbid it and fix it

I mean, we all know this is a guy's pet project that other people are helping him on out of the goodness of their heart, right? As in, we're all participating here because we want it to succeed, but it's perfectly ok if some things don't get done.

I haven't contributed a single line of code myself and feel fine with that.

[msadeqhe]

You're right.

[msadeqhe]

Thanks. It seems I should close this discussion as resolved. Because other fixes are available which can be considered instead of my suggestion.