8 ms·

Why use Rust syntax (fn, x:Type, ...)? Syntax is one thing that is not so well-designed in Rust (in my opinion). Also, with the stated goals, it seems a bit u

Why use Rust syntax (fn, x:Type, ...)? Syntax is one thing that is not so well-designed in Rust (in my opinion). Also, with the stated goals, it seems a bit unnecessary to overhaul C++ syntax, but then I found no explanation why syntax was changed. So what's wrong with C++ syntax if your goal is a successor of C++? This now looks to me like a Rust-- instead of a C++++, which is a picture they might not want to give rise to. Because then I'd rather use Rust instead, which then feels like the real thing(tm). [EDIT: If you think about downvoting, maybe answer instead as I am genuinely interested in this syntax question. I am not trying to be negative, it was just an observation and a question.]

notriddle 4y ago
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 lexer hack and most vexing parse aren't problems, but when the program isn't complete, parsing isolated fragments is impossible, and that limits the amount of useful tooling the language can have.
- beeforpork 4y ago
  OK, I see. Yes, C and C++ syntax is definitely ambiguous without semantic analysis. Maybe this could also be explained somewhere.
- cyber_kinetist 4y ago
  And to add, the `name: Type` syntax is not just a modern fad, don't forget the OG language that did this: Pascal! (https://en.wikipedia.org/wiki/Pascal_(programming_language) https://en.wikipedia.org/wiki/Pascal_(programming_language))
- c-cube 4y ago
  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 harder to do when you have a type declaration on the left imho.
  - nyanpasu64 4y ago
    It would make sense if Carbon started allowing omitting ": Type", which they currently don't: https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/variables.md#overview https://github.com/carbon-language/carbon-lang/blob/trunk/do...
  - amai 4y ago
    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
    - notriddle 4y ago
      > I claim writing the type before the name is much more readable. Compare I claim writing the name first is much more readable. Compare integer five = 5 or five: integer = 5
- kzrdude 4y ago
  There is a lot of Rust in the Carbon syntax. `fn`, `name: Type`, `i32`, `->` for return type. `impl` as a keyword. `Self` as a keyword. Nothing unique to Rust, but it's interesting to see.
dangets 4y ago
A blog post by Roman Elizarov (Kotlin designer) on the observation of types following the variable name [1]. It mostly states that having consistent length prefixes (fn, val/var) makes the code more readable than arbitrarily long type identifiers (in the eye of the beholder). Not scientific, but interesting. [1] https://elizarov.medium.com/types-are-moving-to-the-right-22c0ef31dd4a https://elizarov.medium.com/types-are-moving-to-the-right-22...
- kupiakos 4y ago
  Fixed prefixes also make a codebase significantly more grep-able. Want to find the definition of the function named `foobar`? Search `fn foobar` and that will always match, no regex required.
  - renox 4y ago
    Only if you use a code formatter (which you should) because otherwise there will be some 'fn foobar'(two spaces or more) just to annoy you..
dixego 4y ago
From the "Why build Carbon?" section: > The best way to address these problems is to avoid inheriting the legacy of C or C++ directly, and instead start with solid language foundations like a modern generics system, modular code organization, and consistent, simple syntax. That last part seems to imply that the authors don't consider C++ syntax to be a good foundation for a modern successor language, so they chose to change it. As to why change it in a Rust-like direction I'd imagine that it's both because it's what fashionable at the time and possibly to attract people who are already familiar with that style.
- ArrayBoundCheck 4y ago
  They could have went the C# route, but didn't
Koshkin 4y ago
Indeed, syntax only a mother could love. (Swift, I am looking at you, too.)
jimbob45 4y ago
I can't handle [] syntax for generics. It makes code unreadable as far as I'm concerned because it makes it twice as difficult to know if I'm dealing with an array indexer or a generic. The rest I can excuse but [], I cannot. Same reason I won't touch Nim.
- xigoi 4y ago
  I can't handle <> syntax for generics. It's impossible to auto-pair and looks ugly. The real solution is [] for generics and something else for indexing.
  - renox 4y ago
    When looking for eleguant solutions: look at D, it's full of pearls: they use !() for generics.
  - wtetzner 4y ago
    Using function call syntax for array indexing always made sense to me. Functions are mappings from inputs to outputs, and arrays are mappings from indexes to values.
    - xigoi 4y ago
      I agree, but explain that to programmers who think parametric polymorphism is too complex.
      - int_19h 4y ago
        Given that one of the languages that historically used the same syntax for array access and function invocation since day one is BASIC, I would dare say that it's not a complicated concept.
yakubin 4y ago
Go authors put out a good post explaining the problem with C syntax and contrasting it with Pascal/Go/Rust syntax: <https://go.dev/blog/declaration-syntax https://go.dev/blog/declaration-syntax>
qalmakka 4y ago
C and C++ are infamous for being harder to parse than it's reasonable. C has lots instances of context dependent syntax where code changes meaning depending on what a name is. You can parse Go without a symbol table, but not C, because stuff like item *a; changes completely in meaning depending on the existence of a previous typedef for `item`. C++ in order to not break compatibility with C has elevated this to insane extremes - there's so much ambiguous syntax in the language. x = b.get<item>(r); This expression can either be a function invocation, if `item` is a type and a template method named `get` exists, or else it's a series of comparisons. item f(r, f); is also ambiguous: if r and f are types, that's a function, otherwise that's a variable declaration. There's no way to know that unless you have a symbol table, which makes separating syntactical and semantic analysis impossibile at best. The whole C++ language is full of similar ambiguities, and attempts to fix warts that backfired spectacularly. That's also the reason why writing a C++ frontend is a decade long endeavor that takes lots of people and resources. A full time team of 3 people can probably write a C parser in a few weeks in comparison, and C is big mess too, albeit a smaller mess though.
ModernMech 4y ago
C++++ is C# (notice how the four pluses can be arranged to form a #) C#++ would be the next one, but I'd pull what Microsoft did to Windows 9 and skip right to C##.
- Tyr42 4y ago
  Knowing my music theory though, C## is just D.
  - deleted 4y ago
    [deleted]
  - holysantamaria 4y ago
    not sure on this one, on my keyboard there is a halftone to get D from C so I believe it's more C# = D ?
mkehrt 4y ago
While I think rust has some serious issues with syntax (and I love rust), the things you've pointed out here are not rustisms, but programming language theory-isms. x:Type has been used in MLs (SML, Ocaml) and recently TS. Haskells uses x::Type. This usage dates back to at least the simply typed lambda calculus in the 1930s. fn and fun are used in SML and probably elsewhere. fun is used in OCaml, as well.

notriddle 4y ago

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 lexer hack and most vexing parse aren't problems, but when the program isn't complete, parsing isolated fragments is impossible, and that limits the amount of useful tooling the language can have.

beeforpork 4y ago
OK, I see. Yes, C and C++ syntax is definitely ambiguous without semantic analysis. Maybe this could also be explained somewhere.
cyber_kinetist 4y ago
And to add, the `name: Type` syntax is not just a modern fad, don't forget the OG language that did this: Pascal! (https://en.wikipedia.org/wiki/Pascal_(programming_language) https://en.wikipedia.org/wiki/Pascal_(programming_language))
c-cube 4y ago
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 harder to do when you have a type declaration on the left imho.
- nyanpasu64 4y ago
  It would make sense if Carbon started allowing omitting ": Type", which they currently don't: https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/variables.md#overview https://github.com/carbon-language/carbon-lang/blob/trunk/do...
- amai 4y ago
  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
  - notriddle 4y ago
    > I claim writing the type before the name is much more readable. Compare I claim writing the name first is much more readable. Compare integer five = 5 or five: integer = 5
kzrdude 4y ago
There is a lot of Rust in the Carbon syntax. `fn`, `name: Type`, `i32`, `->` for return type. `impl` as a keyword. `Self` as a keyword. Nothing unique to Rust, but it's interesting to see.

dangets 4y ago

A blog post by Roman Elizarov (Kotlin designer) on the observation of types following the variable name [1]. It mostly states that having consistent length prefixes (fn, val/var) makes the code more readable than arbitrarily long type identifiers (in the eye of the beholder). Not scientific, but interesting. [1] https://elizarov.medium.com/types-are-moving-to-the-right-22c0ef31dd4a https://elizarov.medium.com/types-are-moving-to-the-right-22...

kupiakos 4y ago
Fixed prefixes also make a codebase significantly more grep-able. Want to find the definition of the function named `foobar`? Search `fn foobar` and that will always match, no regex required.
- renox 4y ago
  Only if you use a code formatter (which you should) because otherwise there will be some 'fn foobar'(two spaces or more) just to annoy you..

dixego 4y ago

From the "Why build Carbon?" section: > The best way to address these problems is to avoid inheriting the legacy of C or C++ directly, and instead start with solid language foundations like a modern generics system, modular code organization, and consistent, simple syntax. That last part seems to imply that the authors don't consider C++ syntax to be a good foundation for a modern successor language, so they chose to change it. As to why change it in a Rust-like direction I'd imagine that it's both because it's what fashionable at the time and possibly to attract people who are already familiar with that style.

ArrayBoundCheck 4y ago
They could have went the C# route, but didn't

Koshkin 4y ago

Indeed, syntax only a mother could love. (Swift, I am looking at you, too.)

jimbob45 4y ago

I can't handle [] syntax for generics. It makes code unreadable as far as I'm concerned because it makes it twice as difficult to know if I'm dealing with an array indexer or a generic. The rest I can excuse but [], I cannot. Same reason I won't touch Nim.

xigoi 4y ago
I can't handle <> syntax for generics. It's impossible to auto-pair and looks ugly. The real solution is [] for generics and something else for indexing.
- renox 4y ago
  When looking for eleguant solutions: look at D, it's full of pearls: they use !() for generics.
- wtetzner 4y ago
  Using function call syntax for array indexing always made sense to me. Functions are mappings from inputs to outputs, and arrays are mappings from indexes to values.
  - xigoi 4y ago
    I agree, but explain that to programmers who think parametric polymorphism is too complex.
    - int_19h 4y ago
      Given that one of the languages that historically used the same syntax for array access and function invocation since day one is BASIC, I would dare say that it's not a complicated concept.

yakubin 4y ago

Go authors put out a good post explaining the problem with C syntax and contrasting it with Pascal/Go/Rust syntax: <https://go.dev/blog/declaration-syntax https://go.dev/blog/declaration-syntax>

qalmakka 4y ago

C and C++ are infamous for being harder to parse than it's reasonable. C has lots instances of context dependent syntax where code changes meaning depending on what a name is. You can parse Go without a symbol table, but not C, because stuff like item *a; changes completely in meaning depending on the existence of a previous typedef for `item`. C++ in order to not break compatibility with C has elevated this to insane extremes - there's so much ambiguous syntax in the language. x = b.get<item>(r); This expression can either be a function invocation, if `item` is a type and a template method named `get` exists, or else it's a series of comparisons. item f(r, f); is also ambiguous: if r and f are types, that's a function, otherwise that's a variable declaration. There's no way to know that unless you have a symbol table, which makes separating syntactical and semantic analysis impossibile at best. The whole C++ language is full of similar ambiguities, and attempts to fix warts that backfired spectacularly. That's also the reason why writing a C++ frontend is a decade long endeavor that takes lots of people and resources. A full time team of 3 people can probably write a C parser in a few weeks in comparison, and C is big mess too, albeit a smaller mess though.

ModernMech 4y ago

C++++ is C# (notice how the four pluses can be arranged to form a #) C#++ would be the next one, but I'd pull what Microsoft did to Windows 9 and skip right to C##.

Tyr42 4y ago
Knowing my music theory though, C## is just D.
- deleted 4y ago
  [deleted]
- holysantamaria 4y ago
  not sure on this one, on my keyboard there is a halftone to get D from C so I believe it's more C# = D ?

mkehrt 4y ago

While I think rust has some serious issues with syntax (and I love rust), the things you've pointed out here are not rustisms, but programming language theory-isms. x:Type has been used in MLs (SML, Ocaml) and recently TS. Haskells uses x::Type. This usage dates back to at least the simply typed lambda calculus in the 1930s. fn and fun are used in SML and probably elsewhere. fun is used in OCaml, as well.