Var as alias for let mut

language design
44

@medozs I think this is one area where rust is particularly opinionated. IMHO, I think that rust is well-motivated in not having var, as discussed.

That said, I think the community widely acknowledges that rust is not perfect and should continue to evolve, so please do keep making suggestions.

9 Likes
45

Some points here:

  • I don't think you can that easily transfer research into interaction and user design to language design wrt. readability and ergonomics.
  • Saying that options are sometimes bad is a vastly weaker statement than monotony of design (or Zen of Python). While I agree with the former I don't agree with the latter as a rule.

Rather than saying that there should only be one way to structure code, I believe we need a more nuanced approach. I would state it as follows:

When adding syntactic sugar, you should only do so if:

  1. It is fairly obvious for a writer which one to pick under which circumstance (c.f. ? vs. match).
  2. The syntactic sugar applies to a non-trivial amount of use cases and real code.
  3. The new way of doing things adds to readability.
    • Usually by highlighting the important logic that is currently getting drowned out (c.f. ? again...)
  4. The new way adds non-trivial amount of semantic compression.
  5. <are there more criteria I've missed?>

I believe adding var fails tests 1, 3, 4.

As both a Rust and Haskell programmer, I like pure functional languages. I do not consider myself either a "purist" or extremist. Haskell was designed to be a practical general purpose programming language and is, at least in my view, unparalleled when it comes to productivity and rapid prototyping. In the future, please avoid labeling the users of other languages as extremists or other uncharitable ways.

This line of reasoning is uncalled for. Please try to argue on the merits for or against a feature and please avoid arguing by assigning traits to people. It does not advance your argument even if it is incidentally true.

Like @goodmanjonathan, I would urge you to not be discouraged by the lack of support for adding var. Your insights are valued even if we decide not to go with a feature. Given determination and resolve, I am sure some feature you propose would eventually make it into the language.

6 Likes
46

please avoid labeling the users of other languages as extremists or other uncharitable ways.

I was not labelling anyone as an extremist. I merely stated that I am not one.

This line of reasoning is uncalled for. […] It does not advance your argument even if it is incidentally true.

It does, because it's not incidentally true. If you stay honest to yourself, and consider OP's arguments, you can see that they are the typical arguments of the inexperienced programmer. It appears that you are misunderstanding me – being inexperienced in a language or technology is not bad, and I was not trying to launch a personal attack against OP. What is bad though is trying to change the language to a worse direction without a thorough understanding of it.

I also think that this kind of meta-discussion does not belong here and is off-topic. If you want to continue it in PM, I'm happy to do so.

47

You have a PM.

48

Ok. Let’s look at this from another perspective.

How I normally look at these trade-offs is by considering the gain achieved.

So what are we exactly gaining by changing or providing an alternative?

I don’t see any advantage is using var

1 Like
49

I’d like to second all the opinions here in that I want:

  1. Immutability by default
  2. Explicit declaration of immutability
  3. let to be used for both mutable and immutable declarations.

In other words, I like the way variable declarations are done now and I feel that allowing var will dilute and confuse the language.

4 Likes
51

Locking this thread as it’s gotten off-topic and heated, and the original proposal has been thoroughly discussed.

2 Likes