Earlier quoted context omitted.
Indeed, from Python to Rust and newer C++ codebases you usually see CamelCaseClasses (or structs) and then snake_case for functions methods etc, which improves readability. CamelCaseForEverything is such a waste, maybe they use it for implicit public/private as in Go? And maybe to please existing Go or Java users?
That's PascalCase. camelCase is like this.
Carbon Language: An experimental successor to C++
511–520 of 521 posts
Re: Carbon Language: An experimental successor to C++
#512Earlier quoted context omitted.
You already have them, true it is more than one and isn't bullet proof, still it is way better than not using them.
Sorry, I wasn’t as clear as I meant to be. I was specifically thinking about things like Rust lifetimes being a compiler warning level instead of an absolute.
Re: Carbon Language: An experimental successor to C++
#513Earlier quoted context omitted.
> A key example of this is the committee's struggle to converge on a clear set of high-level and long-term goals and priorities aligned with ours [ https://wg21.link/p2137 ]. I was frankly shocked by that goals and priorities document. The non-goals section reads like an open declaration of war against anyone whose use cases for C++ differ from GOOG and NVDA. My interpretation of Carbon is that since GOOG failed to t…
(one of the Carbon leads) Success for the Carbon Language requires it to successfully be an independent and community driven project. We may not succeed (this really is an experiment), but we're working hard to engage broadly and early in large part because of this being such an important goal and priority for us. Projects like this have to start somewhere, but can grow and become community endeavors. We are also alr…
Re: Carbon Language: An experimental successor to C++
#514Re: Carbon Language: An experimental successor to C++
#515Earlier quoted context omitted.
It's not just Rust syntax. `name: Type` is the syntax used in TypeScript and Python type annotations (also Ocaml, which is probably where Rust got it from). Golang drops the colon, but still keeps the name first. As for what's wrong with `Type name(constructor, args)`? A lot of tooling wants to be able to parse "mostly-valid C++", like IDEs and compiler diagnostics. Sure, once clang's type inference is finished, the…
The syntax `name: Type` is also friendlier to type inference as you generally have a token indicating a declaration. If you have `var x: Type = …` then you can just omit the type and let inference do its job. Even better, when you start having more complex patterns on the left-hand side of `=`, you can type annotate them as you want. Hypothetical syntax would be: var (x: f32, y, [z1,z2,z3]) = SomeExpression(); That's…
five: integer = 5
or integer five = 5Re: Carbon Language: An experimental successor to C++
#516Earlier quoted context omitted.
Example of some well-written code that expresses things that can only be expressed in C++?
I'm far from the most experienced in C++, but friend classes/functions do not seem to have a direct equivalent in any other language.
Re: Carbon Language: An experimental successor to C++
#517Earlier quoted context omitted.
The syntax `name: Type` is also friendlier to type inference as you generally have a token indicating a declaration. If you have `var x: Type = …` then you can just omit the type and let inference do its job. Even better, when you start having more complex patterns on the left-hand side of `=`, you can type annotate them as you want. Hypothetical syntax would be: var (x: f32, y, [z1,z2,z3]) = SomeExpression(); That's…
On the other side `name:Type` doesn't allow an IDE to suggest a name based on the type, because you type the name first. Also setting values looks pretty confusing. I claim writing the type before the name is much more readable. Compare five: integer = 5 or integer five = 5
I claim writing the name first is much more readable. Compare
integer five = 5
or five: integer = 5Re: Carbon Language: An experimental successor to C++
#518Earlier quoted context omitted.
(one of the Carbon leads) Success for the Carbon Language requires it to successfully be an independent and community driven project. We may not succeed (this really is an experiment), but we're working hard to engage broadly and early in large part because of this being such an important goal and priority for us. Projects like this have to start somewhere, but can grow and become community endeavors. We are also alr…
Will Carbon natively support exceptions or is it solely going the Rust `Result ` route ?
Re: Carbon Language: An experimental successor to C++
#519Earlier quoted context omitted.
Example of some well-written code that expresses things that can only be expressed in C++?
I'm far from the most experienced in C++, but friend classes/functions do not seem to have a direct equivalent in any other language.
Re: Carbon Language: An experimental successor to C++
#520Earlier quoted context omitted.
Like the standard library - they don't plan to support exceptions.
Oh, that's excellent and interesting news - not a fan of exceptions. I'm not sure how that's going to work with interop when libraries rely on exceptions though. Where did you hear about this? I'd love to know more.