On 4/22/2024 10:33 AM, Richard (Rikki) Andrew Cattermole wrote:
> I was really looking forward to your recent DConf Online talk about matching.
> 
> It is why I have avoided this idea up until now, I wanted to see what you have come up with.
> 
> Same thing for sum types.
> 
> If you have any design work on this subject, I think other people not just myself would be interested in having a read.

Sumtypes must come before pattern matching. I had a proposal for it:

https://www.digitalmars.com/d/archives/digitalmars/D/sumtypes_for_D_366242.html

On Monday, 22 April 2024 at 16:45:35 UTC, Walter Bright wrote:
> I've thought about it for a while now. Improving switch has a lot of issues with it, such as the unusual scoping rules, the ability to goto in and out of it, the ability to interleave switch/case with other looping constructs (!).
>
> It's unsalvageable.
>
> It's better to create a new construct, let's say "match", and design an unconstrained syntax for it to accommodate pattern matching in particular.
>
> ("match" is already an identifier in common use, some other name would be better.)

int x = 1;

check x {
    1 => writeln!("one"),
    2 => writeln!("two"),
    3 => writeln!("three"),
    4 => writeln!("four"),
    5 => writeln!("five"),
    _ => writeln!("something else"),
}

On Wednesday, 24 April 2024 at 06:52:51 UTC, ShowMeTheWay wrote:
> On Monday, 22 April 2024 at 16:45:35 UTC, Walter Bright wrote:
>> I've thought about it for a while now. Improving switch has a lot of issues with it, such as the unusual scoping rules, the ability to goto in and out of it, the ability to interleave switch/case with other looping constructs (!).
>>
>> It's unsalvageable.
>>
>> It's better to create a new construct, let's say "match", and design an unconstrained syntax for it to accommodate pattern matching in particular.
>>
>> ("match" is already an identifier in common use, some other name would be better.)
>
> int x = 1;
>
> check x {
>     1 => writeln!("one"),
>     2 => writeln!("two"),
>     3 => writeln!("three"),
>     4 => writeln!("four"),
>     5 => writeln!("five"),
>     _ => writeln!("something else"),
> }

aka ..a new language construct (i.e. an improvement over a switch expression) called 'a check expression'.

On 4/28/24 01:58, Basile B. wrote:
> On Saturday, 27 April 2024 at 14:58:19 UTC, IchorDev wrote:
>> On Tuesday, 16 April 2024 at 16:00:48 UTC, Basile B. wrote:
>>> About this, the main point is rather
>>>
>>> ```d
>>> /*-->*/ const /*<--*/ int myvalue = switch(code) {
>>>     // ...
>>> };
>>> ```
>>>
>>> "ah finally you can define a const var decl that relies on branching" (without using the conditional expression...)
>>
>> You can already do that.
>> ```d
>> const string myValue = (){
>>     switch(code){
>>         case 1:    return "what";
>>         case 2, 3: return "ok";
>>         default:   return "no";
>>     }
>> }();
> 
> Sure but the matching AST is unnecessarily complex. A function literal, plenty of return statements, at least 1 capture. Consequently the path borrowed by the compiler is much more complex, it has to do things that would not be done with the expression: return type inference, block exits, etc. Then without optimizations enabled that does not have the equivalent runtime performances.
> 

Specifically promoting switch to an expression would be a wasted opportunity to generalize this to other types of statements, such as try statements.

Here are some examples in pseudo-D of how that could be useful. In these examples, a hypothetical do keyword could prefix any statement and turn it into an expression, and a yield statement would provide the result of evaluating that expression:

    // no need to (default-)initialize file first
    auto file = do try {
        yield open(path);
    } catch (ErrnoException ex) {
        if (ex.errno == ENOENT)
            return;  // return from caller
        throw ex;
    };
    // use file without catching ErrnoException
    file.write("hello");

Or foreach statements:

    const value = do {
        foreach (item; someOpApplyStruct)
            if (f(item))
                yield item;
        throw new NotFoundError;
    };

If the do-ed statement would run off the end (as with a non-void function lacking a return statement) that would be an error.

Besides initializing variables, another advantage of promoting statements to expressions directly instead of through a called lambda is that you can have control flow out of the expression into another statement, such as by break, continue, or return statements.