First Draft: opUnwrapIfTrue

[Richard (Rikki) Andrew Cattermole]

On 16/07/2026 6:41 AM, Paul Backus wrote:
> On Tuesday, 14 July 2026 at 03:08:47 UTC, Mindy (0xEAB) wrote:
>> On Thursday, 26 February 2026 at 16:01:22 UTC, Paul Backus wrote:
>>> This seems like an entirely self-inflicted problem. You've designed 
>>> an API that's a pain in the butt to use, and now you want to add a 
>>> language feature to compensate for your bad design.
>>
>> Yeah, how about we add proper sumtypes to the language instead of 
>> duct-taping on features to make up for the lack thereof?
> 
> The specific feature whose absence this proposal is duct-taping over is 
> pattern matching. It's basically a special case of Rust's "if let":
> 
> https://doc.rust-lang.org/book/ch06-03-if-let.html

Another language is Swift, where the compiler has hard coded knowledge 
of standard Optional library type. The binding in if statements is 
unrelated to matching, and only exists for this one type.

Given D communities need for user supplied types, as result types are 
much more numerous in nature than the simple error handling primitive, 
it makes more sense for us to pull the behavior out as a compiler hook 
instead.

However we are not getting matching to replace this. I tried that, it 
got denied already.

While I could potentially accept match expressions solve most of the 
same problems, due to wanting the integration with if statements 
specifically like every other language that supports result types, we 
may end up with multiple features regardless, but perhaps with a little 
bit better integration between the two (which would be a good thing).