Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

var as alias for let mut #2402

Closed
EdSaleh opened this issue Apr 16, 2018 · 4 comments
Closed

var as alias for let mut #2402

EdSaleh opened this issue Apr 16, 2018 · 4 comments
Labels
T-lang Relevant to the language team, which will review and decide on the RFC.

Comments

@EdSaleh
Copy link

EdSaleh commented Apr 16, 2018

Hello Everyone,

I propose rust to implement var keyword as an alias for let mut. Some might think that's unnecessary and I respect that, however, I think people who would like to create mutable variables by default without much cognitive thinking deserve that option too.

It would also make rust similar to 99% of language out there that has var being the default for mutable variables.

This is similar to the optional keyword return found in rust, where you don't have to use it, but it's available if you would like to.

The compiler can suggest to turn var into let if it's not necessary.

It would make rust more natural as a programming language similar to most languages.

It's doesn't have to be named var, you can pick another to allow the function.

You might say that having let and var would make it confusing; however, Rust already has a similar situation with the const and let keywords, where both function as an immutable variable but they are implemented differently.

The var keyword can be denied by clippy as well if you would like too.

Thank you,

@Centril Centril added the T-lang Relevant to the language team, which will review and decide on the RFC. label Apr 16, 2018
@Centril
Copy link
Contributor

Centril commented Apr 16, 2018

Hi there; and thank you for your interest in Rust language design!

To file a formal proposal, you should follow the guide here: https://github.com/rust-lang/rfcs#what-the-process-is

But before doing so, it is best to file a pre-RFC on https://internals.rust-lang.org/

However, in this case, we previously discussed this at #2304.
To conclude, I think it is unlikely that we will do this based on the discussion over there.

@EdSaleh EdSaleh closed this as completed Apr 16, 2018
@EdSaleh EdSaleh reopened this Apr 16, 2018
@EdSaleh EdSaleh closed this as completed Apr 16, 2018
@EdSaleh EdSaleh reopened this Apr 16, 2018
@EdSaleh
Copy link
Author

EdSaleh commented Apr 16, 2018

@Centril I think it should be highly considered. Making every Rust variable declaration immutable by default would greatly affect its adoption rate, it greatly reduces productivity in my opinion. I am certain that having both options(let and var) is the best way to go. I am not familiar with any other language that takes this immutable approach. It makes sense to have parameters immutable by default since people almost never mutate parameters; however, this is not the case with variables, and introducing var or similar keyword would be the solution for this concern. This would increase rust adoption rate in my opinion.

@EdSaleh EdSaleh closed this as completed Apr 17, 2018
@EdSaleh EdSaleh reopened this Apr 20, 2018
@Centril Centril closed this as completed Apr 20, 2018
@EdSaleh
Copy link
Author

EdSaleh commented Apr 20, 2018

@Centril I still believe in providing this option. Clippy can add an option to disable this keyword programmers believe it can lead to confusion. In addition to compiler warning in case it's not needed similar to let mut when not needed.

@Centril
Copy link
Contributor

Centril commented Apr 20, 2018

@medozs I hear you; but the best place to discuss a proposal that hasn't fully baked is over at https://internals.rust-lang.org/. Furthermore, please avoid closing and reopening the same issue several times =)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-lang Relevant to the language team, which will review and decide on the RFC.
Projects
None yet
Development

No branches or pull requests

2 participants