Why are arrays special?

[dpcollins-google]

There is a special syntax and implicit conversion for arrays, that at the same time feels both awkward and unfamiliar to me:

var a: [i32; 3] = (1, 2, 3);
var a: [i32;] = (1, 2, 3);

In addition, arrays have special rules where they implicitly convert from tuples, and don't need their size specified in the type.

My question is: why are we special casing arrays? In general, most use cases shouldn't be using raw arrays but some higher level container, and the presence of special syntax just for arrays feels like an unnecessary carryover from C.

I think one could build the interface (not the implementation necessarily) for arrays on generics and variadics by doing (as stated in the docs https://github.com/carbon-language/carbon-lang/tree/trunk/docs/design#checked-and-template-parameters)

class Array(T: Type, template N:! i64)
    if N >= 0 and N < MaxArraySize / sizeof(T) {
  ...
  val = <tuple of n elements of type T or magic compiler intrinsic>
}

fn MakeArray[T, template N:! i64 = sizeof...(T)](<variadic pack of T of size N>) -> Array(T, N) { ... }

// Usable like:

var a = MakeArray(1,2,3)

All the names are strawman syntax, but I think its worth asking whether arrays need to have a special interface different from other containers.

[jonmeow]

I think the special syntax is just because arrays are common. It's likely to be syntactic sugar for a library implementation (similar to what you're writing, although I don't think we've decided on names), not builtin. Making things syntactic sugar instead of builtins is generally a goal; numeric types are an another example where the language is essentially providing shorthand, such as i32 translating to Int(32) (theoretically, not implemented yet).

[dpcollins-google]

just because arrays are common

Right, so this is what I disagree with. Outside of very low level or memory constrained code, you will (in my experience) almost always be using a variable sized container (std::vector) not a fixed size one.

language is essentially providing shorthand, such as i32 translating to Int(32)

The i32 shorthand for a type doesn't break the expectations for what a type looks like. I'm not quite sure how I would write the type of an array in a generic context for example, because it looks so different from all other types.

[MichaelBonnet]

it's worth noting that a significant part of C++ use cases are low-level/memory-constrained.

[ncioj10]

@MichaelBonnet It could also be argued, that it is time to create a fast language whose purpose is not just the usual C++ scope, but broader and also in application domain like Java. I think Carbon bottom line might run into the problem of not being any innovation to C++ at all. Just slightly other syntax for some things.

[geoffromer]

One thing to bear in mind is that the array support in Explorer is a preliminary sketch; there isn't yet an approved design for arrays. The eventual proposal for arrays will need to address these questions.

With that said, part of the motivation is that we need a concise syntax to support the upcoming design proposal for variadics, which relies fairly heavily on unsized arrays of types. For that use case, array types will probably need to be given special treatment by the core language, and it's important for them to be pretty concise.

[dpcollins-google]

there isn't yet an approved design for arrays

Interesting, I look forward to the discussion!

variadics, which relies fairly heavily on unsized arrays of types

I didn't realize that "unsized array" or "dynamically sized array" was a first level concept, I thought array as stated was only the constant sized thing. I don't have an objection to a custom syntax for slices (pointer-length pairs), but think arrays (pointer length pairs allocated inline with a specific compile time size) are infrequently needed, and probably don't justify (in my mind) a custom syntax.