Currently, we allow the const keyword to be used for the declaration of non-updated primitive values as well as for Object references where the reference is not updated. The const keyword provides several benefits, such as minimizing coding mistakes by preventing undesired alterations, and I consider it to be one of the best changes the language got.
However, we can’t currently use this keyword with function parameters. These are always updateable values, and I think we should fix that.
'use strict';
const example0 = function(const A){
A++;
// This should trigger errors similar to other const-violating alterations.
};
const example1 = function(const A, const B){
return A+A+A-B;
//Neither A nor B is altered, so we should be able to say they're const.
};
This is a proven idea and would allow for better protections against development mistakes. C and C++ already have this. Java does as well, although Java uses the “final“ keyword instead (eww). Rust has a related idea: Generic parameters - The Rust Reference , although it’s more complicated for Rust because that language is very extra when it comes to safety.
I suspect this may allow for performance improvements as well, but I leave that for the Runtime engine authors to discuss on their own, as I am more interested in this from the perspective of preventing code mistakes.
That suggestion seems to be abandoned. I also admittedly did not know about it. But, now that I know about the other suggestion, I think the idea warrants reconsideration.
That said, having looked at that previous suggestion, I do not see a good reason to allow “let” or “var” be used in this way. “var“ would be counterproductive, and parameters currently behave as if one used “let“, so there would be no additional value.
In JavaScript, reassigning parameters isn’t really meaningful anyway.
If the goal is to prevent accidental reassignment, it might be better handled by lint rules like no-param-reassign rather than introducing new syntax.
I don’t think it’s a good idea to use a linter feature to compensate for an inconsistency within the language. I’m not disparaging eslint either. I just think this should be part of the language rather than a static analysis tool for the sake of consistency with safety features.
The combination would not be more chaotic. That said, why are you putting assignment operations in conditional statement blocks? That’s more chaotic to the eye than allowing const in the parameters, which most algol-derivatives with the keyword allow.
I understand the proposal. I was merely disagreeing with what @WebReflection brought up about it conflicting in terms of readability, while also not caring for someone doing what that proposal outlines allowing.
There was recent push-back from engine implementers regarding the complexity of const. While the concerns were mostly around the TDZ (which I think wouldn't apply to const args), if const declarations in general are seen as a misfeature, it might be difficult to argue for its extension to args.