I'm experimenting with a solution in C3 that has this behaviour. I don't have a sum type as such, but the binding acts as one. I call the binding a "failable".

    int! a = getMayError();
    // a is now either an int, or contains an error value.

    // foo(a) is only conditionally invoked.
    int! b = foo(a);

    // The above works as if it was written:
    // int! b = "if a has error" ? "the error of a" : foo("real value of a");

    // A single if-catch with return will implicitly unwrap:
    if (catch err = b) {
       /* handle errors */
       return;
    }
    /* b is unwrapped implicitly from here on and is treated as int */

    if (try int x = a) {
       /* conditionally execute if a isn't an error */
    }

I think this is kind of formalizing the poison technique but external from the call (that is, "foo" does not need to know about "failables" or return one, the call is skipped on the caller side). Here are some more examples: http://www.c3-lang.org/errorhandling/

I'd be interested in hearing what you think about this (experimental) solution Walter.

You should give a serious try to sum types, btw. They're unambiguously good, and have been in use for the last 40 years at least. To me, not having them is an immediate disqualifier for a modern static language (along with some basic form of pattern matching that goes hand in hand with them).

So that sounds like the way invalid floating point operations give NaN, and then the NaN propagates everywhere. I've always found this super annoying because its often hard to figure out where the NaN comes from. Does your solution differ from this in a way that's less annoying?

How does this work with operations that return basic types like int or string? Can a string be poisoned?