I think you’ve unraveled the mystery of why that didn’t catch on in nearly 40 years of C.

Honestly it’s got to be the biggest disappointment in computer science that nothing has displaced C as the Franca Lingua. And now with the advent of AI, I don’t think anyone is going to care anymore. Rust will be the future, but not because it’s ergonomic, but because it can prevent memory errors.

Programming language development has essentially ceased, no? Because now that you have a super powerful, ceaseless special interest personality that can be ordered to be specially interested in any problem. The actual problem - a dearth of things that special interest personalities will do for little to no money - has been solved.

They allow for types like "String or Integer". A function which returns a value of type "A" can automatically also be assigned to a variable of type "A or B", and a function which accepts a parameter of type "A or B" can automatically also be passed a variable of type "A". This is not the case for algebraic sum types, which require somewhat inconvenient wrapping or unwrapping.

Unlike algebraic sum types, set-theoretic union types are also not necessarily mutually exclusive. E.g. a number of type "Integer or Float" could be both. Moreover, set-theoretic types can be generalized to arbitrary Boolean combinations of types, e.g. "A or (B and not C)", possibly involving disjunctions, conjunctions, and negations (since {and, or, not} are functionally complete). That's not possible for algebraic sum/product data types. Though there is no mainstream language yet with a set-theoretic type system that supports negation types.

    typedef struct {
        int status;
        float value;
    } div_result_t;

    div_result_t divide(float a, float b) {
        if (b = 0.0) return (div_result_t){ E_DIVZERO };
        return (div_result_t){ 0, a / b };
    }

On MSVC: The caller allocates `sizeof(div_result_t)` on the stack, passes the the pointer to that space as an implicit first argument to `divide` in register x0/rcx. The function returns the same pointer as its result in x0/rax.

The latter is almost equivalent to you passing a pointer manually - but the compiler does it for you. In the former case, it's actually more efficient to use the struct as we don't even need to touch the stack - all arguments and returns are in registers (for structs up to two "eightbytes" - ie, 16-bytes).

IMO, if it intended to use automatic storage duration, and the size of the struct is small enough, returning by value is preferable - it performs better on SYSV, and basically automates what you would do manually on MSVC. If it is intended for manual storage duration, then yes, use pass and return by pointer explicitly.

First, you have the "our core libraries/dependencies were written when it was 'C with Classes' and we're going to keep using that style for consistency/laziness/because it's well-tested", and then you have the "C++ is ugly/full of segfaults/hard, I'm going to use <new language> which solves all these problems".

You have to pass those two filters before you get to people who are interested in writing good, modern C++.

    if ([double val, bool ok] = double.TryParse("5.x5"); ok) {
        Console.WriteLine(val);
    } else {
        Console.WriteLine("err");
    }

There actually is another way, but it isn't really that handy (as it is basically just shorthand for multiple assignment):

    func mustInt(v int, err error) int {
        fmt.Printf("got: (%v, %v)\n", v, err)
        return v
    }
    
    func foobar() (int, error) {
        return -123, nil
    }
    
    func badbeef() (int, error) {
        return nil, fmt.Errorf("moo")
    }
    
    func main() {
        vals := []any{
            mustFn(foobar()),
            mustFn(badbeef()),
        }
        fmt.Printf("got vals: %v\n", vals)
    }

    func mustFn[T any](v T, err error) T {
        fmt.Printf("got: (%v, %v)\n", v, err)
        return v
    }
    
    func foobar() (int64, error) {
        return -123, nil
    }
    
    func deadbeef() (string, error) {
        return "weird name for a cafe", nil
    }
    
    func badbeef() (*int, error) {
        return nil, fmt.Errorf("moo")
    }
    
    func main() {
        vals := []any{
            mustFn(foobar()),
            mustFn(deadbeef()),
            mustFn(badbeef()),
        }
        fmt.Printf("got vals: %v\n", vals)
    }

> act on context structures

Same semantics but mutating context is much harder to track, so yes it is preferred to return 2 values.

   typedef struct {
        _Bool ok;
        union {
            double value;
            int error;
        };
    } Result_double;

    Result_double x = strtod·or·error(s, NULL);

    if (!x.ok) {
        handle(x.error);
        return;
    }

    use(x.value);

IEEE 754 was one of the few standards that caused a significant progress of the standardized domain, because what is important for users had precedence over what is important for vendors.

Before IEEE 754, all floating-point implementations attempted to minimize the hardware cost, regardless of what aberrant behavior this would cause, which would confuse the naive users.

A trivial change does though: Just round-trip it.

    int s2d(double*restrict out,const char*restrict in){
     char tmp[99];int r,q=sscanf(in,"%lf%n",out,&r),s=sprintf(tmp,"%lf.",*out);
     return q&&!((r>s)||memcmp(in,tmp,r)||tmp[r]>'0');
    }

That's a feature: Where did the string come from if not the user?

> you cannot set locale, convert, then unset locale

So what? You're not handling multiple locales: You're using the user's locale. If you're making a server, using anything but LANG=C or a utf8 variant is asking for trouble.

I think the point is it's absolutely possible to portably detect errors, some libc's strtod() just don't which ain't the same thing.

I guess that backs up the complaint about portability, if sscanf() doesn't behave that way on all platforms. But on MSVC its behavior is reasonable enough.