Make language more precise in variable mutability design doc #509
Conversation
catamorphism
force-pushed
the
variable-mutability-edits
branch
from
d6814f1 to
9bc20f2
Compare
| The term **external variable** refers to a value that is passed to the | ||
| message formatter by name and which can be referred to in an expression. |
There was a problem hiding this comment.
Looking at the changes you've proposed, I think this part ought to be revisited as well. Given that the chosen solution is to use input and local declarations, the definitions here of "local" and "external" variables don't necessarily align all that well. Maybe we'd be better off with "local", "input", and "implicit" variables as separate concepts?
Overall, though, I'm not excessively keen on spending too much time on this, esp. given that the corresponding changes have already been applied to the spec. If there are issues with any of that text, that should definitely be prioritised. The remaining value of this doc is to provide some explanation of our decisions for later really interested readers.
|
I'm going to close this, since the actual spec text doesn't mention mutability, as far as I can tell. (If I see something else that's in the final spec, I'll open another PR.) |
|
Variables are not mutable with the changes that brought in (Good to see you able to contribute again!!) |
The existing proposal uses the term "mutability" to describe a situation where variables aren't being mutated. I've rewritten the document to refer to name shadowing rather than mutability. As we discussed in issue 413, mutability is not on the table; the question is whether to allow shadowing (overriding) or not.
(I've used "name shadowing" in most cases since the term "override" can easily be confused with "overwrite".)