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