Questions about rust

Sorry for the questions so pardon me for asking but...

Why does rust use type names after the variable or function identifier?
let a:i32 = 0
Instead of?...
i32 a = 0;

And why does rust use array indexing like...
let a:[i32,5] = [0,1,2,3,4] and let a[5,5]
Instead of something like?...
i32[5] a = {0,1,2,3,4} and i32[5] a = 5

both c style syntax take less effort to write and is more familiar to c and c++ programmer.
is there a reason that this style is used and will rust ever be changed or a option for c style?

1 Like

I don't know the reason behind Rust's design specifically, but here's some discussion on the topic of right-hand type placement (not Rust specific) on StackOverflow.

The effort and familiarity is a matter of preference and what you're use to. Use Rust or the other languages in that thread enough and you'll get used to it. It won't be changed and can't reasonably be an option, either (modulo some token-rearranging proc macro that everyone else would hate to run into) -- backwards compatibility, churn the entire world, etc etc.

2 Likes

Do you think the devs would possibly add a c style flag being emitted to the compiler for c programmers
or do you think that would be too much effort for reward when it comes down to actually adding it to the compiler and making it backward compatible?

I don't think there would every be anything official, no. Both too much effort, and I'm sure they're not interested in promoting a split in the ecosystem. Maybe someone else motivated enough could make some macro or other translator, but again, anyone outside the niche would hate to run into it.

(I have an example in mind of someone doing this in C that I'm going to try and dig up...)

Because Rust is designed to be written with type inference. So you almost always just write let a = 0; and don't mention the type.

10 Likes

Why bother? Rust is not C and should not pretend to be C. It's a completely different language with different syntax, semantics, and much more. There's no reason to force syntax into Rust.

5 Likes

I can’t comment on the specific design of the Rust syntax, but the general idea is that the keyword introducing a new variable defines its storage duration or memory allocation (let, static, const). For local variables (let), you don’t normally need to specify the type at all.

As a long time C/C++ programmer, defining arrays that way looks no less alien than the Rust syntax. In particular if I saw i32[5] a = 5 without context, I’d be quite confused. I’m a sample size of 1 though.

This is a matter of opinion. Both C++* and Rust provide longer and more abbreviated ways of defining variables. In practice I feel like I’m typing less in Rust, at least where variable definitions are concerned.

[* I don’t think C is a fair comparison, since it lacks type deduction, namespaces/modules, generics, etc.]

I hope not! Whatever the benefit might be, it wouldn’t be enough to justify breaking existing code, or to complicate the language and compiler to support a double syntax.

3 Likes

well you have to type more when you actually supply the type when the type comes after and something like var, auto or let could be used for when you don't want to specify anything

I think there are plenty of reasons to use type first syntax..

  1. again it requires less typing (usully)
  2. most likely more known due to c and c++ being the standard
  3. may be my opinion but its more readable when declaring arrays if its part of the type (guess this wouldn't be c though more or C#)

For an example of why it's a bad idea to even fudge this which you may be more sympathetic to, the Bourne shell code used to use a set of C macros that let the programmer pretend they were programming in ALGOL 68. Imagine you, someone used to C, ran into a C program that looked like ALGOL 68. Oh, and the boss says please fix these bugs...

It ended up being one of the inspirations behind the IOCCC.

7 Likes

again it requires less typing

Rust requires a bit of typing — what's wrong with that? C uses function instead of Rust's fn, is that a negative? I certainly don't think so. In the vast majority of situations you don't have to type out the type of a variable, nor do I even have to think about it. Sometimes it is literally impossible to declare a concrete type!

most likely more known due to c and c++ being the standard

As I stated, Rust is not C, and does not care what C/C++ do syntax-wise. Rust is an ML-style language, not C-like. Rust has a high learning curve; type ascription is far from the largest thing to get used to.

may be my opinion but its more readable when declaring arrays if its part of the type (guess this wouldn't be c though more or C#)

Absolutely that's an opinion, and one I very much disagree with. I can type let x = [1, 2, 3, 4, 5]; and not have to worry about the concrete type. It's immediately obvious that it is an array, and has no ambiguities to the reader.


The simple answer to your question is inference. There is pretty much zero chance that this will ever be changed in Rust. If you sincerely feel that it's better, write an attribute macro that flips the syntax around. Just be aware that doing so would be highly unidiomatic and likely not used by anyone seriously.

1 Like

That’s… Ouch. I remember when I first started with C/C++ doing things like #define until(x) while(!(x)), but that is next level.

1 Like

On the other hand, name-then-type syntax will be more familiar to users of languages like

  • Swift
  • Kotlin
  • TypeScript
  • Haskell
  • Nim
  • Python (sort of)
  • Scala
  • Go

Programmers who can only use languages with C-style variable declarations are cutting themselves off from a wealth of modern statically-typed languages. Getting used to a new syntax can be uncomfortable at first, but in the long run it is one of the smallest adjustments you'll need to make to be productive in a different programming language.

8 Likes

ok thankyou for all your input. I just wanted some opinions on why it was chosen to be like this.
I was mostly just worried mostly about nested arrays [][][] being hard to use when I wanted to specify a datatype.

Note how that's not C syntax either.

The nice thing about [ [i32; 2]; 100 ] vs int[2][100] is that it's much more obvious which type is "inside" of which. See also how std::array<int, 10> is preferred in C++ over int[10], despite being longer...

5 Likes

It's minor, but C doesn't actually use function; to declare a function in C you just do int f() {}. function isn't even a keyword. In Javascript you write function f() {}, and in C++ you can also do auto f() -> int {}, which is closer to Rust's syntax, but auto is still longer than fn.

3 Likes

No, why do you think so?

Yes, it's more uniform, namely, it is context-free. It makes Rust easier to parse (both for the compiler and for human readers of the code). C type declaration syntax is a mess, not due to some personal preference or anything like that, but because it can't be parsed without at least partially type checking the code at the same time as well. This hurts the modularity of the compiler.

My guess would be categorically no. Why would it change back to an inferior option? Rust is not C, in fact it's a language designed to correct the mistakes of C.

3 Likes

It's amazing how this discussion on "why not C style array declaration syntax" does not contain a correct C example. For example:

int balance[5] = {1000.0, 2.0, 3.4, 7.0, 50.0};

Personally I have been programming in C since 1980 and have always thought this was a bit odd. My mind working thus as follows: If I want an integer type I write:

int

Then if I want an integer array type the obvious thing is to modify it so:

int[5]

I want to name this thing so either of the following would do:

int[5] a
a int[5]

If I want to initialise it why not use the array [] syntax we have already:

a int[5] = [0, 1, 2, 3, 4];

But no. C does something really weird instead. It splits the description of the type by putting the variable name in the middle. It uses curly braces to initialise rather than square. Why?

Years later I was happy to find Rust had done something more inline with what I imagined C should have done.

Anyway. None of this matters. Rust is not C. The syntax is different. At the end of the day that difference is a minor detail compared to learning the rest of Rust if you are coming from C.

Also, I think there is advantage in have a different syntax. During times when I ws switching between languages rapidly, C, C++, Javascript I often found my self getting confused and thinking the wrong thing and typing the wrong language into a source file I'm looking at that moment. Having a clearly different syntax is a good mental cue that one is looking at a different language.

I don't buy the argument of less typing. Readability is far more important than saving the programmer a few key hits. Besides I'm pretty sure most people spend far more time thinking about what they want to write than typing it.

9 Likes

I am a long C++ dev, and when I started learning Rust I was actually throwing up when I was getting used to the syntax. It reminds me too much of a bash/others scripting languages to which I simply have aversion.
But after a while I got used to it and it is OK.
There are few things I don't like in Rust syntax, and one of them is:
let a = HashMap::<i32,i32>:: new();
vs
let a: HashMap<i32,i32> = HashMap::new()
To me it is simply wrong, that the typing of a type is different. Other than that, it is just another language and if you want to program in it better get use to its syntax. It's not gonna change.
As for C/C++. Tbh, I was a enthusiast of C++ but after working with Rust I actually prefer the Rust way of doing things.

Well, it’s actually let a: [i32; 5] = [0,1,2,3,4]; and let a = [5; 5];.

I don’t understand i32[5] a = 5 at all, I also don’t know which C or C++ syntax this should correspond with.

5 Likes