[SUGGESTION] Array Literals with the support of both Multidimensional and Jagged Arrays

[msadeqhe]

Preface

The idea of this suggestion is gathered from discussion in this issue.

I have to mention that (...) is already for calling constructores, grouping expressions and initializing lists.

Now, consider the following ambiguities:

• (1) as an expression, are they parenthesis around a value? Or is it an array of one item?
• () is not an empty array, but it calls default constructor in variable declarations.
• (1, 2) in declarations, is it the arguments of a constructor? Or is it an array of two items?

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

Yes I know that std::vector has a bad API design, but I ask myself why would Cpp2 (like Cpp1) allow libraries to have this ambiguity in the first place?

Having array literals with a different syntax, will solve those three ambiguities. I suggest to use [...] for array literals:

x0: = [1, 2, 3];

Also nested (...)s or ;s or etc, will create multidimensional arrays, because they don't create a new array, and they are for mathematical grouping (as they are used to group expressions and to change the precedence of operators). On the other hand, nested [...]s will create jagged arrays, because they create a new array:

// Multideminsional Array
x0: = [(1, 2, 3), (4, 5, 6)];
// Or alternatively one of the following syntax:
// x0: = [1, 2, 3; 4, 5, 6];
// x0: = [(1, 2, 3); (4, 5, 6);];
r0: = x0[0, 1] == 2; // true

// Jagged Array
x1: = [[1, 2, 3], [4, 5, 6]];
r1: = x1[0][1] == 2; // true

I currently do not suggest to support multidimensional arrays, but it's a possibility to consider in the future.

Suggestion Detail

Three options are available instead of () for array literals:

• <...> is already for template parameters/arguments. It's not a good choice, because:
  • It doesn't have any known relation with arrays.
  • It looks like less-than and greater-than operators, because of this similarity, it's not a good choice for arrays which are methematical such as a vector of boolean values, e.g. <a < b, c > 2>.
• [...] is already for accessing items of an array. It seems to be a good choice.
• {...} is already for function/statement blocks and type definitions. It can be considered as a good choice.

Now, it's the time to compare both [...] and {...} for array literals:

x0: /*...*/ = [1];
x1: /*...*/ = {1};

OK. Both of them look good. So what if we want to write an empty array?

x0: /*...*/ = [];
x1: /*...*/ = {};

[] is clearly an empty array, but {} can be either an empty function/statement block or an empty array in which it depends on the declaration. For example:

x0         :       std::vector<int> = {};  // empty array
x1         : () -> void             = {}   // empty statement block
x2         : () -> std::vector<int> = {}   // ERROR: It doesn't work, although visually it's the same as above.
x3: = call(: () -> std::vector<int> = {}); // SURPRISE! It works, although visually it's the same as above.

{} is visually surprising and inconsistent for x1, x2 and x3, although they look the same:

• In x0 declaration, {} is an empty array.
• In x1 declaration, {} is an empty statement block.
• But in x2 declaration, {} is an error, because it must end with ;.
• But in x3 declaration, {} is an empty array!

So [...] is more expressive than {...} for array literals.

Now let's consider this situation in the following example:

x0: = [1, 2, 3][1]; // It's equal to 2

The first [...] creates an array, and the second [...] accesses an item from it. A sequence of [...]s is not ambiguous, because its behaviour is similar to parenthesis:

x0: = (call() + something)(1);

The first (...) groups the operands of operator+, and the second (...) calls operator() on the result.

Your Questions

Will your feature suggestion eliminate X% of security vulnerabilities of a given kind in current C++ code?

Yes. If a bad API design can suddenly change the meaning of code, it's going to be a security vulnerability. This suggestion is a way to prevent it by separating arrays from constructors and expressions.

Will your feature suggestion automate or eliminate X% of current C++ guidance literature?

Yes. It's not needed to learn if user-defined constructors are ambiguous with initializer lists, because it prevents ambiguous situation completely. It allows more API choices.

Considered Alternatives

An alternative solution was that if a type has ambiguous constructor with initializer list, it should be a syntax error. By the way, this approach wouldn't fix the bad API design of std::vector.

Another alternative solution was a little complicated. The idea was to favor constructors over initializer list, and to consider a comma-separated list with parenthesis to be an initializer list:

x0: = (1, 2); // x0 is an initializer list

With the help of unnamed variable declaration and indirect initialization, it could be used like this:

// `: = (1, 2)` is an initializer list
x0: std::vector<int> = : = (1, 2);

// This calls the constructor to create a vector of one element with value 2.
x1: std::vector<int> = (1, 2);

But I gave up on this idea, becuase it would encourage unnamed variable declaration more than necessary.

Finally I considered to use literal templates syntax:

// `(1, 2)<int>` is an initializer list
x0: std::vector<int> = (1, 2)<int>;

// `list` is a user-defined literal suffix which creates an initializer list
x1: std::vector<int> = (1, 2)list;

// This calls the constructor to create a vector of one element with value 2.
x2: std::vector<int> = (1, 2);

But I gave up on this idea too, because (1, 2)<int> would require to always specify the type, and (1, 2)list would make user-defined literal suffixes to be look like constructors.

Edits

• I've added one more alternative solution which I was considered.

[AbhinavK00]

Herb points out that [1,2,3] would be hard to parse to see if it's the indexing operator or an array literal here, so here's the suggestion for an unambigious syntax. It'll be

x0: = [,1, 2, 3];  //notice the comma between the [ and 1

These arrays would effectively translate to std::array in cpp1 or some cpp2::array if Herb wants a different type.
With that syntax, std::vector constructors would look like this

x1 : std::vector = (4,2);  // vector of [2,2,2,2]
x2 : std::vector = ([,4,2]) // vector of [4,2]
x3 : std::vector = [,4,2]  //error!

There won't be any initialiser lists in cpp2, they'll be just an implementation detail on cpp2 side.

[msadeqhe]

Herb points out that [1,2,3] would be hard to parse to see if it's the indexing operator or an array literal here, ...

So "hard to parse" is the only complaint against [...]. I hope it to be revisited. If there is an identifier before [...] then it's a subscript operator, otherwise it's an array literal:

x0: = identifier[1]; // [1] is a subscript operator.
x1: = [1]; // [1] is an array literal.

It's like parenthesis in Cpp2 and Cpp1:

x0: = identifier(1); // (1) is a function call operator.
x1: = (1); // (1) is an expression group.

The only difference is that [...] (without identifier before it) has to be transformed to {...} in Cpp1. But other cases don't need this transformation.

[msadeqhe]

Herb points out that [1,2,3] would be hard to parse to see if it's the indexing operator or an array literal here, ...

It seems Herb's answer was to this comment:

Could we use square [ ] brackets for lists/aggregates instead?

I have to clarify that I don't suggest to also use [...] for aggregates or etc. I suggest to use [...] only for array literals. IMO parenthesis are best for aggregates, because somehow they are constructors similar to designated initializers which look like named arguments (both visually and semantically), and there won't be any conflict between constructors and designated initializers with parenthesis as described in this comment.

[HALL9kv0]

I think it is important for initializer list/ array-type constructors to have a different symbol/syntax from everything else, as they are a special case. We also need avoid the double paren ((...)) nightmare.
[...] is the most sensible choice as it is intuitive and very familiar for people coming from python/javascript (two of the most pop languages) .

[AbhinavK00]

I think initialiser list contructors should be viewed as simple contructors where we pass arrays as parameters, they should not be a special case. so if [...] is chosen as array literals, then

x : std::vector = ([1,2,3,54]);

should translate to initialiser list syntax instead of

x : std::vector = [1,2,3,54]; //does not feel right

[HALL9kv0]

The issue with that is that for the case of a 2D vectorst the ('s and [' become too many
v : std::vector<std::vector<int>> = ([([1,2,3]),([4,5,6])]) ;

The () feel redundant and a pure [[1,2,3],[4,5,6]] syntax way less prone to typing errors. Also, it more closely resembles the math vectors everyone learns in school.

[AbhinavK00]

That's not what I recommend. The syntax would be

v : std::vector<std::vector<int>> = ([[1,2,3],[4,5,6]]);

Like I said, just view it as passing an array to a constructor. Here we are passing the array [[1,2,3],[4,5,6]] as an argument to the constructor.
One more thing, I said that the following would be an error

x : std::vector = [1,2,3,54];

But I think this should be allowed if the constructor is marked implicit, what do you guys think?

[msadeqhe]

Parenthesis around [...] are not necessary, because [...] is an array literal. It's just like other literals in which we pass arguments to the constructor without implicit:

#include <iostream>

taip: type = {
    operator=: (out this, i: int) = {
        std::cout << i << "\n";
    }
}

main: () = {
    t0: taip = 1;

    // Parenthesis are not necessary.
    t1: taip = (1);
}

So 1 is a literal with type int, in the same way [1, 2, 3] is a literal with type std::initializer_list<int>, that's similar to how "text" is a literal with type std::string. For example:

#include <string>
#include <iostream>

taip: type = {
    operator=: (out this, text: std::string) = {
        std::cout << "OK. That's a string literal.\n";
    }
    operator=: (out this, list: std::initializer_list<int>) = {
        std::cout << "OK. That's an array literal.\n";
    }
}

main: () = {
    s0: taip = "text";
    t0: taip = [1, 2, 3];

    // Parenthesis are not necessary.
    s1: taip = ("text");
    t1: taip = ([1, 2, 3]);
}

[HALL9kv0]

If I understand correctly, the inner vectors will only need [...] for their initializer list but the outer will need ([ ..]) ?
Personally, even though it is much better that ([]), I still find the ()redundant and prefer the python/javascript way.

[AbhinavK00]

Parenthesis around [...] are not necessary, because [...] is an array literal. It's just like other literals in which we pass arguments to the constructor without implicit

I thought constructors were supposed to be explicit? you guys can ignore my comments cuz it seems my understanding was wrong

[msadeqhe]

1. Multidimensional Arrays

I have to clarify that currently I don't suggest multidimensional arrays, but they are a possible feature to explore.

Multiple syntax choices are available for multidimensional arrays:

a: = [((1, 2), (3, 4)), ((5, 6), (7, 8))];
b: = [1, 2; 3, 4;; 5, 6; 7, 8];
c: = [((1, 2); (3, 4);); ((5, 6); (7, 8););];
d: = [((1; 2); (3; 4)); ((5; 6); (7; 8))];
e: = ...

Here, I'm explaining the first one of those possible syntax for multidimensional arrays:

a: = [((1, 2), (3, 4)), ((5, 6), (7, 8))];

This syntax requires loosely multidimensional arrays, when the type of array literal is not specified within declaration (e.g. the type of variable a in above example is not specified).

1.1. Loosely Multidimensional Arrays

1-dimensional arrays are loosely multidimensional arrays. It's useful in generic programming. That's because there is two types of dimensions within arrays:

• Required dimensions: They are added with parenthesis which contain commas.
  • These parenthesis must have identical commas in all corresponding elements.

// These parenthesis don't contain commas:
[(0), (1), (2), (3)]     // OK. It's equal to [0, 1, 2, 3]
[0, (1), ((2)), (((3)))] // OK. It's equal to [0, 1, 2, 3]

// These parenthesis contain commas:
[(0, 1), 2, 3] // ERROR! They must have identical commas in all corresponding elements.

// This is a combination:
[(0, (1)), (2, (3))] // OK. It's equal to [(0, 1), (2, 3)]

• Optional dimensions: They are extra dimensions in which their length is always 1, therefore we use index 0 to access them.
  • Optional dimensions are always after required dimensions.
    • We have to specify the index for required dimensions.
    • Optionally we can specify index 0 for optional dimensions.

list: /*something*/ = [1, 2, 3];

// Only `1` is required dimension. These zero-value indexes are optional dimensions.
s0: = list[1] == 2; // true
s1: = list[1, 0] == 2; // true
s2: = list[1, 0, 0] == 2; // true

The opposite is not true. Multidimensional arrays cannot be treated as 1-dimensional arrays.

I have to explain that these rules help us to get rid of parenthesis when they are used to only group expressions inside arrays without any intention to add another dimension:

// It's a 1-dimensional array.
x: = [(1 + 2), (3 + 4)];

// But optionally it can be used as a two-dimensional array.
a: = x[1];    // OK. It's equal to (3 + 4)
b: = x[1, 0]; // OK. It's equal to (3 + 4)

// It's a two-dimensional array.
y: = [(1, 2)];

// But it cannot be used as a 1-dimensional array.
a: = x[0];    // ERROR! The second index is required.
b: = x[0, 1]; // OK. It's equal to `2`

1.2. More Examples

point: type = {
    operator=: (out this, x: int, y: int) = {}
}

zero_point: () -> point = {
    return (0, 0);
}

zero_array: () -> std::initializer_list<int> = {
    return [0, 0, 0/*, ...*/];
}

a0: =     []; // An empty array
a1: =     [ [] ]; // An empty array in array
a2: =     [1, 2, 3]; // A 1-dimensional array
a3: =   [ [1, 2, 3] ]; // A 1-dimensional array of 1-dimensional arrays
a4: =    [(1, 2, 3)]; // A two-dimensional array
a5: = [ [ [1, 2, 3] ] ]; // A 1-dimensional array of 1-dimensional arrays of 1-dimensional arrays
a6: =   [((1, 2, 3))]; // A three-dimensional array
a7: =  [ [(1, 2, 3)] ]; // A 1-dimensional array of two-dimensional arrays
a8: =  [( [1, 2, 3] )]; // A 1-dimensional array of 1-dimensional arrays

Although a8 (the last line) can be visually seen as "A two-dimensional array of 1-dimensional arrays", and we can use it either way without any problem with optional dimensions:

a8: =  [( [1, 2, 3] )]; // A 1-dimensional array of 1-dimensional arrays
// It can be visually seen as a two-dimensional array of 1-dimensional arrays

x0: = a8[0][1];      // OK. A 1-dimensional array of 1-dimensional arrays
x1: = a8[0, 0][1]; // OK. A two-dimensional array of 1-dimensional arrays

[msadeqhe]

2. Dictionaries

I have to clarify that currently I don't suggest dictionaries, but they are a possible feature to explore.

No additional syntax is required for dictionaries, if Cpp2 could support type inference for unnamed variable declarations.

2.2. Dictionaries are arrays of objects.

With the help of unnamed variable declarations, we can write arrays of objects:

x0: = [: std::pair<std::string, int> = ("a", 1),
       : std::pair<std::string, int> = ("b", 2),
       : std::pair<std::string, int> = ("c", 3)];

But if Cpp2 could support type inference for unnamed variable declarations, it would be so much simpler in a way that a distinct syntax would be not needed for dictionaries:

x0: std::vector<std::pair<std::string, int>> = [: = ("a", 1),: = ("b", 2),: = ("c", 3)];

// It's a dictionary.
x1: = [: = ("a", 1),: = ("b", 2),: = ("c", 3)];

Please, see the next comment for construction with (...) in declarations.

2.2. Do "arrays of objects" conflict with "multidimensional arrays"?

No. There isn't any conflict, because parenthesis have loosely semantic unlike [...]. It's possible to have multidimensional arrays of objects, so they don't conflict with each other. For example:

// A multidimensional array of numbers
x0: matrix<int, 2, 3> = [(1, 2, 3), (4, 5, 6)];

// A multidimensional array of objects
x1: matrix<std::pair<std::string, int>, 2, 3> = [
    (: = ("a", 1),: = ("b", 2),: = ("c", 3)),
    (: = ("d", 4),: = ("e", 5),: = ("f", 6))
];
r1: = x1[0, 1]; // It is `: = ("b", 2)`.

In a nutshell, we use (a, b) to add a new dimension to the array, and := (a, b) to call the constructor of an element.

But in this case, the type of array literal is known for variable x1, therefore with the help of constructor syntax in declarations, all : = (...)s can be replaced with (...)s:

// A multidimensional array of objects
x1: matrix<std::pair<std::string, int>, 2, 3> = [
    (("a", 1), ("b", 2), ("c", 3)),
    (("d", 4), ("e", 5), ("f", 6))
];

Please, see the next comment for explanation.

[msadeqhe]

3. Array Literal of Constructors

If the type of array literals are specified within declarations, the object construction is much easier and readable.

First, I have to mention that parenthesis can have the meaning of calling constructor in declarations in Cpp2:

point: type = {
    operator=: (out this, x: int, y: int) = {}
}

main: () = {
    // These parenthesis call constructor.
    x0: point = (0, 0);
}

So with the help of this feature, we may create an array literal of constructors:

// This is not a multidimensional array.
// Because parenthesis call constructor. They don't add new dimension.
// It's not ambiguous. It's expressed from the type within declaration.
x0: std::vector<point> = [(0, 0), (1, 1), (2, 2)];

// This is a two-dimensional array.
// Because the inner most parenthesis call constructor. They don't add new dimension.
// It's not ambiguous. It's expressed from the type within declaration.
x1: matrix<point, 2, 2> = [((0, 0), (1, 1)), ((2, 2), (3, 3))];

Because the type is specified within declaration, "Parenthesis for Constructors" won't conflict with "Parenthesis for Dimenstions". Finally a dictionary will look like this when its type is specified within declaration:

c0: std::vector<std::pair<std::string, int>> = [("a", 1), ("b", 2), ("c", 3)];

// It's a dictionary.
c1: dictionary<int> = [("a", 1), ("b", 2), ("c", 3)];

It's context-free, and : = (...) is not needed for object construction (see part 2. Dictionaries from the previous comment).

[msadeqhe]

Readability examples

C++ already has operator[] to access arrays. If only operator() was available without operator[], it would be hard to understand the meaning of code. For example:

// `something` is defined somewhere...
sum: = 0;
(copy i: = 0) while i < 10 next i++ {
    // Is there any array here?
    sum += thing(something(i))(i);
}

What does it? OK. operator[] (aka brackets) will make it readable:

// `something` is defined somewhere...
sum: = 0;
(copy i: = 0) while i < 10 next i++ {
    // OK. This is an array of function objects.
    sum += thing[something(i)](i);
}

operator[] helps both "the compiler to parse" and "humans to read" the code (context-free).

In a similar manner, array literals with [...] will simplify the guidance of Cpp2 in a consistent way:

• Unnamed variable declarations will call the constructor:
  • : id = arg
  • : id = (), default constructor
  • : id = (args...)
• Parenthesis will group expressions. They cannot be empty:
  • (expr)
• Function call, operator():
  • id(), without arguments
  • id(args...)
• Brackets will create an array:
  • [], an empty array
  • [items...]
• Accessing arrays, operator[]:
  • id[], ??
  • id[index...]
• Braces are for the body of declarations and control structures:
  • {}, an empty statement block
  • { statements... }
• Templates:
  • id<>, ??
  • id<args...>

They lead to more readable and easier to understand Cpp2 code, especially in a function call:

If we use (...) for arrays, consider how this example would be difficult to understand:

call((: t = (1, (f() + 2)), : t = (0, ())));

If you didn't lose the meaning of parenthesis, the compiler will face with ambiguous meanings.

Now if we use [...] for array literals, the previous example would look like this:

call([: t = (1, [f() + 2]), : t = (0, [])]);

Consider how you already understand what it does without my explanation (context-free).

[jcanizales]

I'm sympathetic to the suggestion, but this misunderstands the questions:

Will your feature suggestion eliminate X% of security vulnerabilities of a given kind in current C++ code?

Yes. If a bad API design can suddenly change the meaning of code, it's going to be a security vulnerability. This suggestion is a way to prevent it by separating arrays from constructors and expressions.

Will your feature suggestion automate or eliminate X% of current C++ guidance literature?

Yes. It's not needed to learn if user-defined constructors are ambiguous with initializer lists, because it prevents ambiguous situation completely. It allows more API choices.

Bolding mine: The key word in those questions is "current". Current C++ code, current C++ guidance.

[msadeqhe]

OK. Both of them look good. So what if we want to write an empty array?

x0: /*...*/ = [];
x1: /*...*/ = {};

[] is clearly an empty array, but {} can be either an empty function/statement block or an empty array in which it depends on the declaration. For example:

x0         :       std::vector<int> = {};  // empty array
x1         : () -> void             = {}   // empty statement block
x2         : () -> std::vector<int> = {}   // ERROR: It doesn't work, although visually it's the same as above.
x3: = call(: () -> std::vector<int> = {}); // SURPRISE! It works, although visually it's the same as above.

{} is visually surprising and inconsistent for x1, x2 and x3, although they look the same:

• In x0 declaration, {} is an empty array.
• In x1 declaration, {} is an empty statement block.
• But in x2 declaration, {} is an error, because it must end with ;.
• But in x3 declaration, {} is an empty array!

So [...] is more expressive than {...} for array literals.

For {}, Cpp2 has to look within {} to find out if it's a list or a block statement. How much of this visually unclear meaning (opinion-based) is acceptable?

a: = call(: () -> std::vector<int> = {1, 2, 3});          // {} is a list.
b: = call(: () -> std::vector<int> = { /*statements*/ }); // {} is a block statement.
c: = call(: () = {});                                     // {} is a block statement.
d: = call(: () -> _ = {});                                // {} is a list.

The only thing against {} for array literals is this behaviour, otherwise {} is also a good choice like []. Either of them will resolve issues.

Another Considered Alternative

Also () can be used for array literals if Cpp2 could support typed expressions as described in issue #463, in this way () always calls the direct constructor:

x: vector<int> = (1, 2);      // This is an array of one `int` with value 2.
y: vector<int> = (1, 2):list; // This is an array of two `int`s with values 1 and 2.

list<T> is a type alias to initializer_list<T>.

But the problem of this approach is that we have to write :list everytime.

// This is an array of two `int`s with values 1 and 2.
z: = (1, 2):list:vector<int>;

On the other hand, if () may call either direct constrcutor or initializer_list<T> constructor, Cpp2 may favor direct constructors over initializer_list<T> constructor, in this way :list will be used only for ambiguous cases:

x: vector<int> = (1, 2);      // This is an array of one `int` with value 2.
a: = (1, 2):vector;           // The same

y: vector<int> = (1, 2):list; // This is an array of two `int`s with values 1 and 2.
b: = (1, 2):list:vector;      // The same

z: vector<int> = (1, 2, 3);   // This is an array of three `int`s with values 1, 2 and 3.
c: = (1, 2, 3):vector;        // The same

So the constructor with initializer_list<T> is like a general constructor, and constructors with multiple arguments of type T are like specialization:

Abc: <T> type = {
    // General constructor for sequence of `T`s
    operator=: (out this, initializer_list<T>) = { /*statements*/ }

    // This is a specialized constructor for one item of `T`
    operator=: (out this, a: T) = { /*statements*/ }

    // This is a specialized constructor for three items of `T`s
    operator=: (out this, a: T, b: T, c: T) = { /*statements*/ }
}

main: () = {
// It calls the specialized constructor for one item of `int`.
    a: Abc<int> = (1);
// It calls the general constructor for sequence of `int`s.
    b: Abc<int> = (1, 2);
// It calls the specialized constructor for three items of `int`s.
    c: Abc<int> = (1, 2, 3);
// It calls the general constructor for sequence of `int`s.
    d: Abc<int> = (1, 2, 3, 4);
}

By the way, it can be a bad API if those specialized constructors had completely different behaviours as vector<int> has a bad API. If Cpp2 wouldn't call direct constructor and list initialization with the same notation, it would completely eliminate the possibility of this bad API to happen. Using [...] or {...} or even force to write (...):list for every list initialization will elimintate the possibility of bad API to happen.

[AbhinavK00]

Jagged arrays are different from a tuple of arrays, because the length of tuples are fixed.

Sorry for misunderstanding, I thought the suggestion was about fixed length arrays. But I think cpp2 should support fixed length arrays as inbuilt as one can always resort to std::vector.

[AbhinavK00]

The idea of native arrays and tuples is something I really like for cpp2 as these contructs fit better at the language level rather than at a library level.
I'm not proposing a broad suggestion like this issue but a simple [...] (or anything that works) syntax for language arrays that simply lower to std::array in cpp1 code.
P2163 is a paper that proposes native tuples in cpp. Although its goal is more to fix/extend braced-init-lists, cpp2 could still have them as tuples quite useful.

Also, while this is more off-topic, does gsl's dynarray have a place in cpp2?

[msadeqhe]

That's a good idea. [...] can be used for both arrays and tuples if we could have P2163 in Cpp1:

a: = [10, 20, 30]; // an array of integers
t: = [10, "text"]; // a tuple of integer and string

[SebastianTroy]

Makes it hard to know whether it is an array or tuple when named values are used to construct rather than literals, would need the context On 7 September 2023 06:22:10 Sadeq ***@***.***> wrote: That's a good idea. [...] can be used for both arrays and tuples if we could have P2163 in Cpp1: a: = [10, 20, 30]; // an array of integers t: = [10, "text"]; // a tuple of integer and string — Reply to this email directly, view it on GitHub<#637 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQOLPIFC53JNVUUY6EDXZFKX7ANCNFSM6AAAAAA4OKIH6U>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[AbhinavK00]

Yeah, we would need different kinds of brackets to distinguish. Something like

a := [1,2,3];    //array of 3 integers
t := {1, 2,3};  //tuple of <int, int, int>

but syntax can be considered later.

[msadeqhe]

Yeah, we would need different kinds of brackets to distinguish. Something like

a := [1,2,3];    //array of 3 integers
t := {1, 2,3};  //tuple of <int, int, int>

but syntax can be considered later.

Or Python-style:

a := [1, 2, 3]; // array
t := (1, 2, 3); // tuple

[msadeqhe]

I think Cpp1 this approach is good enough:

• {...} is list initialization, if it cannot find the right constructor for that, instead it's direct initialization.
• (...) is direct initialization, if it cannot find the right constructor for that, instead it's list initialization.

But there is a difference in Cpp1, (...) does narrowing conversion but {...} doesn't.

So Cpp2 can just fix that by making them similar in regards to narrowing conversion.

Also the following ambiguities about {...} can be solved if Cpp2 drops one extra = from declarations:

Now, it's the time to compare both [...] and {...} for array literals:

x0: /*...*/ = [1];
x1: /*...*/ = {1};

OK. Both of them look good. So what if we want to write an empty array?

x0: /*...*/ = [];
x1: /*...*/ = {};

[] is clearly an empty array, but {} can be either an empty function/statement block or an empty array in which it depends on the declaration. For example:

x0         :       std::vector<int> = {};  // empty array
x1         : () -> void             = {}   // empty statement block
x2         : () -> std::vector<int> = {}   // ERROR: It doesn't work, although visually it's the same as above.
x3: = call(: () -> std::vector<int> = {}); // SURPRISE! It works, although visually it's the same as above.

{} is visually surprising and inconsistent for x1, x2 and x3, although they look the same:

• In x0 declaration, {} is an empty array.
• In x1 declaration, {} is an empty statement block.
• But in x2 declaration, {} is an error, because it must end with ;.
• But in x3 declaration, {} is an empty array!

So [...] is more expressive than {...} for array literals.

If we write the above example with the new declaration syntax as discussed in #742 and #793:

x0         :       std::vector<int> = {};  // An empty vector
x1         : () -> void               {}   // An empty statement block
x2         : () -> std::vector<int> = {}   // ERROR! It requires semicolon, and it's not visually ambiguous.
x3: = call(: () -> std::vector<int> = {}); // OK. {} is an empty vector.

So in a nutshell {} is an empty initializer list if it's on the right side of =, otherwise it's an empty block statement.

Why Cpp1 this approach is good (of course with fixed narrowing conversion)?

Because making (...) and {...} to fallback to each other is as much helpful as UFCS in generic code.

Optionally, the syntax of {...} may be changed to [...] in Cpp2, because it resembles operator[]. On the other hand, having the same syntax for both Cpp1 and Cpp2 is an advantage.

[JohelEGP]

(...) is direct initialization, if it cannot find the right constructor for that, instead it's list initialization.

Parentheses are never list-initialization: https://en.cppreference.com/w/cpp/language/list_initialization.

[msadeqhe]

Oops, you're right. But making (...) to fallback to {...}, doesn't break existing code in Cpp1.

Thanks. I've fixed my wrong statement.

[JohelEGP]

But making (...) to fallback to {...}, doesn't break existing code in Cpp1.

It certainly breaks code that relies on constructible traits or similar with SFINAE or manual contraints.

[msadeqhe]

Thanks. Type traits are library feature, but (I was thinking about that) syntactically it doesn't break code (regardless of which library or reflection feature we are using).

[msadeqhe]

So for example in Cpp1:

// [2]
std::vector<int> var1(1, 2);
// [1, 2]
std::vector<int> var2{1, 2};
// ERROR!
std::vector<int> var3(1, 2, 3, 4, 5, 6);

If it could create an object instead of ERROR! in var3, the programmer would create an object, either with (...) or {...}, it depends on if the programmer prefers to create it from arguments or a list of items in generic code.

For example in Cpp2:

// [2]
var1: std::vector<int> = (1, 2);
// [1, 2]
var2: std::vector<int> = {1, 2};
// [1, 2, 3, 4, 5, 6]
var3: std::vector<int> = (1, 2, 3, 4, 5, 6);

Instead of a compilation error in var3, it fallbacks to {...} in generic code.

[AbhinavK00]

If every constructor in cppfront relies on parenthesis, then there would be no question of () vs {} and code would be naturally generic. There are better ways to solve the problem and yet keep the code generic I guess.

[msadeqhe]

Yes, that's why we currently have only () in Cpp2 to construct objects. But unfortunately I can write a class with wrong constructors that may lead to bad API.

[AbhinavK00]

That's on the programmer, a language can only do so much. Cpp2 does great, the current problem is from a bad cpp1 choice that is std::initializer_list.

[msadeqhe]

Then what's the point of having type safe (and memory safe, ...) programming languages? Cpp2 can help C++ programmers in writing correct and clean code.

[AbhinavK00]

Type-safety is correctness via restriction. If the goal is to help programmers write correct code, the way is to diagnose "wrong" constructors, the fallback semantics introduce confusion and possible bugs in future.

[SebastianTroy]

Could cpp2 use the variadic "..." to denote initialiser lists, and then error when constructor signatures are ambiguous? On 11 November 2023 10:24:36 Abhinav00 ***@***.***> wrote: That's on the programmer, a language can only do so much. Cpp2 does great, the current problem is from a bad cpp1 choice that is std::initializer_list. — Reply to this email directly, view it on GitHub<#637 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQLHTFRZPQHEDOBNMVLYD5G6DAVCNFSM6AAAAAA4OKIH6WVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TKMZZHAZDK>. You are receiving this because you commented.Message ID: ***@***.***>

[msadeqhe]

Yes, I hope we had it as a language feature in Cpp2 to prevent programmers to write wrong constructors.

[msadeqhe]

An alternative solution was that if a type has ambiguous constructor with initializer list, it should be a syntax error. By the way, this approach wouldn't fix the bad API design of std::vector.

std::initializer_list<T> is not the solution to have a safe variable argument list. They can be completely replaced with an integrated language feature. For example:

run: (args...: int) = {}
// : (args: int, ...) = {}

Now, syntactically Cpp2 can disallow a function (or constructor) to have the following overloads at the same time:

run: (arg1: int) = {}
run: (args...: int) = {} // ERROR!
// : (args: int, ...) = {} // ERROR!

The above example will be like the following example with std::initializer_list<int>:

run: (arg1: int) = {}
run: (args: std::initializer_list<int>) = {}

But because std::initiazlier_list<int> type is different from int, syntactically it has to be allowed to have all those overloads which leads to bad API design.

So this approach (making () to mean both construction and list initialization, and disallowing creating constructors with wrong signature) seems a good solution that also works in generic code, the syntax can be anything else such as using more/next contextual keyword or ... (in a way that it doesn't conflict with parameter packs of templates):

cls1: type = {
    //       : (out this, args: std::initializer_list<i32>)
    operator=: (out this, more args: i32) = {}
    //       : (out this, next args: i32) = {}
    //       : (out this, ... -> args: i32) = {}
    //       : (out this, -> args: i32) = {}
    //       : (out this, args: i32 -> ...) = {}
}

cls2: type = {
    //       : (out this, args: std::initializer_list<_>)
    operator=: (out this, more args) = {}
    //       : (out this, next args) = {}
    //       : (out this, ... -> args) = {}
    //       : (out this, -> args) = {}
    //       : (out this, args -> ...) = {}
}

Also args can be the last parameter, if Cpp2 will support combination of regular parameters with initializer_list:

cls3: type = {
    operator=: (out this, name: std::string, age: i32, more args: i32) = {}
    //       : (out this, name: std::string, age: i32, next args: i32) = {}
    //       : (out this, name: std::string, age: i32, ... -> args: i32) = {}
    //       : (out this, name: std::string, age: i32, -> args: i32) = {}
    //       : (out this, name: std::string, age: i32, args: i32 -> ...) = {}
}

var3: cls3 = ("Alex", 30, 1, 2, 3);

For jagged arrays, multidimensional arrays and dictionaries, we will have:

var1: std::vector<std::vector<i32>> = ((1, 2), (3, 4));
var2: matrix_2d<i32> = ((1, 2), (3, 4));
var3: std::vector<std::pair<std::string, i32>> = (("one", 1), ("two", 2));

And so on..., the type specifies the meaning of nested ()s.

[SebastianTroy]

Would this require the function to become templated? Or could it be lowered to cpp1 in such a way that it doesn't require a cpp1 feature, but maintains the benefits? On 12 November 2023 04:45:46 Sadeq ***@***.***> wrote: An alternative solution was that if a type has ambiguous constructor with initializer list, it should be a syntax error. By the way, this approach wouldn't fix the bad API design of std::vector. std::initializer_list<T> is not the solution to have a safe variable argument list. They can be completely replaced with an integrated language feature. For example: run: (args...: int) = {} // : (args: int, ...) = {} Now, syntactically Cpp2 can disallow a function (or constructor) to have the following overloads at the same time: run: (arg1: int) = {} run: (args...: int) = {} // ERROR! // : (args: int, ...) = {} // ERROR! The above example will be like the following example with std::initializer_list<int>: run: (arg1: int) = {} run: (args: std::initializer_list<int>) = {} But because std::initiazlier_list<int> type is different from int, syntactically it has to be allowed to have all those overloads which leads to bad API design. So this approach (making () to mean both construction and list initialization, and disallowing creating constructors with wrong signature) seems a good solution that also works in generic code, the syntax can be anything else such as using more/next contextual keyword or ... (in a way that it doesn't conflict with parameter packs of templates): cls1: type = { // : (out this, args: std::initializer_list<i32>) operator=: (out this, more args: i32) = {} // : (out this, next args: i32) = {} // : (out this, ... -> args: i32) = {} // : (out this, -> args: i32) = {} } cls2: type = { // : (out this, args: std::initializer_list<_>) operator=: (out this, more args) = {} // : (out this, next args) = {} // : (out this, ... -> args) = {} // : (out this, -> args) = {} } Also args can be the last parameter, if Cpp2 will support combination of regular parameters with initializer_list: cls3: type = { operator=: (out this, name: std::string, age: i32, more args: i32) = {} // : (out this, name: std::string, age: i32, next args: i32) = {} // : (out this, name: std::string, age: i32, ... -> args: i32) = {} // : (out this, name: std::string, age: i32, -> args: i32) = {} } var3: cls3 = ("Alex", 30, 1, 2, 3); For jagged arrays, multidimensional arrays and dictionaries, we will have: var1: std::vector<std::vector<i32>> = ((1, 2), (3, 4)); var2: matrix_2d<i32> = ((1, 2), (3, 4)); var3: std::vector<std::pair<std::string, i32>> = (("one", 1), ("two", 2)); And so on..., the type specifies the meaning of nested ()s. — Reply to this email directly, view it on GitHub<#637 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQKHRXJPPPUUCFM57EDYEBH7NAVCNFSM6AAAAAA4OKIH6WVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TKNBTGQ2DO>. You are receiving this because you commented.Message ID: ***@***.***>

[msadeqhe]

No, it doesn't require the constructor to be templated. But yes, it can be lowered to Cpp1's initializer_list type.

For example, if the syntax of variable arguments is like this:

cls1: type = {
    operator=: (out this, args: i32 -> ...) = {}
}

The type of args will be initializer_list<i32> in generated Cpp1 code.

The point is to have a special syntax to prevent bad API from happening because of initialized_list<TYPE> type in function overloading. But if it's reasonable to ban it without any special syntax:

cls2: type = {
    operator=: (out this, x: i32) = {}
    operator=: (out this, x: initializer_list<i32>) = {} // ERROR!
}

That's OK too (although syntactically it shouldn't be an error).

[AbhinavK00]

In that case, it would be just another way to spell the same feature. How does this prevent "bad" constructors?

[msadeqhe]

sry, English is not my native language, I mean it prevents the programmer from writing a constructor with wrong signature that otherwise it would lead to having bad API.

So in this case, the programmer cannot write a class similar to std::vector (which has two constructors with surprising results).

[SebastianTroy]

No, I mean, does the cpp1 have to be templated to achieve this safety? I believe that lowering to initialiser lists maintains the problem, and will allow the problematic constructors to compile regardless of the nice cpp2 syntax...? On 12 November 2023 09:13:53 Sadeq ***@***.***> wrote: No, it doesn't require the constructor to be templated. But yes, it can be lowered to Cpp1's initializer_list type. For example, if the syntax of variable arguments is like this: cls1: type = { operator=: (out this, args: i32 -> ...) = {} } The type of args will be initializer_list<i32> in generated Cpp1 code. The point is to have a special syntax to prevent bad API from happening because of initialized_list<TYPE> type in function overloading. But if it's reasonable to ban it without any special syntax: cls2: type = { operator=: (out this, x: i32) = {} operator=: (out this, x: initializer_list<i32>) = {} // ERROR! } That's OK too (although syntactically it shouldn't be an error). — Reply to this email directly, view it on GitHub<#637 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQIAJ7AZECTFSERX2QTYECHM3AVCNFSM6AAAAAA4OKIH6WVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TKNBUGI4DK>. You are receiving this because you commented.Message ID: ***@***.***>

[AbhinavK00]

if we use () we cannot call the constructor with list initialization in Cpp1

We can

auto a = std::vector({1,2,3,4,5,6});

The problem is that cpp1 prefers constructors with std::initializer_list instead of giving an error when encountering ambiguities.

[msadeqhe]

I mean:

auto a = std::vector(1, 2, 3, 4, 5, 6); // ERROR!

It never calls the constructor with list initialization.

EDIT: On the other hand:

auto a = std::vector{1, 2, 3, 4, 5, 6}; // OK.

It calls the constructor with list initialization, also it fallbacks to call other constructors with arguments 1 to 6 too.

[msadeqhe]

I mean {} was named Uniform Initialization but it hides constructors with special signature:

class X {
    public:
    X(std::initializer_list<std::string> li) { ... }

    X(std::string a) { ... }                // We cannot call it with {}
    X(std::string a, std::string b) { ... } // We cannot call it with {} too.
    X(std::string a, std::string b, std::string c) { ... } // We cannot ...
    // Also that's the same for other constructors with a sequence of `std::string` parameters.
};

The same problem exists in Cpp2... we don't have Uniform initialization yet.

[msadeqhe]

Although array literals (list initializations) and function arguments (constructor arguments) are mixed together, but we don't have Uniform Initialization. On the other hand if we don't have Uniform Initialization, we could have a distinct notation for Array Literals. But we don't have it too.

[AbhinavK00]

On the other hand if we don't have Uniform Initialization, we could have a distinct notation for Array Literals. But we don't have it too.

That's what I want too.

[SebastianTroy]

Because the compiler will detect the collision, initialiser_list is a library feature, we are suggesting a language feature because then the compiler can actually detect the collisions On 12 November 2023 09:24:52 Abhinav00 ***@***.***> wrote: In that case, it would be just another way to spell the same feature. How does this prevent "bad" constructors? — Reply to this email directly, view it on GitHub<#637 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQOWQECFYHUX6XAYSGLYECIWFAVCNFSM6AAAAAA4OKIH6WVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TKNBUGMZDO>. You are receiving this because you commented.Message ID: ***@***.***>

[SebastianTroy]

I don't see how the compiler can be expected to check that a library feature meets x, y, z requirements, I think it needs to be part of the language, whether that's a the cpp1 or 2 level On 12 November 2023 11:52:50 Abhinav00 ***@***.***> wrote: Cpp2 can have its own initializer_list which can be cast to std::initializer_list when required. OR what it can have is ARRAY LITERALS which can be cast to std:: initializer_list when required. — Reply to this email directly, view it on GitHub<#637 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQJBD2HL7MPUMSYQGXDYEC2A7AVCNFSM6AAAAAA4OKIH6WVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TKNBVGM4DE>. You are receiving this because you commented.Message ID: ***@***.***>

[msadeqhe]

The syntax

I'm trying to find some good options for the list initialization syntax as a language feature. I think contextual keyword next is a good fit here. The point is to have Uniform Initialization by restricting the signature of constructors, and to eradicate the surprising result of bad API design. Therefore a programmer can safely assume what will be constructored in generic code (instead of forcing the programmer to use a different syntax to call a special constructor).

Using next: TYPE => args

The advantage of this syntax is that it's visually aligned the impact of rest parameters to the left:

cls1: type = {
    //       : (out this, inout next => args) = {}
    //       : (out this, inout next: _ => args) = {}
    operator=: (out this, inout next: i32 => args) = {}
    operator=: (out this, inout abcd: i32) = {} // ERROR! Its signature is duplicated.
}

In which:

• next is a contextual keyword. If => is written after the parameter, next is a keyword, otherwise it's an identifier.
• next: TYPE means the type of next parameters are TYPE.
• => means redirection, so next parameters will be redirected to args parameter.

A keyword or another notation may be used instead of =>.

Using args => next: TYPE

The advantage of this syntax is that it's left to right:

cls1: type = {
    //       : (out this, inout args => next) = {}
    //       : (out this, inout args => next: _) = {}
    operator=: (out this, inout args => next: i32) = {}
    operator=: (out this, inout abcd: i32) = {} // ERROR! Its signature is duplicated.
}

In which:

• next is a contextual keyword.
• next: TYPE means the type of next parameters are TYPE.
• => means redirection.

Syntactically => may be removed (it's not necessary). Also a keyword or another notation may be used instead of =>.

How to fix a Cpp1 class with a bad API?

As @hsutter already stated, types such as std::vector can have bad API design (therefore it prevents Cpp1 to have Uniform Initialization feature).

Fix std::vector bad API in Cpp1

It needs a proposal, but it hopefully completely fixes the issue (not just for Cpp2, but also for all Cpp1 code).

But it would break so many source codes:

auto var1 = std::vector<int>{1, 2}; // [1, 2]

// OK. These lines don't have a surprising result.
// New constructor signature:
auto var2 = std::vector<int>{1, 2, true}; // [2]
// Or new static member function:
auto var3 = std::vector<int>.with_size(1, 2); // [2]

// WARNING! This constructor is deprecated and will be removed in the future!
auto var4 = std::vector<int>(1, 2); // [2]

But this approach needs a proposal to be accepted in C++ standard comittee, and perhaps it never will be accepted because of the breaking change.

Fix std::vector bad API in Cpp2

Cpp2 has UFCS, it can do the job of Extension Methods. But unfortunately we cannot add constructors and static methods to a type with UFCS. If Cpp2 has such a feature:

operator=: <T> (out this: std::vector<T>, count: size_type, value: T, tag: bool) = { /* ... */ }

We may use the new constructor or static method:

var1: std::vector<i32> = (1, 2); // [1, 2]

// OK. It doesn't have a surprising result.
var2: std::vector<i32> = (1, 2, true); // [2]

This approach would bring the next subject for discussion.

Surprising result of initialization in Cpp2

Currently a: TYPE = (...) and a: = TYPE(...) are not the same in Cpp2:

var1: std::vector<i32> = (1, 2); // [1, 2]
var2:  = std::vector<i32>(1, 2); // [2] SURPRISE!

To achieve Uniform Initialization and to eradicate the surprising result, Cppfront may transpile TYPE(...) to TYPE{...} in generated Cpp1 code. Thanks.

[msadeqhe]

I've created issue #823 from our discussion.

[HALL9kv0]

Is there any update regarding initialization with array literals?
I believe since the last comment on this thread, the [[ ]] has been freed, since it is no longer used in contracts.

Could we use them for array/vector etc literals? For example:

v : std::vector = [[1,2,3,4,5]];
vv: std::vector<std::vector<int>> = [[1,2,3 ; 4,5,6 ]];  //  2D
vvv: std::vector<std::vector<std::vector<int>>> = [[  [[1,2 ; 3,4 ]] , [[5,6 ; 7,8 ]]  ]];  //3D

Pros:

1. Clearly distinct from subscript operator [] or any other potential use of of [] in the future.
2. Distinct from the () constructor, does not use parentheses at all.
3. No other bracket style is used, so no mixing between { ( [ .
4. Reminiscent of the math matrix, for up to 2D.
   Just enclosing the array in the brackets

 [[1, 1 ; 
   2, 2 ; 
   3, 3 ;
   4, 4 ]];

5. Still clear for larger dimensions, since its only one type of bracket.

Cons: Double the brackets required for the 1-D arrays (4 instead of 2).