Implement better function argument ordering parsing #8352
+119
−69
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
Currently, the enhanced function argument parsing with named arguments is too restrictive when optional parameters exist. For example, the following function call errors for a somewhat unclear reason:
set {_loc} to location(x: 1, y: 1, z: 1, yaw: 1, pitch: 1)(Mixing named and unnamed arguments is not allowed unless the order of the arguments matches the order of the parameters.). This error is because theworldparameter must occur before theyawparameter. However, given that it is optional. one would expect for this function call to work without issue.Solution
I have reworked the function argument parsing so that the user provided arguments are instead reworked into the order defined by the function signature. First, all named parameters are inserted into their respective positions. Then, the remaining unnamed arguments are inserted into the remaining positions. An unnamed parameter is only valid in its position if the named parameter it represents occurs before all named parameters that come after in the user's provided arguments.
For example, the following calls are now valid:
location(1, 2, 3, pitch: 10, yaw: 5)where1,2, and3representx,y, andzrespectivelylocation(x: 1, y: 2, z: 3, yaw: 4, 5)where5representspitchlocation(x: 1, 2, z: 3) where2representsy`.Further, I fixed a mistake where failures to parse arguments as expressions would result in the default value being used. Instead, an error about the input being invalid for that parameter is now parsed.
Testing Completed
I have added a few additional tests to
StructFunction.skSupporting Information
n/a
Completes: none
Related: none
AI assistance: none