Delyan Angelov

`c := a.@or(b)` should be a checker error, since the type of `a` is `Maybe`, while the type of `b` is `Maybe` i.e. incompatible.

`println(a)` should work, just like `println(a.str())` does

`println('$a')` should work too, just like `println(a.str())` does

`ra := a.as_ref()` not inferring that the return type should be `Maybe` and NOT `Maybe` as it does, is the weirdest of all listed bugs here, and probably the most...

Uncommenting the `pub fn (m Maybe) map(f fn (v T) U) Maybe {` method also leads to weird checker errors, that are not directly related to the map method: 

In the original report, there was also this: ```v // pub fn (m Maybe) flatten() Maybe { // return m.unwrap_or(noth()) // } ``` ... which I could not express with...

The only remaining issue is: `ra := a.as_ref()` is *not* inferring, that the return type should be Maybe and NOT Maybe as it does: `dump( typeof(ra).name )` produces: `[g.v:142] typeof(ra).name:...

I suggested `git revert 6e24f7e` which undoes specifically that commit, so I think the problem /difference in expectation between the user code and vlib is in it. That commit corresponds...

btw, is already on v2.27, it may be a good idea to update our copy as well. Unlike some other thirdparty libraries, they are usually very careful to not make...

is it ready for review?