Currently Intercom assumes any method can return an error. This allows Intercom to implement its own fallible type conversions. However there are many places where these type conversions just shouldn't be needed as there really shouldn't be anything that might fail in the method call (in Rust terms anyway - invalid pointers will still cause access violations, etc).
Proposal
Introduce Infallible<T> return value. This is a special return value that intercom macros (namely the return handler) recognize. In effect this is #[repr(transparent)] over T.
The result of using Infallible<T> return value would make Intercom use InfallibleExternInput/InfallibleExternOutput traits in place of the usual ExternInput/ExternOutput traits when converting types. These new traits provide the same functionality as the old traits without using a Result return value.
Naturally not all conversions can be used with these traits. What this would mean in effect is that the user needs to make a choice between infallible return value or more convenient types. The user should always be able to receive their parameters through infallible conversions by using raw parameter types: Instead of using String as an input parameter, use *const c_char or IntercomString instead - avoiding the possible failure in the generated code and allowing the user to handle it in a way that doesn't cause the whole method to fail.
Hopefully we can still have generic implementations of impl ExternInput for T: InfallibleExternInput so there is only ever need to implement one trait for a type (or two, including ...Output).
Currently Intercom assumes any method can return an error. This allows Intercom to implement its own fallible type conversions. However there are many places where these type conversions just shouldn't be needed as there really shouldn't be anything that might fail in the method call (in Rust terms anyway - invalid pointers will still cause access violations, etc).
Proposal
Introduce
Infallible<T>return value. This is a special return value that intercom macros (namely the return handler) recognize. In effect this is#[repr(transparent)]overT.The result of using
Infallible<T>return value would make Intercom useInfallibleExternInput/InfallibleExternOutputtraits in place of the usualExternInput/ExternOutputtraits when converting types. These new traits provide the same functionality as the old traits without using aResultreturn value.Naturally not all conversions can be used with these traits. What this would mean in effect is that the user needs to make a choice between infallible return value or more convenient types. The user should always be able to receive their parameters through infallible conversions by using raw parameter types: Instead of using
Stringas an input parameter, use*const c_charorIntercomStringinstead - avoiding the possible failure in the generated code and allowing the user to handle it in a way that doesn't cause the whole method to fail.Hopefully we can still have generic implementations of
impl ExternInput for T: InfallibleExternInputso there is only ever need to implement one trait for a type (or two, including...Output).