TL;DR:
- What was the motivation behind making procedure arguments immutable?
- Could it be a good idea to allow some variables to only be assigned to once, similar to how procedure arguments are immutable?
Question 1
I’ve read that Bill doesn’t like const or immutable qualifiers because it’s a viral thing, which totally makes sense. So it’s strange that procedure arguments are immutable by default. I’m guessing that’s ok because it doesn’t involve a real const/immutability qualifier type, so there is no virality involved?
Question 2
Out of instinct, I recently tried to make some of my variables immutable by using :: instead of := inside a procedure, but then I realized that :: can only be used with values known at compile time. But what I was really reaching for is what procedure args already are - variables that prevent further assignment.
So I’m wondering if the following would be a good idea or not: have some kind of “immutable assignment” operator that will allow a variable to be assigned to initially, but then prevent it from being assigned later on in the same scope, just like procedure arguments.
It might look something like this:
my_proc :: proc(something: u64) -> {
CANT_CHANGE_ME ::= something + 10 // "immutable assignment operator"
do_something(CANT_CHANGE_ME) // Takes a normal u64 as an arg
... // lots of logic
CANT_CHANGE_ME += 10 // Compile-time error!
}
Variables assigned with ::= would not alter the type signature of do_something() in any way.
I think this could be nice, especially for newcomers from other languages with immutable variables. It helps document your intent that something shouldn’t change, which can help in really long procedures, like a large game update loop. I feel like this would satisfy 80%+ of the use cases for the people asking for const/immutable qualifiers, without the baggage of any virality. But I get that Bill and other C-style programmers probably wouldn’t care about this use case.