Failable types -> failable functions

[b1ek]

as discussed in #478

i didn't actually change the syntax, just the way how it is handled internally: no more failable types, but failable functions instead

[Ph0enixKM]

@b1ek i think that we should keep failable types because later on we can match on them:

match failabe_func() {
    failed {
        echo "This function failed!"
    }
    ok {
        echo "This function succeeded!"
    }
}

Or even in the future run methods on them:

let a = failable_func()
echo a.is_ok()

[Ph0enixKM]

Also I'm pretty confident that I'd want to do this:

$ command $ or "default value"

And current state of things gives us ease of detecting failable value

[b1ek]

we should keep failable types because later on we can match on them

that can still be achieved with failable functions. my issue with failable types is that they exist only for a brief period of time, don't actually store any data and shouldn't even be considered types:

fun may_fail(): Num? { // declared
    if cond {
        fail 1 // created
    }
    return 123
}

fun accepts_failure(me: Num?): Null { // not allowed to pass as parameter
    ...
}

let a = may_fail(); // not allowed to have a variable with a failable type in it
let b = 123 as Num?; // not an option either

the only use case for it is when a function may fail, which i dont think should be treated as a data type internally:

fun may_fail(): Num?;

let data = may_fail() failed {
    echo status
}
echo "not failed: {data}"

[b1ek]

i just want to clarify that i haven't changed the syntax one bit here. all code that has been written before will work exactly the same. but it will be handled differently internally

[hdwalters]

Assuming we decide to go with this approach, I cannot see anything major wrong with your changes, but have made some minor suggestions.

[Ph0enixKM]

@b1ek I can't found a counterargument. You convinced me on this one

[Ph0enixKM]

I think that the proposed message is the biggest common denominator:

1. It is different enough (The two sentences start with a different letter)
2. It's written the same way

Other changes look good

[mks-h]

I implemented Failable as a type under an assumption that we might or might not turn it into an actual type. I have no issues with the idea of implementing them through an attribute of a function, but do note that this will cement the current way of handling failability (as a function attribute, rather than a type) — and that is probably a good thing.

[hdwalters]

Looks good thanks.

[Ph0enixKM]

We can always pivot this logic if we hit the wall

[Ph0enixKM]

One question though. Are we releasing 0.4.1 with this or we implement it as a feature of 0.5?

[hdwalters]

One question though. Are we releasing 0.4.1 with this or we implement it as a feature of 0.5?

I thought we were not planning to target features for different releases, but instead merge everything to staging, and bump the version number according to impact of changes?

[Ph0enixKM]

Exactly, then this PR has to be rebased

The base branch was changed.

[hdwalters]

Nothing appears to have changed since the rebase; reapproving.

[mks-h]

LGTM, apart from a little code quality change.

[mks-h]

Please revert this part to as it was. This function is only supposed to tell whether the parsed amber function is de-facto failable. Further error handling should be done outside.

[mks-h]

You already do some error handling here, so lets keep all of it here.

[mks-h]

If you extract the error handling, you also won't need to pass these arguments or make the function return a Result.