As a follow-up to this Reddit thread (but I’ve seen similar complaints several times in other places), how do people feel about supporting alternate signatures for main()?
I realize, this is only useful for short examples and such, but first impressions are important.
So, what if we allowed using any of the following?:
fn main()fn main() -> Result<(),u32>fn main() -> MainResult // same as above but with a type alias
As a less invasive middle-ground, I suppose we could also create an attribute macro that wraps body of the function in a closure as suggested in this comment:
#[unwrap_result] fn main()
Youre correct on all counts, but it still feels strange. I feel like there is a better solution, this just seems like a bandaid (in regards to returning result just to use try!)
Yes, that's what I meant.
However, we'd have to explain to developers what this magic macro does, and, IMO, it would look very much like a band-aid.
Hey, here's another idea: Can we restructure try! and FromError such that the return type no longer has to be specifically a Result, and impl FromError for ()?
Something like this:
Unfortunately, right now 'impl<T,E,F> FromError<F> for Result<T,E>...' above conflicts with 'impl<E> FromError<E> for E' from std.
I wonder if negative trait impls would help here? I.e. could we re-define the latter as 'impl<E> FromError<E> for E where E:!FromError<E>' ?
You would want to use a different trait than FromError for that conversion, although the current name isn’t very clear about what it’s producing (it’s technically ErrorFromError or ErrorToError or ErrorConvert), and so it’s hard to find a good name that’s not FromError.
That said, try! sometimes failing doesn’t seem like great API design - the function author may have merely forgotten to specify a Result return type and instead of a nice type error, the function could panic in production.