Negative matching nor predicate support in `ConditionalInterceptor.Subject`

[MathieuTricoire]

Is your feature request related to a problem? Please describe it.

When using ConditionalInterceptor.Subject it's currently only possible to target .all, .services, or .methods.
This makes it difficult to express common cases like "apply this interceptor to all methods except a small set" without manually listing every included method or service. For example applying authentication everywhere except health check and authentication services.

Describe the solution you'd like

1. Negative variants
   Add negative forms alongside the existing .services / .methods, for example:

   .exceptServices(Set<ServiceDescriptor>)
   .exceptMethods(Set<MethodDescriptor>)

   This would keep the current per-scope structure but add the ability to exclude instead of include.

2. Unified include/exclude
   Alternatively or additionally, introduce single cases that accept both services and methods at once:

   .only(services: Set<ServiceDescriptor> = [], methods: Set<MethodDescriptor> = [])
   .except(services: Set<ServiceDescriptor> = [], methods: Set<MethodDescriptor> = [])

   This keeps the API minimal, avoids combining multiple subjects, and makes it easy to mix service-level and method-level rules.

3. Predicate-based matching
   Additionally add a form such as:

   .predicate(@Sendable (MethodDescriptor) -> Bool)

   The library already caches interceptor lists per method (for what I understand), so the predicate should be pure/static (same result for a given method, not dependent on runtime state).

   This would fill the gap for complex inclusion/exclusion logic and avoid introducing heavier mechanisms like arrays of subjects with combination rules.

   If you already have ideas or internal discussions about expanding Subject matching in a different way, I'd be interested to hear your thoughts.

Describe alternatives you've considered

Manually enumerating all "included" services or methods except the few to be excluded. This works but it's error-prone and hard to maintain, especially when new services or methods are added.

Additional context

I'd be happy to open a PR for this once we agree on the desired semantics and API shape.

[glbrntt]

Thanks for writing this up. I think adding this is definitely a worthwhile addition and I'm happy for all three variants to be added. We just need to agree on naming. Because the API is used as .apply(someInterceptor, to: subject) the suggested names don't quite fit right. I left a few suggestions inline.

1. Negative variants
   Add negative forms alongside the existing .services / .methods, for example:
   .exceptServices(Set)
   .exceptMethods(Set)

.apply(someInterceptor, to: .allExcluding(services: [...])
.apply(someInterceptor, to: .allExcluding(methods: [...])

2. Unified include/exclude
   Alternatively or additionally, introduce single cases that accept both services and methods at once:
   .only(services: Set = [], methods: Set = [])
   .except(services: Set = [], methods: Set = [])

I would remove the defaults here, having only() and except() doesn't make a lot of sense.

Drawing back on the above, I think the second should be spelled as .allExcluding(services:methods:). This makes it a natural extension to the exclusions above. Happy with .only(services:methods:) (providing we drop the defaults).

This keeps the API minimal, avoids combining multiple subjects, and makes it easy to mix service-level and method-level rules.
3. Predicate-based matching
Additionally add a form such as:
.predicate(@sendable (MethodDescriptor) -> Bool)

Not sure about this one...how about .matches(_ predicate:)?

apply(someInterceptor, to: .matches { descriptor in ... })

[gjcairo]

Not sure about this one...how about .matches(_ predicate:)?

May I suggest .allMatching(_ predicate:)? Makes it clear it will apply to all matches (plus it uses the gerund which seems more consistent with .allExcluding).

[MathieuTricoire]

Food for thought — I prototyped an approach where every variant is just sugar over a single predicate, like this:

public struct ConditionalInterceptor<Interceptor: Sendable>: Sendable {
  public struct Subject: Sendable {

    private let predicate: @Sendable (MethodDescriptor) -> Bool

    public static var all: Self {
      Self(predicate: { _ in true })
    }

    public static func services(_ services: Set<ServiceDescriptor>) -> Self {
      Self(predicate: { descriptor in
        services.contains(descriptor.service)
      })
    }

    public static func methods(_ methods: Set<MethodDescriptor>) -> Self {
      Self(predicate: { descriptor in
        methods.contains(descriptor)
      })
    }

    public static func only(
      services: Set<ServiceDescriptor>,
      methods: Set<MethodDescriptor>
    ) -> Self {
      Self(predicate: { descriptor in
        services.contains(descriptor.service) || methods.contains(descriptor)
      })
    }

    public static func allExcluding(
      services: Set<ServiceDescriptor>,
      methods: Set<MethodDescriptor>
    ) -> Self {
      Self(predicate: { descriptor in
        !(services.contains(descriptor.service) || methods.contains(descriptor))
      })
    }

    public static func allMatching(
      _ predicate: @Sendable @escaping (MethodDescriptor) -> Bool
    ) -> Self {
      Self(predicate: predicate)
    }

    @usableFromInline
    package func applies(to descriptor: MethodDescriptor) -> Bool {
      self.predicate(descriptor)
    }
  }
}

If we don't want to call a closure for .all we can create a enum for all and predicate?

[glbrntt]

Looks great! Happy to use the predicate for all cases.

[MathieuTricoire]

Though this "closure" design being simpler it will probably be a tiny less performant since it cannot be optimized by the compiler the way the old design is (for what I know about compiler optimization). So I'm fine with old design, it's just to open the question.

[MathieuTricoire]

Looks great! Happy to use the predicate for all cases.

Ok I'll push a PR with this change soon. We could then discuss if we want to go forward with this design or not. Thanks!