Before you go any further, learn Ada.

[jmccabe]

The US DoD spent loads of money on the design and implementation of the Ada language, which was released for public use just under 40 years ago. Its design solved numerous problems inherent in the existing languages of the time, many of which continue in C++ and the languages that try to retain C++ style syntax.

I'm not suggesting that you abandon the project and use Ada instead (although that probably wouldn't be a bad idea) but, having used Ada myself for a number of years before moving to C++, I find it shocking that the C++ community seems to be so happy to get half-baked new features added to the language rather than sorting out the fundamental inadequacies of the core language.

There are a number of Ada features that just make your job as a software developer easier, more reliable and clearer. The ones I particularly care about are:

Enumerated types.

In particular:

1. Differentiation between value/representation, and position
2. Being able to use them as the index type in an array (see also "Arrays")
3. Being able to reference them using attributes, e.g. 'first. ' last, etc.
4. 'image providing a string representation of the enumeration literal

C++''s enum class is such a dreadful let-down!

Any C/C++ programmer ought to recognise at least some of these as being things that require messing about with legacy constructs to achieve. Programmers shouldn't need to put up with that nonsense in this day and age.

Arrays

Definition of user-defined array types that are incompatible with each other, i.e. strong typing, not type aliases.

Definition of array types where the start index is NOT zero; "off-by-one" remains a huge problem when dealing with arrays, for no other reason than C arrays (and, hence C++ and multiple other languages) are like this because it made the compilers easier to write.

Arrays indexed by any discrete type (i.e. Including enumerated types).

Being able to use properties of an array, e.g. value of start index, value of last index, range etc.

std::array in C++ is such a dreadful let-down!

Named Parameter Association

Obvious; allow parameter names to be given at a function call site to aid readability, and to improve the flexibility of defaulted parameter values (no need for them to be at the end of the list, and you can genuinely skip ones you just want to use the default of)

User-defined Numeric Types that ARE NOT multiples of 1 byte

The language should support types that genuinely represent the range of a property without the programmer needing to mess about trying to check etc

This includes wrap-semantics on arbitrary width types ("modular types" in Ada.

Reliable And Consistent Representation Definitions

This is really more geared at embedded systems but, since C++ is quite widely used in those, it should be easy to define portable representations of the structure of 'objects' (e.g. equivalent of fields size declarations, but better defined behaviour on fields that cross byte or word boundaries etc - see "record representation clause" in Ada, but also pay attention to representation clauses in general).

Avoid keyword duplication

I.e. Don't use the same keyword with different semantics depending on context

Avoid too many symbols & their reuse

Don't just use &, *, && all over the place 'because that's how C++ does it'.

Also, as mentioned elsewhere, fix the '=' / '==' nonsense by 1) defining a new assignment operator, 2) use '=' to mean 'is equal to' and 3) don't allow assignment in conditions

Make short-circuiting conditions explicit (see Ada's 'and then' and 'or else' conditions)

Make Bool a first-class type

Do not allow implicit 0 -> false, non-zero -> true conversion.

There are many more, but..

Ultimately, every single point I've mentioned here has been about making life easier for the programmer, and making it harder for them to screw up with common mistakes. If compilers developed 40 years ago are capable of all this, modern compilers and languages should be providing core features to achieve this; it shouldn't be the responsibility of a 'template library' to do that.

[jonmeow]

We don't want our forums to be used for language debates. You can praise features of Ada without insulting C++, and when you use aggressive words, that doesn't belong in our forums. For reference, please see the code of conduct. https://github.com/carbon-language/carbon-lang/blob/trunk/CODE_OF_CONDUCT.md

Our team is aware of Ada. I think that most of your comments reflect areas that we haven't fully designed out, but I'll give a few quick comments.

Choice types are likely going to be provided instead of enum types, and they'll have different flexibilities. We're thinking through array and slice design to make them easy to use and efficient. We're trying to be conservative on casts to prevent errors, but I don't know which way int->bool casts are heading off the top of my head.

However, bear in mind we're trying to convert C++ use-cases. A lot of C++ developers are very comfortable with =/==, and there's a lot of good reasons to support assignment in conditionals in order to limit variable scopes. The nuances of syntax and error detection may be what matters more than Ada's specific choices in these areas.

[jmccabe]

Jon

Can you please specify where I've used "aggressive words"? Having re-read my comment, unless you've edited it, there are no words in there that I consider aggressive, so your help would be appreciated.

I'd be interested in hearing more about what you mean by "choice types". It's worth remembering that, even in Ada, enumerated types are a fundamental type and are there because there is a genuine need to be able to specify and use that kind of thing. Your brief description of "choice types" makes me think you're going to end up with something that's more flexible, extendable etc etc, but more complicated (i.e. hampers the development of tools that help prove your implementation is safe) and less performant.

I am pleased your team are aware of Ada but, if it hasn't already been done, please take the time to read through and understand its history, its requirements, its design and its development before continuing to plough on and reinvent C/C++/Java/C# etc with slightly different syntax. Enumerated types are a prime example of where it's easy to see how you may be able to improve things but, in doing so, you could quite easily compromise the ease of use and performance of your language.

FWIW, at this point I'm probably going to step back as, TBH, this whole project just appears to be Google trying to detract from Rust (and, at this point, we really need less language fragmentation, not more) but, before that, I just need to reiterate something I've said on another discussion. I've been developing software professionally since 1987. In that time, I've seen languages come and go, but I've also seen that, for those languages that have managed to keep going, the time from inception to becoming fully accepted and 'mainstream' is in excess of 10 years. From my point of view, that means that a 'new' language should be aiming to make it easy for future developers to write safe, robust, understandable and performant code so justifying design choices on what current developers are comfortable with, even when there are numerous, known, good reasons to avoid the same mistakes, is complete anathema to me.

Thank you for your time.

[cjdb]

I have locked this conversation, as it uses both aggressive language, and has started a language debate, neither of which we wish to cultivate in this community. For reference, please see the code of conduct.

Examples of aggressive language:

I find it shocking that the C++ community seems to be so happy to get half-baked new features added to the language rather than sorting out the fundamental inadequacies of the core language.

We don't allow jokes or generic complaints about programming languages. Those are off topic and make our community less friendly.

There are obviously changes that we'd like to make to C++, but calling C++ "half-baked" is demeaning to those who have invested years of work into that project.

TBH, this whole project just appears to be Google trying to detract from Rust

This is disrespectful to everyone working on the Carbon Language project. While we are open to criticism of the design of the language, it isn't okay to question people's motivations. Both the Carbon Language README and FAQ state that if an existing programming language meets your needs, then you should ignore Carbon and use that instead (with the latter explicitly addressing Rust).