C++ pattern matching is coming

[Walter Bright]

On 10/24/2022 12:26 PM, rikki cattermole wrote:
> On 25/10/2022 8:12 AM, Paul Backus wrote:
>> 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.
> 
> Right now I'm building up my library infrastructure using @safe and DIP1000.
> 
> @live on a memory object sounds very attractive to ensuring memory owned in a 
> data structure/nullable ext. stays alive and won't be deallocated.
> 
> But not on a function, that asks far too much of people, so I'm 100% in 
> agreement with Paul over this.

@live doesn't actually add any *new* semantic behavior to a function. All it 
does is add checking. This means it can be mixed and matched with non- at live 
functions as the user sees fit. This is on purpose.

It seems you're suggesting attaching this behavior to the pointer, rather than 
the function. That means multiple pointer types.

Multiple pointer types have been tried many times. They are attractive in 
theory, but work out poorly in practice. For example, take:

     char* strcpy(char* dst, char* src);

With two pointer types, now you have 4 implementations of strcpy rather than 
one. It does not scale.