5 ms·
> Of course, Rust doesn't forbid having it the other way around -- we could make Output a generic parameter too, and have overloaded functions which can have di
by dan00 10y ago
> Of course, Rust doesn't forbid having it the other way around -- we could make Output a generic parameter too, and have overloaded functions which can have different output types for the same input (and need type annotations to choose). But we don't want FnOnce to work that way, so we don't have it like that.
Can you please explain why FnOnce shouldn't work this way?
- Manishearth 10y agoBecause overloading the return type (for the same inputs) is pretty unusual :) Rust has the machinery to deal with this -- you'd need type annotations -- it just gets annoying. Specific functions in Rust do get "overloaded" by return type by returning a generic parameter (e.g. the collect() method on iterators), but in general functions are expected to work without needing type annotations on return. I mean, allowing this kind of use of FnOnce isn't a bad idea. I don't see major issues with it, just minor ones. That's not the choice that was made during the design. I'm sure if we looked at the original design rfcs this point will have come up somewhere :) I wasn't involved in that decision, so I'm not aware of the exact reasoning.
- dan00 10y agoThanks! I just thought their might be some quite important technical reasons for this decision. After all overloading the return type is quite usual and extremly helpful for parsing or the conversion of types. But these kind of operations most likely will be done with a Trait in Rust, so having this option for closures might not be that important.
- Manishearth 10y agoExactly -- it only stops you from creating function-likes that have multiple return types (not closures, because closures aren't locally generic anyway). If you really need such behavior, regular generic functions or traits will work, e.g. `.collect()`