Improving the consistency of where filters

[Pikachu920]

The existing where filter syntax in Skript is kind of odd. When I added it years ago, I just copied the lambda syntax from skquery and called it a day. This isn't great. The where filter is the only place in Skript that square brackets are used, so it's kinda confusing. In skquery, using square brackets made more sense because they represented a lambda object which had other uses. In skript, their only purpose is to help the parser understand which part of the expression is the condition. This brings me to my proposed changes to the where filter:

Proposed Changes

1. Use required parentheses instead of square brackets

Like mentioned above, the square brackets are currently only used to help the parser differentiate the parts of the syntax. Skript already uses parentheses for this same purpose, so it would make more sense to just use parentheses here.

2. Use loop-value instead of input

Skript already had an expression for a looped value. It would make more sense to reuse it instead of having a dedicated expression just for where filters. In addition, we could add support for loop-index when filtering variables.

3. Deprecate input and square brackets for eventual removal

If these proposals are implemented, input and square brackets can be deprecated for removal in a future release.

Potential issues

1. Numbering loop-value when using a where filter within a loop
   If we use loop-value instead of input, one potential issue would be how loop-value numbering works. For example:

loop {warps::*}:
  teleport all players where (loop-value-2 has permission "warp.%loop-index%") to loop-value
  loop 5 times:
    send "Counting is super fun: %loop-value-3%" to all players

The where filter has to use loop-value-2 since it's within a loop already and the nested loop has to use loop-value-3 rather than loop-value-2 due to the where filter. This might be a pain to implement or confusing to users.

Before/after examples
set {_admins::*} to all players where [input has permission "admin"] -> set {_admins::*} to all players where (loop-value has permission "admin")
kill all pigs where [name of input is "unlucky pig"] -> kill all pigs where (name of loop-value is "unlucky pig")

[sovdeeth]

I like the () change, but i think the loop-value change is very confusing.
input is fine imo, but maybe something like filter-value and filter-index could be used to follow the pattern more closely.

[sovdeeth]

Although I'm uncertain as to how the () would interact with the parser. Would set {_x::*} to ( join y where (input is x) with "test") have to also try parsing (input is x) with "test") as the filter condition? I'm not sure how the regex stuff interacts in the parsing process. Maybe this is a non-issue.

[Pikachu920]

what do you think about candidate (like all players where (candidate has a diamond))? it makes english sense to me, but i'm worried it's a little too out there to be understandable for beginners

[TheLimeGlass]

Also #4856

[Moderocky]

I think this a great idea pikachu. I'm not particuarly happy with the filter syntax as-is and I always love it when we can do things better.

Use required parentheses instead of square brackets

Sounds great, I'd love it if they could be optional but I think that could be hard on the parser unless we had some kind of detection.

Use loop-value instead of input

I don't hugely love the loop-value syntax, but I do agree with moving away from input. I might suggest reusing the this|it local syntax that I came up with for switch statements, since it should read more like english in most cases:

teleport all players where (it has permission "my_permission") to {something}
set {_things::*} to {_items::*} where (it is a stone sword)

[Pikachu920]

i like it a lot. it might be hard to implement player input type things with it, though. that said, i'm not sure how important that functionality really is anyways. the main thing it does is allow people to specifically force a return and loop type.

[Pikachu920]

maybe combine candidate and it? the pattern could be (it|candidate|%-*classinfo% candidate)

[sovdeeth]

I like that