Swift: Add and use ApplyExpr.getArgumentByParamName. #11036
Conversation
|
What happens when a parameter has a default value, and an ApplyExpr omits an argument for that parameter? Do you think the parameter's default expression should be the argument in that case? |
|
Good point, yes, that seems like a reasonable thing to do. In which case I think I'm going to need to add a test for this... |
|
As for naming, getArgumentByParamName sounds fine. Alternatives: getArgumentNamed, getArgumentByName. |
|
Hmm. Slightly related comment: why are we using the name of the parameter and not just its index? The internal parameter name seems like something that the developers are free to change, and it's a bit scary that we're depending on this name |
There have been a couple of cases where there's a reasonably large collection of functions with the same name and similar parameters, but the target parameter is not at a consistent position. So expressing it by parameter name is more concise and probably more robust. I think using the index is preferred in most other cases. |
|
I've changed the two existing cases to use argument indexes instead. I'm now unsure whether we want |
|
OK, in the interests of having fewer balls in the air I've removed the addition of We can have another go at a |
|
DCA run is finished. Some stage timing results (quite a lot actually - and apparently not in a good way - but I don't know how to read these yet) . Overall analysis time is unchanged. |
|
(I'm currently looking at a bugfix for the stage timing. Don't worry about those for now) |
Add and use a predicate
ApplyExpr.getArgumentByParamName(please say if you can think of a cleaner name for it). This makes it easier to get an argument by its parameter name, rather than the argument name (which is often anonymous) or index (usually the preferred method, but sometimes varies across the functions of interest).This will be used in a couple of upcoming queries in addition to the two I've updated here.