Consider substituting type aliases in "public-in-private" checker

[petrochenkov]

E.g. allowing things like

pub struct SomethingLongButPublicWithLotsOfParameters;
type ShortPrivAlias = SomethingLongButPublicWithLotsOfParameters;
pub fn public_function(arg: ShortPrivAlias) {}

This was originally done in #29973, but reverted later to follow the letter of RFC 136.
Now it starts hitting people. I think this should be reconsidered sooner than later to reduce the number of annoyed people.
Type alias substitution reduces the breakage by 25% according to the crater data.

[sgrif]

Just to give a concrete example, the current behavior even disallows type aliases in locations which are effectively private. An example from diesel is https://github.com/sgrif/diesel/blob/c8127d408f759faa056503014cd00e92479215e0/diesel/src/query_builder/select_statement/dsl_impls.rs#L54-L67, where the type alias is purely used for brevity in what is effectively an internal impl of a trait, but is disallowed because the trait itself is public.

[petrochenkov]

what is effectively an internal impl of a trait, but is disallowed because the trait itself is public.

The logic is that both the trait and the type are public, so the impl is public as well. (But this is a digression)

[sgrif]

Right, I fully understand the logic. My argument is that it's an ergonomics
issue in places where while that is technically true, it is not
semantically true (for lack of a better word).

On Sun, Dec 20, 2015, 6:04 PM Vadim Petrochenkov notifications@github.com
wrote:

what is effectively an internal impl of a trait, but is disallowed because
the trait itself is public.

The logic is that both the trait and the type are public, so the impl is
public as well.

—
Reply to this email directly or view it on GitHub
#30503 (comment).

[petrochenkov]

cc @seanmonstar
(You also wanted this)

[seanmonstar]

Yes! 👍

[pnkfelix]

I'm basically in favor of this; I have some vague concerns about specifying it literally as substitution of the right hand side given that we have parameters to consider in the general case, but it seems plausible that kind of substitution works out fine.

[petrochenkov]

@pnkfelix
An implementation is here.
(It may be missing some corner cases, but I'm not aware of them.)

[petrochenkov]

cc @retep998
I guess this can affect -sys crates (maybe winapi?) with lots of typedefs positively.

[retep998]

I pretty much make everything pub anyway so this doesn't really affect winapi either way. The thing that did affect winapi was things like DECLARE_HANDLE! which created a private opaque type, with a public typedef to a raw pointer to that.

[nixpulvis]

I'd be in favor of something like

type Foo = usize;  // This is a type alias which must always be preserved.
alias Bar = usize;  // This is a type alias which always gets substituted when crossing modules.

This allows

alias Return = (usize, isize);

mod a {
    fn foo() -> super::Return;
}

mod b {
    fn foo() -> super::Return;
}

But is documented as returning a (usize, isize) everywhere.

[nikomatsakis]

I think the primary concern with this was rustdoc -- which will show these private aliases -- but we could probably change rustdoc's behavior to expand private aliases.