[FEATURE] Simple switch statement

[oschijns]

match expression in Zen-C are more expressive than switch expression in plain C. But they get transpiled into a sequence of if-else statements. There is currently no way in Zen-C to generate a regular switch statement without using a raw block and write it in plain C. Which can be an issue depending on the C compiler as a switch statement is more likely to be optimized over an if-else sequence.

Add a switch statement (or raw_match) which would transpile trivially to a C switch statement. That switch statement would only support primitive types and enum variants and it would not support ranges. Contrary to C switch, it would not be necessary to add break after each case but instead there would be a fallthrough keyword indicating that a given case can fallthrough the next one defined.

So something like this

switch val {
    0 => {
        println "zero";
        fallthrough;
    },
    1 or 2 or 3 => {
        println "{val}";
    },
    _ => {
        println "unsupported";
    },
}

Would transpile into this

switch (val) {
    case 0: 
    {
        ({ fprintf(stdout, "%s", "zero"); fprintf(stdout, "\n"); 0; });
    }
    case 1:
    case 2:
    case 3:
    {
        ({ fprintf(stdout, "%u", val); fprintf(stdout, "\n"); 0; });
        break;
    }
    default:
    {
        ({ fprintf(stdout, "%s", "unsupported"); fprintf(stdout, "\n"); 0; });
        break;
    }
}

[lunardoesdev]

1. is there some documentation telling that switch is better optimized than if-else?
2. match in Zen-C can also do this, how should it transpile such code?

// Destructuring Enums
match shape {
    Shape::Circle(r)   => { println "Radius: {r}" },
    Shape::Rect(w, h)  => { println "Area: {w*h}" },
    Shape::Point       => { println "Point" },
}

[oschijns]

Someone on the discord proposed that a trivial match expression could be transpiled into a C switch statement. I think this would be an elegant solution.

[kyle-github]

1. is there some documentation telling that switch is better optimized than if-else?

   2. match in Zen-C can also do this, how should it transpile such code?

// Destructuring Enums
match shape {
    Shape::Circle(r)   => { println "Radius: {r}" },
    Shape::Rect(w, h)  => { println "Area: {w*h}" },
    Shape::Point       => { println "Point" },
}

Switch is generally optimized pretty well either with sorted prongs or a jump table (for example). If-else is optimized in some cases but I am not sure of what would drive that. All this in modern C compilers: GCC, Clang, and MSVC. There really are not any others that matter that much for the vast majority of platforms. There are a few specialized embedded ones but those are dying out too as GCC can produce code for almost every embedded CPU used these days.

In your example, if the type is a value in the object/class in the transpiled C code then it could be turned into a switch-case on translation. Not saying it would be easy but I think that is a much better situation than having two similar constructs that overlap in function. Everything the proposed switch can do, match can do.

My advice is to not attempt to optimize Zen-C at this point. Fix the feature set. Get it to work first. Optimize later. IMHO it is already starting to get a collection of features that probably do not interact all that well (only judging from history after watching C++ start nice and end up a complete Frankenstein's monster of a language).

[kyle-github]

As much as I hate to post links to Reddit:

Comparing switch-case to if-else.

It is extremely situation dependent which is faster.

So, please, just keep match and do not add anything else unless you can prove that there are common cases where adding switch/case would be a clear win.

[kyle-github]

Even a small change in how the CPU does branch prediction can completely skew the results.

In 99.99% of the cases, clarity of code is far more important than the performance of low level constructs like this.

[Zuhaitz-dev]

This makes more sense as a discussion for now.

[Zuhaitz-dev]

Now that we have implemented RFC (Request for Comments), this makes more sense in that repository and not here as a discussion.