How to tell Mojo that something is intended to be constant?
In mojo 24.1.0 (55ec12d6) I get a new warning:
'let' is being removed, please use 'var' insteadI think it is good practice to make explicity my intention that something is constant. How to I do that (in the future) since let is deprecated?
50 Replies
You can use
alias as a compile time constant. The old let was there to emphasize immutable variable deceleration which is no longer needed.Of course I know of the existence of alias, it is just that there is a very large semantic difference between
var x = 8 and let x = 8, namely that it is my intention (the programmer) that a variable (not a compile constant) is constant, how are my colleagues to know my intentions if i cannot make that explicit? What were the reasons for removing this?GitHub
mojo/proposals/remove-let-decls.md at main · modularml/mojo
The Mojo Programming Language. Contribute to modularml/mojo development by creating an account on GitHub.
Congrats @Ehsan M. Kermani, you just advanced to level 1!
I did not comment on the proposal when it was made, but now that it has been executed, I'm interested in the 'official' reason
let will be removed.
Because now I cannot tell that something is intended to be constant, which is, for me, a very important concept.well, atleast from how I see it, this becomes the same argument as when I proposed private struct fields. The effect you need can be made with changing naming scheme, though the compiler will not recognize it officially. The same way I can say _data is a private field, although not enforced, you can say var DATA is a constant, hence the naming scheme
@benny you mean that by naming a variable with eg capitals we can communicate that it is not intended to be changed, but the compiler will not enforce it (anymore). Similar, that all fields are public, but by naming it differently my colleagues can know that it should not be used.
correct
you can imply behavior without it being enforced, which i believe is intended
i personally am not sure I agree with this, but i see both sides of the arguments
Thus, our ability to write bug free code is sacrificed for ...., i hope it is something important...
A workaround is to create a function. In a function signature, it's possible to declare that an input value can't be mutated. And it works with references too.
👍🏻
along with this, I can think of few cases where I 1. don’t know the value or the function to get the value, and 2. need it to be immutable during runtime. I’m not saying there aren’t any, there are, i’m just saying alias can and should be used wherever possible, and i believe that is what that change is trying to emphasize
plus there are some other issues with let/var being used with pointer/referencd
since semantically you aren’t changing the pointer, rather the value it points to, if given the choice it can be ambiguous for new developers to choose let or var for that use case
whereas alias is a little more imperative that the pointer itself is immutable while its underlying data may not be
^something that reference improves on even more, explicitly saying if it’s a mutable or immutable reference
It introduces complexity to the compiler and it doesn't work well
What started this "bug-free code" movement?
Congrats @toiletsandpaper, you just advanced to level 1!
I want Mojo to do well because it gives us access to top-notch MLIR lowering capabilities (translation: it compiles to speedy code).
For Mojo to succeed, the company Modular is creating a product called Max (written in Mojo) aimed at companies with highly profitable but complicated AI technology setups. And anyone who's dealt with such setups knows what a complete and total nightmare they can be.
So, Modular, help us out (for us programmers' sake). How do we convince others (meaning management, who aren't keen on changing a highly profitable AI stack) that Mojo is a solid language? What does not quite helps is that it lacks basic Encapsulation (no private member fields) and has dropped Immutability. But that's okay if there are solid reasons behind it. Arguments like "it makes the compiler tricky" or "it's tough for new hires to grasp
const int * const foo" just won't cut it. Even more challenging is how to persuade that Mojo can match Rust's capabilities without these fundamentals.I think every company should use what they feel is the best tool for their job. If all these features are important then Rust is the obvious choice.
For people having problems Mojo is intended to solve, these things are a non-factor. I'm talking AI Researchers, Python developers, and C/C++ devs writing extensions for Python.