First Draft: opUnwrapIfTrue

[jmh530]

On Wednesday, 15 July 2026 at 18:41:20 UTC, 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

Hmm, I can kind of think of two ways to think about this.

Suppose we have something built-in like
```d
match(x)
{
     Some(value) => use(value),
     None => handleNone();
}
```
and then you also have the ability to do something like
```d
if (match Some(value) = x) {
     use(value);
}
```

Option 1 would be that the whole thing gets lowered to something 
like
```d
match(x)
{
     Some(value) => use(value),
     _ => {}
}
```
If there's an `else` statement, then you could plug that in to 
the `_ => {}`

Option 2 would be that it gets lowered to something like
```d
if (match(x)
     {
         Some(value) => true,
     _     => false
     }) {
     use(value);
}
```

I would think that Option 2 would kind of be more in line with 
how rust handles in. Once you start thinking about option 1, it 
gets harder to think about if you have `else if` parts.