An incoherent Rust

The table is on the stack because we conjured into existence a temporary, so it's exactly as if the programmer had conjured the variable as a local by hand. Suppose our table is named SOUP

    const SOUP: [f32; 1000] = [ /* whatever */ ];
    let foo = something(blah_blah, blah) * SOUP[4];
    // The optimiser will see that SOUP[4] is exactly say 1.5_f32 so it'll just do
    // the same as if we'd calculated something(blah_blah, blah) * 1.5_f32

However

    let foo = something(blah_blah, blah) * SOUP[blah];

Now blah is a variable, we might need any value from SOUP, the optimiser doesn't know what values it might have - so a temporary is conjured into existence, equivalent to:

    let tmp = SOUP;
    let foo = something(blah_blah, blah) * tmp[blah];

You do presumably recognise that this now puts SOUP on the stack right? The temporary is equivalent, but without the explicitness.

Now if you know what you're doing you would of course have one single place in your program where you do this:

    static SOUP: [f32; 1000] = [ /* whatever */ ];

And now there's an immutable global named SOUP and like "the good ole days" we don't keep writing this huge data blob to the stack only to subsequently look at a single element. But that's not the thing the noob wrote so that's not what they get.

"Sufficiently smart compilers" are a very gradual miracle. In theory a compiler could realise this is a good idea, in practice today I doubt you will find such a compiler, so just write explicitly that you want a single variable if that's what you want.

I don't know what quotemstr was specifically talking about, but here's my own take.

The ideal error handling is inferred algebraic effects like in Koka[1]. This allows you to add a call to an error-throwing function 15 layers down the stack and it's automatically propagated into the type signatures of all functions up the stack (and you can see the inferred effects with a language server or other tooling, similar to Rust's inferred types).

Consider the following Rust functions:

    fn f1() -> Result {...}
    fn f2() -> Result {...}
    fn f3() -> Result {...}
    fn f4() -> Result {f1()?; f2()?;}
    fn f5() -> Result {f1()?; f3()?;}
    fn f6() -> Result {f4()?; f5()?;}

Now, how do you define E4, E5 and E6? The "correct" way is to use sum types, i.e., `enum E4 {E1(E1), E2(E2)}`, `enum E5 {E1(E1), E3(E3)}` and `enum E6 {E1(E1), E2(E2), E3(E3)}` with the appropriate From traits. The problem is that this involves a ton of boilerplate even with thiserror handling some stuff like the From traits.

Since this is such a massive pain, Rust programs tend to instead either define a single error enum type that has all possible errors in the crate, or just use opaque errors like the anyhow crate. The downside is that these approaches lose type information: you no longer know that a function can't return some specific error (unless it returns no errors at all, which is rare), which is ultimately not so different from those languages where you have to guard against bizarre runtime errors.

Worse yet, if f1 has to be changed such that it returns 2 new errors, then you need to go through all error types in the call stack and flatten the new errors manually into E4, E5 and E6. If you don't flatten errors, then you end up rebuilding the call stack in error types, which is a whole different can of worms.

Algebraic effects just handle all of this more conveniently. That said, an effect system like Koka's isn't viable in a systems programming language like Rust, because optimizing user-defined effects is difficult. But you could have a special compiler-blessed effect for exceptions; algebraic checked exceptions, so to speak. Rust already does this with async.

[1] https://koka-lang.github.io

One could argue flying is just controlled falling.