Metadata and uniform declarations

[joaosigma]

After reading the design specification I have the feeling that the language can become as verbose, and therefore as difficult, as C++ eventually became. For an initial design, there are already a lot of keywords, and (in my opinion) weird things like ! for generics: why are we negating them?

I think that (and I hope it isn't already too late), one should try and come up with a way to express all the different options that the language offers (and even future ones) in a more clean and easy way.

Taking into account that in Carbon, <> isn't used (well, at least not as in C++), why not use it to declare "metadata" in vars, classes, functions, etc.? For example:

var<f64> x2; //a f64 (double) var
var<auto> x3 = 10; //an inferred var
var<bool[3]> x4; //an array of 3 bools
var<bool[]> x5 = x4; //a slice? of bools

var<const, int32> x1 = 42; //a const int32 var

var<auto> kvpair = {.key = "the", .value = 27};

Forget about let, mut and other stuff. There's just var, that simple. We can change the behavior of that var by specifying options inside <>. There's no need to create a : operator to indicate the type.
Inside the <> scope, the options are not keywords, and user-defined types must be prefixed with : (or some other keyword).

For the hardcore C++ programmer, one could do:

alias auto = var<auto>;
:auto var_a = var_b; //copy

alias auto& = var<auto*>;
:auto& var_ptr = var_a; //ref

Also, I don't think that using <> would make the parser more complex, because the pair would have to come after var, class, fun, or whatever keyword that needs to be "configured".

Applying this design to classes:

class<> Foo;
class Foo; //same as previous line

If we want that class to extend another class and be abstract / base or sealed:

class<extends: Base, abstract> Foo
{ }

class<extends: Base, sealed> Foo
{ }

What about generics?

class<?T> Foo
{ }

I used ? instead of !: I think it's more readable because we simply don't know the type.
For example, a specialization:

class<?T: if int> Foo
{ }

Remove the impl as Data {}, just declare the class has being a POD (and also with packing alignment specified):

class<pod, pack: 1> Foo
{ }

To have the class be an interface:

class<interface> Foo
{ }

And what about functions?

fn sum(<f32, const> a, <f32, const> b) -> <auto>
{ 
	return a + b;
}

In the parameter list and return type, the var is implicit before the <> pairs.

A generic function, with a constraint, and also marked pure:

fn sum<?T: Arithmetic, pure>(<T> a, <T> b) -> <auto>
{ 
	return a + b;
}

Other stuff might include "tail return", "build: development", etc.

In class methods:

class Foo
{
	destructor<Self this, virtual>
	{ }

	fn toggle<Self this>()
	{ 
		this.enabled = !this.enabled;
	}

	fn check<const Self this>() -> <bool>
	{ 
		return this.enabled;
	}

	private var<bool> enabled;
};

The syntax allows us to "extend" declarations, like for example:

class Foo
{
	fn toggle<Self this>()
	{ 
		this.enabled = !this.enabled;
	}

	var<bool, private set> enabled; //make writing private
};

var<:Foo> bar;
var<auto> enabled = bar.enabled; //OK
bar.enabled = false; //error

More "random" stuff (geared towards gaming):

class<pod, simd, align: 16> Point //"simd" imposes constraints, like: members must be 1 character long
{ <f32> x, <f32> y, <f32> z }

var<Point> p1;
var<Point> p2;

p1.xyz = 2.0f;
p1.z = -p1.z;
p1.yzw = p2.xxx;

I could give more examples, but I think this is enough for the point I'm trying to make.

[geoffromer]

Taking into account that in Carbon, <> isn't used (well, at least not as in C++), why not use it to declare "metadata" in vars, classes, functions, etc.?

Carbon doesn't use <> as delimiters because the ambiguity between "open angle bracket" and "less than" creates serious parsing problems.

[joaosigma]

I have to admit that I didn't give much thought to tuple syntax, I just assumed that a tuple would be something like var<(i32, f32)>.
In the previous example (the syntax to decompose the tuple), it would have to be something like:

(var<i32> a, var<f32> b) = foo();

Granted, it's way more verbose, but doesn't break the logic: <> continues to be attached to var.
I haven't grasped the "irrefutable patterns" logic yet, but using the same example, can one declare b as let? Which would be equivalent to:

(var<i32> a, var<f32, const> b) = foo();

Another example is related to variants (as in std::variant), which I was a bit surprised not to see support for in the language. With my approach it would be rather simple, for example:

var<i32 or f32 or bool> variant;

[geoffromer]

I have to admit that I didn't give much thought to tuple syntax, I just assumed that a tuple would be something like var<(i32, f32)>. In the previous example (the syntax to decompose the tuple), it would have to be something like:

(var<i32> a, var<f32> b) = foo();

One problem with that syntax is there's no introducer, so the parser may have to dig arbitrarily deep to figure out what kind of statement this is.

Granted, it's way more verbose, but doesn't break the logic: <> continues to be attached to var. I haven't grasped the "irrefutable patterns" logic yet, but using the same example, can one declare b as let?

Yes, you can have a declaration like this:

var (a: i32, let b: f32) = foo();

or this:

let (var a: i32, b: f32) = foo();

Basically, the nearest enclosing var or let determines whether a binding is an l-value or an r-value.

Another example is related to variants (as in std::variant), which I was a bit surprised not to see support for in the language.

See the README section on choice types.

[jonmeow]

var (a: i32, let b: f32) = foo();

Minor correction here, but at least as the outcome of discussion so far, this must be written as your second form (let (var a: i32, b: f32) = foo();). var is allowed within let, but let is not allowed within var. Because var requires storage,var is the stricter requirement, and cannot be loosened with let.

[joaosigma]

Yes, you can have a declaration like this:

let (var a: i32, b: f32) = foo();

It's seems a bit like a hack, where the let outside is just to then introduce the tuple, no?

See the README section on choice types.

Sorry, missed that completely.

[geoffromer]

It's seems a bit like a hack, where the let outside is just to then introduce the tuple, no?

Yes, we allow the outermost let or var to act as the introducer, rather than requiring a separate introducer. Whether that's a "hack" is, of course, a matter of taste.

[geoffromer]

For the hardcore C++ guy

Could you please change that to "programmer"? C++ and Carbon programmers aren't necessarily "guys".

[joaosigma]

Sorry about that. Changed.

[geoffromer]

Thanks!