[organizeImports] matching priority

[Conaclos]

The matching system of organizeImports is by nature ordered.
In the following example, the second matcher is useless because all import type are matched in the first group.

{
  "groups"; [
    { "source": ":PACKAGE:" },
    { "type": true, source: ":PACKAGE:" }
  ]
}

In order to be effective, the first group has to exclude import type:

{
  "groups"; [
    { "type": false, "source": ":PACKAGE:" },
    { "type": true, "source": ":PACKAGE:" }
  ]
}

When I implemented organizeImports, I chose this system for several reasons:

• Once you know the matching is ordered, it is easy to predict how imports are sorted
• Implementation-wise it is pretty efficient because you can stop at the first matching group for each import.

Unfortunately, the use of these systems revealed two main issues:

1. Users want to express complex sorting constraints. This leads to very verbose configuration as demonstrated here or there.
2. Some users are confused by the in-order nature of our matching system.

Addressing (2) could require a new matching system with a new semantic. Some import sorters use a more complex system based on selector precedences (for example type has precedence on source) and matching specificity (for example a matcher with two type and source is more specific than a matcher with only type). I am really not fond of the matching by specificity. However, I could be open to introduce some selector precedence.

For example, it could make sense to make type and the future kind selectors have a higher precedence than source.
So the two examples at the start of this post could be identical in terms of matching behavior, because { "type": true, source: ":PACKAGE:" } got matched before { source: ":PACKAGE:" }.

I am really hesitant to introduce a such system because this makes things harder to explain.
This is why I thought about a more explicit approach: we could make matching priority explicit by introducing a priority field.
So the first example could be written as follows:

{
  "groups"; [
    { "source": ":PACKAGE:" },
    { "priority": 1, "type": true, source: ":PACKAGE:" }
  ]
}

priority is like a CSS's zindex. By default, it is set to 0: higher it is, higher the matcher priority is.
We could allow negative priorities.

Note that this explicit system doesn't address (2) (user confusion). However, it could reduce the verbosity of complex configurations.