|
|
|
|
|
by mananaysiempre
1777 days ago
|
|
Hm. OK. I tried writing a response several times but I still feel confused. Can you explain what you mean by “not the type but the binding”? Note that I know the Haskell but not the Rust (guessing from the “Result” name) way of working in this style. (Not necessarily relevant or correct thoughts: - Your language still seems to mark potentially-failed values in the type system, even if it writes them T! not Either Error T or Result<Error, T>; - The way Haskell’s do-notation [apparently implemented as a macro package in Rust] is centred around name binding seems very close to what you’re doing, although it [being monadic, not applicative] insists on sequencing everything, so fails the whole block immediately once an error value occurs; - Of course, transparently morphing a T-or-error into a T after a check for an error either needs to be built into the language or requires a much stronger type system; Haskell circumvents this by saying that x <- ... either gives you a genuine T or returns failure immediately, which is indeed not quite what you’re doing.) |
|
Here is an example:
This also means that `int!` cannot ever be a parameter, nor a type of a member inside of a struct or union.The underlying implementation is basically that for a variable `int! x` what is actually stored is:
The semantics resulting from this is different from if `int!` had been something like Which is what a Result based solution would work like. In such a solution: