C++ pattern matching is coming

[Walter Bright]

On 10/23/2022 4:54 PM, Timon Gehr wrote:
> As soon as people try to use it in production they will run into some issues 
> with expressiveness. For example, DIP1000 does not even support storing objects 
> with different lifetimes in different fields of the same struct. (Real case that 
> came up on Discord today.)

That's right. DIP1000 does not track lifetimes at all. It only does scoped 
lifetimes. Tracking requires data flow analysis, which is in the purview of @live.

> The underlying issue is that DIP1000 lacks a modular way to track different 
> lifetimes. E.g., DIP100 does not allow having an array allocated on a region 
> allocator, containing references pointing to objects allocated on a distinct 
> region allocator with correct lifetime tracking. As soon as you store things in 
> the array and want to get them back out, if it works at all, their lifetimes 
> will be limited by the lifetime of the region allocator that backs the array 
> storage, even if their own allocator actually is longer-lived.

That's right.


> 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.