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