?. Null-Safety Fails with match Method on Enums

[NipponSunrise]

Description of the Issue

The null-safety behavior of the ?. operator does not work correctly when calling the match method on a null value. This results in a TypeError: v is null, even though the ?. operator is expected to prevent method calls on null.

---

Minimal Reproducible Example (see here)

class Test {
	static function main() {
		var v:TestEnum = Value1;
		trace(v?.getName()); // output: Value1
		trace(v?.match(Value1)); // output: true

		v = Value2;
		trace(v?.getName()); // output: Value2
		trace(v?.match(Value1)); // output: false

		v = null;
		trace(v?.getName()); // output: 
		trace(v?.match(Value1)); // Null Pointer Exception occurs here
	}
}

enum TestEnum {
	Value1;
	Value2;
}

---

Expected Behavior

The ?. operator should properly handle null values and avoid calling the match method when the value is null. For example, if v = null, the statement trace(v?.match(Value1)); should evaluate to null without throwing an error.

---

Actual Behavior

When v?.match(Value1) is called and v is null, a TypeError: v is null is thrown, breaking the expected null-safety behavior of the ?. operator.

---

Environment

• Haxe Version: 4.3.6
• Target Platform: html5 (other not checked)

---

Additional Information

This issue violates the null-safety guarantees of the ?. operator, leading to unexpected runtime errors when relying on this functionality in code.

[Simn]

Since 46481f6 this gives an error.

I don't know if this is worth supporting. My intuition is that null?.match(pattern) looks like it should return false, not null, but that's not how ?. works in general.

[NipponSunrise]

Both v.match(Value1) and v?.match(Value1) result in a Null Pointer Exception, meaning the only current safe approach is the old-school if (v != null && v.match(Value1)). Regardless of how this issue is resolved, the ?. operator should behave correctly in all cases, as it is expected to ensure null-safety.

[Simn]

Yes that's why this errors now to communicate that null-safety isn't supported by ?.match.

I'd actually be open to making the normal value.match null-safe, i.e. make nullValue.match(null) work. Then there are no controversies about whether it should yield null or false.

[back2dos]

FWIW nullable enums actually work fine in swtich and with match: https://try.haxe.org/#F6eD114C

I'd actually be open to making the normal value.match null-safe, i.e. make nullValue.match(null) work. Then there are no controversies about whether it should yield null or false.

Well, dunno, given the above circumstances I would say:

1. the null check could be generated if the type is non-nullable and nullsafety is disabled (so users would have a chance not to incur the code / speed cost)
2. the ?.match is not supported error could suggest addjusting the type

[Simn]

Did you mean a Null<Option<String>> there? The switch version fails without it, the match version gets entirely optimized away by the analyzer.