C++ pattern matching is coming

[Dukc]

On Monday, 24 October 2022 at 20:29:55 UTC, Walter Bright wrote:
> On 10/24/2022 12:12 PM, Paul Backus wrote:
>> The problem with using @live and @safe together is that (a) 
>> you cannot *safely* call a @live function from a non- at live 
>> function, or vice-versa (because non- at live functions will not 
>> honor the above rules), and (b) as a consequence, changing a 
>> function from @safe to @safe @live is a breaking API change.
>> 
>> This means that existing @safe D projects will not be able to 
>> adopt @live, and the community will have to build an entirely 
>> new @safe @live ecosystem from the ground up in order to see 
>> any benefit in practice. The more likely outcome is that D 
>> users will stick with their existing @safe codebases (which 
>> they've invested time and money in) and ignore @live 
>> altogether.
>
> @live does indeed allow for incremental, function by function 
> use of @live. This is inevitable as using an 
> ownership/borrowing system requires restructuring the 
> algorithms and data structures.

I demonstrate what I think Paul means. Suppose we have a manually 
managed custom pointer type, designed for safe usage in `@live` 
functions:

```D
struct MMptr (Pointee)
{ @system Pointee* data; // Assuming @system variables DIP is 
implemented
   // implementation...
}

// The only way to create MMptrs except for nulls
MMptr!T mallocate(T)()
{ import core.lifetime;
   import core.stdc : malloc;
   auto mem = cast(T*)malloc(sizeof(T));
   return MMptr(mem.emplace);
}

// The only way to get rid of owned MMptrs
void free(T)(MMptr!T expired)
{ import core.stdc : free;
   destroy!false(*expired.data);
   free(expired.data);
}
```

This is great when all client code is `@live`. Perfectly `@safe` 
as far as I see. Yet you cannot mark `free` `@trusted`. This is 
because then there would be nothing to prevent a `@safe` but 
non-`@live` function using it and corrupting the heap with 
dangling pointers.