Should we warn about public function uses private type aliases?

language design
1

In case we have:

type Output = i32;
pub const OUTPUT: Output = 1;
pub fn test() -> Output {
    OUTPUT
}

Most modification of private things should be minor changes, but with Output be modified, the return type of public function test is also modified, and thus we are actually making a major change.

Should we warn about public function using private things (even aliases)?

This idea comes directly from thread Simplified syntax for simple functions. IMHO public function's signature cannot be inferred, since it might be changed silently.

3 Likes
2

I don't think so. In most cases, crates tend to define its own Error type, and inside crate implementation, a Result is aliased to be function's return type to simplify boilerplates of writing custom Error type everywhere. And this Result type is usually not made public.

3

Counter examples:

I've run into a few situations where it made sense to use the Result type alias from a dependency because a function can only ever return its Error type. I'd argue that (especially for Result) having access to this type alias is still useful. For example when writing Debug implementations you probably want to use std::fmt::Result<T> instead of Result<T, std::fmt::Error> or having to add your own type alias.

You use type aliases to shorten types. Why would you want/need to remove that convenience from your users, especially when the type that is aliased is already part of your function signatures.

6 Likes