C++ pattern matching is coming

Steven Schveighoffer schveiguy at gmail.com
Mon Oct 24 01:11:31 UTC 2022


On 10/23/22 9:01 PM, Steven Schveighoffer wrote:
> On 10/23/22 8:29 PM, Walter Bright wrote:
>>> DIP1000 is very keen to conflate different lifetimes and to cut the 
>>> longer one off based on the shorter one.
>>
>> Yup.
>>
>> DIP1000 does not handle what you describe, and isn't designed to. 
>> However, it is still very useful for the vast bulk of cases. It's also 
>> carefully set up to be conservative, i.e. it will always err on the 
>> side of safety.
>>
>> To loosen up the safety is the job of @trusted containers, similar to 
>> Rust's unsafe code blocks, because Rust's expressiveness is limited, too.
> 
> Is this a bug? Because I can't do this from @trusted code:
> 
> ```d
> void foo() @trusted
> {
>      static struct T
>      {
>          Exception ex;
>          ubyte[] buf;
>      }
> 
>      scope buffer = new ubyte[100];
>      T t;
> 
>      t.ex = new Exception("hello");
>      t.buf = buffer;
>      throw t.ex;
> }
> 
> void main() @safe
> {
>      foo();
> }
> ```
> 
> Fails with:
> ```
> onlineapp.d(14): Error: scope variable `t` may not be thrown
> ```

Comically almost, I realized *return values* can be unscoped, so adding 
the following accessor works:

```d
static struct T
{
    Exception ex;
    ubyte[] buf;
    Exception getEx() { return ex; }
}

...

throw t.getEx; // ok, because now we unscoped it
```

This seems like a goofy workaround, still makes me feel like the 
rejection in @trusted code is a bug.

-Steve


More information about the Digitalmars-d mailing list