Open alnoki opened 1 year ago
One initial thought: there is nothing "optional" in a good programming language. In a good language and framework, its clear to everybody that this is the way how you do it.
Let us say we define a linter for Move. Now we would have the option to name parameters. What would be the rules for the linter?
One initial thought: there is nothing "optional" in a good programming language. In a good language and framework, its clear to everybody that this is the way how you do it.
Let us say we define a linter for Move. Now we would have the option to name parameters. What would be the rules for the linter?
@wrwg as for rules, I would start with the following:
If an argument has a parameter hint, then all arguments after it must also have parameter hints. This is an approximation of Python's positional/keyword argument schema, and encourages programmers to put the most easily inferred parameters first in their calls:
do_something_complex(account, struct_to_mutate = &mut my_struct, convergence_iterations = 4);
The same for type hints:
let (result_1, result_2: address) = a_complex_function(
a_struct_ref_mut,
to_read = a_struct_ref,
iterations: u8 = 4,
operation_description: vector<u8> = b"indexing",
);
I think it's an interesting idea; I personally wouldn't ever use it, but I'm sure some Move developers would like it. Interestingly, function calls in Cadence work almost exactly like this:
Can't you just use the IDE for those?
I can attest that the CLION Move plugin is godly. Parameter name highlighting is one of the many amazing features!
Can't you just use the IDE for those?
This solution requires developers to use JetBrains software, correct?
I think named arguments would be very useful for writing safer and more readable code--have definitely seen cases where folks swap two u64
inputs in a function with a lot of parameters.
It would be cool to do this in a way that allows punning (which is very useful for writing concise packs and unpacks elsewhere in Move). I think OCaml's approach of using ~
prefixes to distinguish named arguments from non-named ones is a nice syntactic trick https://v2.ocaml.org/manual/lablexamples.html
@wrwg @chen-robert @davidiw @movekevin @PaulFidika
Presently Move does not allow parameter hints in function calls, which is not a problem for straightforward invocations:
More complex function calls, however, can be confusing without sufficient context, and developers may have to refer to the original function definition signature to "cognitively prepare" during code review:
Hence it is proposed that Move support (optional) Pythonic parameter hints (AKA keyword arguments in Python) of the following form:
Type hints would also be helpful:
Here, the compiler should throw an error if type or parameter hints do not match the original function signature definition.