Some assumptions I personally would like you to add to the assumption list.

[YagaoDirac]

Different projects have different priorities, trade-off, assumptions. For Carbon, as a successor to c++, I would like to propose some personally preferred assumptions.
Some are mentioned in my earlier thread:
#1572

1, c++ is a glue language while provides possibilities for people to make heavily customized containers.
Carbon should also focus on this. This means, the default grammar set should target handling the glue jobs, while providing features for people to customize containers. When you decide the default grammar, I recommend the glue oriented ones.
(By the word "default", I assume that you would really make multiple grammar all in Carbon. I'll mention details later.)

2, Carbon is for experienced programmers to handle super heavy jobs. It's not for people to learn how to program.
Always consider the users as programmers who at least know a brunch of programming languages. Then, trivial grammar should not be any problem for them. They can adjust to almost any grammar easily.
I personally have confidence to start using any high level language in 2 hours, or any c++ level languages in 3 days. Since most cases can be handle with the simplest grammars in almost all the languages and all the grammars follow similar patterns.
The trivial grammar is the only thing I recommend you to choose for people. I'll mention more in 5, and 6,.
I just read some other thread in discussion page, I found some ideas seem likely to be from inexperienced people. I don't want to offend anyone, but the project should not be for inexperienced people. It should be friendly to experienced programmers since heavily customized containers do need a lot knowledge to make.
If something is too classic and really easy to search on Google, it doesn't surprise experienced programmers. Use it.

3, Code is not only a text file. Auto completion is the most important tool.
Text is easy to maintain, but it's too limited. Now we have so many powerful IDEs, we should utilize them to enhance features especially readability and auto completion. I would like to emphasize auto completion, it's too important. All the features should be regular enough to ensure the auto completion can work efficiently and correctly. Also, auto completion should be in the language specification. Auto completion should also contain all the possible operators at a given position.

4, Programmers speak a variety of languages and they all need to search for help, individually.
Always prefer searchable keywords than symbols. Unless it's too classic.
Always make sure English native speakers at 10 yo can search for help all by themselves. For non native speakers, English is also a time consuming thing to learn, and they are many.
I admit this may conflict the readability somehow. Maybe we shouldn't decide so early.

5, The official language team should not choose for programmers (that much).
I really appreciate all the researching you have done, but this should only be "default", not the "only". You should also keep different grammars for programmers to choose. I mean, you need to provide multiple grammars and separate them.
Theoretically every grammar is a feature. Now the conception of feature space is not accepted by people but I know it's gonna be a thing.
I read some threads here and I found people really have different preference of some basic grammar. Like:
var a:int = 42;
var a int = 42;
int a = 42;
Some reasons are provided but I didn't find any interesting reason. Alignment is not a good reason, since if IDE feature is also part of the project, it's possible to do anything to solve this.
But, my opinion is that, you should not choose for people. Let them choose.
Again, this is where feature space(I used to call this feature scope) helps.
example:
{
scope.var_parsing(some enum::cpp);
int a = 42;//OK
}
{
scope.var_parsing(some enum::carbon);
var a:int = 42;//OK
}
Then all are happy. Years later, you'll see which people prefer. Also, it's possible to add new grammar if 10 years later, if a now fashion comes, without breaking old code or forcing a upgrade to the old code.
This can also handle the function definition style.
example:
{
scope.fn_parsing(some enum::cpp);
int foo(){}//OK
}
{
scope.var_parsing(some enum::carbon);
fn foo(){}//OK
}
This even helps when people decide to use some different inheritance or mixin logic. Also, the swizzling(object.xyz) feature.
example:
{
scope.enable_swizzling(true);
a.xyz = b.yzx + c.zxy;//OK
}
In Odin, this works only for array with only 4 or less elements. But if we can customize feature space, we can apply it also to members.
Also, since macros seem not friendly to auto completion, yeah, maybe we should have scope.enable_macro(false).

6, Allow programmers to customize the inheritance-like logic. (Another aspect of "don't choose for people, let them choose".)
For me, the relationship among traditional inheritance, new mixin, and composition, is very similar to std::vector, std::deque, and std::list. They are all good, useful in some cases. I appreciate c++ because it exposes so many features for people to mess around, thus we have the Google version of unsorted_map which is way better that the std one.
Also, for programmers on video games, we have FName, FString, and FText all in Unreal Engine to handle strings by different means. Also, quaternion, Eular angle, and rotation matrix to handle rotation. They are all great tools. If this language is truly for experienced programmers, you should trust them and let them decide which inheritance-like pattern they are gonna use.
(I personally call this the c++ philosophy :)
Also, this part should also be done with plain Carbon grammar. Never introduce specific grammar for this part. Typescript already messed with this.
Idk if this also handles the concepts and constrains part in Carbon.

Some off topic comments:
I remember some of you mentioned meta programming. I think c++ provides some meta editing, like, const, static, volatile, inline, etc. But it's only editing, like check a check box in an editor. It's not programming. Maybe we should have something like:
class a{}
meta_var class_a = meta.get_class();
class_a.add_field("b", type::i32, composition::back);
a.b = 42;
But this way doesn't allow any adjustment to be done before "class a{}". So maybe we need:
meta_var class_a = meta.add_class("a");
class_a.private();
class_a.add_field("b", type::i32, composition::back);
a.b;//Error, b is private.
Then, wait for people to make the standard inheritance(or mixin or composition) library for you. :)

[MrScriptX]

I really like the idea of being able to choose which grammar we want to use, however, I'm not to keen on the assumption that Carbon is for experienced programmers.

I'm going to use my personal experience here. I started programming with C and then moved on to C++ shortly after. They were great starting points for many reasons that I won't list here but to simplify : simple concepts are simple to understand, use and visualize. I think it's a showcase of how well-designed those languages were for those simple concepts.

So rather than assuming only experienced programmers will use carbon, we should let beginners try carbon and see how they do with it as it would be a good indication on how well the language is design. Kind of similar on how you would test a new UX.

(It is also why I would advocate for cpp grammar style (easier to read, understand and learn). But not really the subject of this discussion.)

[YagaoDirac]

Yeah, glad to see any reply. No offense, it really needs tons of knowledge to use the newest features. Also, if you have only learnt c and c++, I highly recommend you try other languages, at least python and javascript, and you'll know the "var a:int = 42;" better. It's indeed much better. This grammar pattern is still trivial. No matter which they choose, it does the same thing. When it comes to inheritance, mixin, composition, esc pattern, data oriented programming, customized memory managing, new programmers would feel super painful.
Yeah, still I would encourage you to comment more since the community should know where people find it painful even if they had tried super hard and it's still painful.
Btw, I personally think python(the basic content) and lua(without its built in regularity expression) are most new programmer friendly. You probably feel very easy when learn them and they shouldn't cost you very much time. Give them a try.

[MrScriptX]

I have become a fully fledged software engineer since the time I first discover C (got my diploma this year, yeah). So I do know and use those languages. I know that newest C++ features needs more knowledge. But some are heavily criticized. Moreover, it's normal for more advance concepts to be harder to use or understand. It just needs to feel natural. Ideally, the learning curve for a language should match the learning curve of the concepts used or be lower if it doesn't interfere with natural flow of the language. Of course this is just to give a good direction, it doesn't have to be the absolute rule. I just feel that in general, if you use something and you can't comprehend how it works (which means how to use it well), then there is something missing that should be there before as a stepping stone.

So yes, python and lua are easy to get your hands on, but they abstract way to many things to be a good learning material. I've seen this with some of my class mates who used to javascript or python as their first language. They lacked a lot of what I would consider basic knowledge. Well, they are scripting language, more than programming ones.

var a:int = 42; is fine. I have nothing against it, really. I just feel that int a = 42; looks less like sorcery. But might be because I started with C, so I'm more accustom to that syntax.

[YagaoDirac]

The most sorcery might be python if I didn't mess with memories. Variables in python don't require declaration. I learnt python after c++, js/ts, lua, and it was still able to confuse me a bit. But generally, if a programmer is trained enough, all these syntax should all be at least ok.

Another detail. I think if a language is successful enough is mainly about the cp ratio. Production over cost. c++ costs a lot and gives enough. Python cost way less while a better cp ratio but it caps too early. Such unavoidable trade off choices leads to all the staffs including this project. My opinion is that, Carbon can cost super much, but it has to maintain a cp ratio which is good enough. Imo, cp ratio of c++ is already low enough, it should not be very hard to go beyond it.

Btw, I personally call c++ a container language. I personally call c, hlsl, glsl, odin computational language. Then js/ts, py, lua, glue language. So, for now, c++ is the only container language. This is only personal opinion.