[Review] SF-0035: PredicateExpressions API for nil comparisons without Equatable conformance within #Predicates

Related Projects Foundation
1

Hello Swift community,

The review of Support for nil comparisons without Equatable conformance begins now and runs through 2026-02-25.

Reviews are an important part of the Swift-Foundation evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to me as the review manager by DM. When contacting the review manager directly, please include proposal name in the subject line.

Trying it out

If you'd like to try this proposal out, you can check out the implementation PR on the swift-foundation repo.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive feedback. When writing your review, here are some questions you might want to answer in your review:

  • How much effort did you put into your review?

  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

More information about Swift-Foundation review process is available at

https://github.com/swiftlang/swift-foundation/blob/main/CONTRIBUTING.md

Thank you,

Jeremy, Review Manager

2 Likes
2

I believe the standard library uses _OptionalNilComparisonType to handle comparisons between an optional and a nil literal. Is there a reason the same technique would not work here?

6 Likes
3

Big +1 on using _OptionalNilComparisonType instead. Avoiding the extra generic parameter of this new NilLiteral<T> type might improve performance.

4

The standard library does have _OptionalNilComparisonType, which can facilitate these comparisons without requiring either side to conform to Equatable, and @jmschonfeld mentioned that feature in swift-foundation#711. It could help us when evaluating a predicate, but not when constructing it. For example, #Predicate<Message> { $0.subject == nil } expands into this:

Foundation.Predicate<Message>({
    PredicateExpressions.build_Equal(
        lhs: PredicateExpressions.build_KeyPath(
            root: PredicateExpressions.build_Arg($0),
            keyPath: \.subject
        ),
        rhs: PredicateExpressions.build_NilLiteral()
    )
})

Without the new overloads, the Swift compiler chooses the only build_Equal(lhs:rhs:) currently available, which requires LHS.Output: Equatable and LHS.Output == RHS.Output of its generic parameters.

2 Likes
5

To your point here about choosing the only build_Equal that’s available, perhaps some of the confusion here may stem from the proposal title (and to an extent the introduction) not explicitly stating that this is proposing support in Predicate expression trees (as opposed to proposing a general developer-facing API or language feature like the one with _OptionalNilComparisonType mentioned above).

Perhaps we should consider retitling the proposal / this thread to explicitly call out Predicate to make sure we’re all framing the discussion the same way, would that make sense / @Nevin @x-sheep does that help clarify how this proposal is related to _OptionalNilComparisonType?

2 Likes
6

This is entirely process-side, but it would be helpful if the title of the proposal defined exactly where these need to be added.

1 Like
7

I spoke with @matthewturk and I’ve gone ahead and update the thread title to more clearly define the scope of the feature being reviewed here (an addition to the PredicateExpressions API to support nil literal comparisons in the PredicateExpression tree produced by the #Predicate) macro. Hopefully that helps reduce any confusion and narrow in the focus of the review a bit!

2 Likes
8

I understood the proposal was about the Predicate macro. My suggestion was just replacing NilLiteral with _OptionalNilComparisonType, since it's a type already defined in the standard library and doesn't introduce a generic parameter. The additional overloads for build_Equal in the proposal would remain, but only have their parameter type changed.

9

Very nice! I filed the issue PredicateExpressions.Equal requires Equatable conformance for comparing an optional value with "nil" · Issue #711 · swiftlang/swift-foundation · GitHub about this, so thanks for addressing. As I recall we worked around this in our predicate editor by simply requiring `Equatable`, which was fine for our particular use case, but this would certainly have helped if we hadn’t been able to do that.

2 Likes
10

If I’m not mistaken, #Predicate substitutes occurrences of nil expression syntax with PredicateExpressions.build_NilLiteral(), which returns an instance of NilLiteral. The new overloads could accept _OptionalNilComparisonType instead, but wouldn’t we also have to update how the macro works for the types to line up again?

11

Taking off my review manager hat for a moment to speak to this and expand upon what @matthewturk mentioned above:

_OptionalNilComparisonType isn’t really an option for use here because it serves a different purpose than PredicateExpressions.NilLiteral. All components of a Predicate's expression tree must conform to PredicateExpression. This protocol provides requirements for each component - namely the ability to produce a generic Output type given a set of bindings. If you try to conform _OptionalNilComparisonType to PredicateExpression you’ll find that it actually isn’t possible. Since PredicateExpression requires a generic Output type, _OptionalNilComparisonType would be required to declare some Output type that is Equatable which is not possible since its output can be anything. That is why PredicateExpressions.NilLiteral is generic over the Output type as well - the use of the generic parameter is a feature rather than an undesired aspect here - it allows it to satisfy the generic requirements of PredicateExpressions.Equal when used with any other Equatable type.

In addition to the above but possibly less critical, we typically don’t conform other standard types to PredicateExpression but rather create PredicateExpression types nested in the PredicateExpressions namespace (for example, we have PredicateExpressions.KeyPath which is distinct from Swift.KeyPath).

For those reasons I don’t think _OptionalNilComparisonType is an API to use here - rather PredicateExpressions.NilLiteral is the PredicateExpression type that represents a _OptionalNilComparisonType. Does that help clarify/answer your question?

9 Likes
12

Thanks for the detailed explanation!

2 Likes
13

Hello all,

The review of SF-0035 has concluded as of 2026-02-25. The discussion was positive and questions were clarified, and the proposal is now accepted by the Foundation workgroup.

Thank you all for participating!

2 Likes