C++ pattern matching is coming

[Timon Gehr]

On 10/25/22 00:26, Walter Bright wrote:
> On 10/24/2022 6:14 AM, Timon Gehr wrote:
>> - have more than one lifetime that exceeds the current function's 
>> lifetime. I.e., multiple distinct return annotations, ideally an 
>> arbitrary number, by allowing the return annotation to be 
>> parameterized by a lifetime variable.
> 
> This has been proposed before (I think by deadalnix), and much much 
> earlier (before Rust) by Bartosz Milewski.
> ...

Pretty sure this has already been proposed in some academic paper in the 
1990's or earlier.

> My objection to it was based on its complexity.

It's barely more complicated than return annotations. `inout` grew into 
a complex type unsound mess exactly because D was avoiding such parameters.

> People have a hard 
> enough time with `scope`. I am frankly amazed that Rust has been able to 
> sell the idea of such complicated annotations, though Rust does seem to 
> attract programmers who revel in such :-) I often hear stories about 
> Rust developers just trying random annotations to get it to pass the 
> compiler, having little concept of how it actually works.
> ...

Well, one goal of @safe is to reduce the amount of damage that can be 
done by incompetent developers. Let them randomly try stuff. If that 
allows them to write memory safe code, more power to them I guess.

Anyway, for the cases where DIP1000 is adequate, no other annotations 
are needed. Library developers do need them though.

> The design of dip1000 does not preclude this, however, and it's good to 
> see how far we can push things and avoid needing such complexity.
> 
>> - have such parameterized scope return annotations on fields of 
>> aggregates.
> 
> Same problem. Let's see how far we can get without them.
> ...

It does not allow me to do most of the things I'd like to do with 
lifetime tracking. At least `scope` is checked by the compiler more 
reliably now, which is good.

> P.S. another annotation that nobody is able to use effectively (or 
> correctly) is C's `restrict` keyword. C++ never bothered to adopt it. 
> Though it was a bad design anyway, as the compiler cannot check if it is 
> used correctly, it just generates bad code. ImportC just ignores 
> `restrict`.
> 

(That's a completely different case.)