C++ pattern matching is coming

[Paul Backus]

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.

It is impossible for both of the following statements to be true 
simultaneously:

1. Existing @safe code can incrementally adopt @live without 
breaking API changes.
2. @live allows code to be made @safe or @trusted that could 
previously only be @system.

If (1) is true, then allowing @live functions to do anything a 
@safe function could not already do would make it possible for 
memory corruption to occur in @safe code. Therefore, (2) must be 
false.

If (2) is true, then the argument in my previous message applies, 
which means that (1) must be false.

Note that DIP 1000 satisfies both (1) and (2)--it can be (and has 
been!) incrementally adopted without breaking existing APIs, and 
it allows some previously- at system code to be made @safe or 
@trusted.