Reviewing files that changed from the base of the PR and between 2d6cfb4 and 764d533.

• src/NLog/Conditions/ConditionExpression.cs (1 hunks)
• src/NLog/Conditions/ConditionParser.cs (1 hunks)
• src/NLog/Filters/ConditionBasedFilter.cs (1 hunks)
• src/NLog/LayoutRenderers/Wrappers/WhenLayoutRendererWrapper.cs (3 hunks)
• src/NLog/Targets/ConsoleRowHighlightingRule.cs (3 hunks)
• src/NLog/Targets/ConsoleWordHighlightingRule.cs (2 hunks)
• src/NLog/Targets/Wrappers/AutoFlushTargetWrapper.cs (2 hunks)
• src/NLog/Targets/Wrappers/FilteringRule.cs (1 hunks)
• src/NLog/Targets/Wrappers/FilteringTargetWrapper.cs (3 hunks)
• src/NLog/Targets/Wrappers/PostFilteringTargetWrapper.cs (5 hunks)

src/NLog/Conditions/ConditionParser.cs (1)

217-217: LGTM: Simplified empty text handling

The removal of special case handling for empty fixed text is consistent with the broader refactoring to eliminate ConditionExpression.Empty. Always creating a new ConditionLiteralExpression regardless of emptiness simplifies the logic.

src/NLog/Targets/Wrappers/FilteringRule.cs (2)

67-67: LGTM: Property made nullable

Converting the Exists property to nullable ConditionExpression? is consistent with the broader refactoring to remove ConditionExpression.Empty.

---

73-73: LGTM: Property made nullable

Converting the Filter property to nullable ConditionExpression? aligns with the refactoring pattern across the codebase.

src/NLog/Targets/ConsoleWordHighlightingRule.cs (2)

71-71: LGTM: Property made nullable

Converting the Condition property to nullable ConditionExpression? is consistent with the refactoring to eliminate ConditionExpression.Empty.

---

158-158: LGTM: Simplified condition checking

The updated logic correctly uses null checking instead of comparing against ConditionExpression.Empty. The behavior remains equivalent: if no condition is specified (null) or the condition evaluates to true, the method returns true.

src/NLog/Conditions/ConditionExpression.cs (1)

56-60: LGTM: Nullable-aware implicit conversion

The updated implicit conversion operator correctly handles nullable inputs by:

1. Accepting nullable string? parameter
2. Returning nullable ConditionExpression?
3. Explicitly returning null for null input strings

This foundational change enables the nullable condition pattern throughout the codebase and eliminates the need for ConditionExpression.Empty.

src/NLog/Targets/Wrappers/AutoFlushTargetWrapper.cs (2)

67-67: LGTM: Property made nullable

Converting the Condition property to nullable ConditionExpression? aligns with the broader refactoring to remove ConditionExpression.Empty sentinel values.

---

152-152: LGTM: Simplified condition evaluation

The updated condition check correctly uses null checking instead of comparing against ConditionExpression.Empty. The logic remains equivalent: flush if no condition is specified (null) or if the condition evaluates to BoxedTrue.

src/NLog/LayoutRenderers/Wrappers/WhenLayoutRendererWrapper.cs (3)

59-59: Property conversion to nullable looks correct.

The change from ConditionExpression to ConditionExpression? properly reflects the optional nature of the condition and eliminates dependency on the ConditionExpression.Empty singleton.

---

70-71: Validation logic simplified appropriately.

The null check is the correct way to validate the required When property now that it's nullable. The removal of the ConditionExpression.Empty check aligns with the refactoring goal.

---

106-106: Condition evaluation logic correctly updated.

The simplified logic When is null || true.Equals(When.Evaluate(logEvent)) maintains the same behavior while properly handling the nullable condition.

src/NLog/Filters/ConditionBasedFilter.cs (2)

54-54: Property correctly converted to nullable.

The change to ConditionExpression? properly eliminates the dependency on the Empty singleton pattern.

---

61-62: Null-conditional evaluation correctly implemented.

The use of Condition?.Evaluate(logEvent) properly handles the nullable condition, returning FilterDefaultAction when the condition is null or doesn't evaluate to true.

src/NLog/Targets/ConsoleRowHighlightingRule.cs (3)

58-63: Constructor parameter correctly updated to nullable.

The constructor parameter change to ConditionExpression? condition is consistent with the nullable Condition property and maintains the same assignment behavior.

---

68-68: Default property correctly uses null.

Using null instead of ConditionExpression.Empty in the Default property is the proper way to represent no condition in the nullable pattern.

---

93-93: Condition evaluation logic properly simplified.

The logic Condition is null || true.Equals(Condition.Evaluate(logEvent)) correctly handles the nullable condition and maintains the expected behavior.

src/NLog/Targets/Wrappers/FilteringTargetWrapper.cs (3)

101-101: Property getter/setter correctly handles nullable type.

The implementation properly handles the nullable ConditionExpression? by safely casting and accessing the underlying filter's condition while passing nullable values to CreateFilter.

---

112-113: Validation logic correctly handles internal filter structure.

The check for both null and ConditionBasedFilter.Empty is appropriate since the internal filter system still uses the Empty singleton while the public API uses nullable conditions.

---

156-162: CreateFilter method correctly bridges nullable API with internal filter system.

The method appropriately handles the nullable input by returning ConditionBasedFilter.Empty for null values and creating a proper filter for non-null conditions.

src/NLog/Targets/Wrappers/PostFilteringTargetWrapper.cs (4)

98-98: DefaultFilter property correctly converted to nullable.

The change to ConditionExpression? is consistent with the refactoring pattern and properly represents the optional nature of the default filter.

---

116-121: Validation logic correctly simplified for nullable properties.

The null checks for rule.Exists and rule.Filter are appropriate now that these properties are nullable, eliminating the need to check against ConditionExpression.Empty.

---

142-142: Condition check correctly simplified.

The simplified null check properly handles the case where no filtering condition is determined, allowing all events to pass through.

---

178-198: EvaluateAllRules method correctly updated for nullable handling.

The method properly handles nullable conditions with the null-conditional operator rule.Exists?.Evaluate(logEvents[i].LogEvent) and returns the appropriate nullable ConditionExpression? type.