Support named expression/condition/effect parameters

[voximity]

Is your feature request related to a problem? Please describe. In the event I need to create an expression where two or more parameters may be ordered differently for two different parameters, e.g.

make %player% say %text% and make %text% be said by %player%

the keywords expr-1 and expr-2 become ambiguous between the two patterns. A current solution would to be to check the matched pattern, but that would include hard coding in the patterns twice, and is overall just a gross solution.

Describe the solution you'd like A way to name custom expression/condition/effect parameters. For example, in the creation of patterns, a solution could be as follows for the previously presented scenario:

make %player:speaker% say %text:message% and make %text:message% be said by %player:speaker% (where each parameter is defined like %type:name%)

Thus, in the definition of the effect, you could use a variable reference with some syntax to fetch the value of the provided parameter, like {:speaker} to refer to what would be expr-1 in the first pattern, and {:message} to refer to what would be expr-2. This syntax is obviously not the most ideal, but works with the idea I am trying to convey: named parameters prevent ambiguity.

Describe alternatives you've considered Another solution would be to somehow number the parameters in the pattern beforehand and continue to use the [the] expr[ession][s](-| )%number% pattern, like make %player:1% say %text:2% or some similar syntax to define parameter position consistency throughout multiple patterns.

Additional context Nothing belongs here.

[Moderocky]

You can compare the matched pattern, or the class of the expression, to determine which is which. That said, it can get a little clumsy, so something like this might be nice.

An extension to this suggestion would be to allow expr-string and expr-player, as skript does with command arguments, when there is only one of a particular type. That would help in simple cases.

[voximity]

That's also a somewhat viable solution, until you end up having multiple parameters of the same type in interchangeable positions. The current comparison of the matched pattern would be considered bad practice in almost any other language or scenario, so I don't know why it would be the acceptable one here.

[btk5h]

This is actually a planned feature! This was even a utility that I wrote a few years back for Skript addons in general, and I'm excited to bring it to skript-mirror in the future.

The plan is to be able to name expressions within the pattern and be able to access the expression as a local variable {_name}, which is very similar to how Skript functions work as well.

I remember that for some reason, there was a lot of negative feedback to this idea when this was discussed in the past. If anyone has any issues with this approach, I think organizing any arguments here would be a good idea.

[voximity]

I am a fan of the usage of local variables for fetching passed arguments! I'm very curious, however, about what syntax you have planned for modifying the patterns in a way that would allow named parameters to be possible.

I'm also curious over what arguments people might have against this. Additionally, this feature would come as semi-optional. As long as the "matched pattern" expression was kept in place, developers who use this method presently would not be forced to switch over to the named parameter convention.

[btk5h]

The syntax you described originally is pretty much exactly what I had in mind.

I think the main argument against this had something to do with the use of local variables? I don't want to misrepresent that argument, but I don't recall that conversation bringing up any massive issues.