[Draft] RFC: Hidden implementations

[Centril]

This is a draft version of an RFC for you to review, before a formal proposal is made for consideration.
The RFC introduces a concept I am calling "hidden implementations".

Note that this idea is radically different than modularization of implementations as permitted in Idris, Scala and such languages in that it preserves coherence keeps the language free of orphan implementations.

I have left a bunch of unresolved questions which I'd like special attention given to. If you, the reader, have some rationale, motivation, drawbacks that you feel are missed, please do include them in your review. I would also love it if you find better ways to explain concepts than in this draft.

[Mark-Simulacrum]

This sentence seems to have gotten mangled.

[Mark-Simulacrum]

I'm confused how this would be allowed anyway as (AIUI) neither Property nor Thing are defined in crate B, so this impl would be invalid, overlap or no overlap.

[Mark-Simulacrum]

Couldn't people who need this do pub(in self)? Seems like that would be less surprising than "priv"

[kennytm]

Or priv could be just made an alias of pub(self) (similar to crate being an alisa of pub(crate)).

[Centril]

Apparently I was oblivious to the fact that pub(self) is already stable - so I'll make this section "possible future work".

[Mark-Simulacrum]

So essentially, return Box::new(Thing): Box<dyn Property> is permitted with no compiler warnings? I'm confused why the compiler cannot lint against this -- it knows that it is creating a vtable for the impl of Property for Thing; as such that place can lint against this (though in many cases only after/during monomorphization).

However, I'm not opposed to this (just feels like the wording could be changed).

[Mark-Simulacrum]

Hm, so we hard-lint currently on pub in the the below impl; in a way, I could see this being a way to define the "extensible traits" talked about on Discord -- we could say that you could make certain methods of a trait not world-visible. I guess you can also do that with two (or more) traits, but this seems like a reasonable extension of this RFC.

trait Foo {
    pub fn bar() {}
}

[Centril]

Sure; you could have something like:

// crate A

pub trait Foo {
    crate fn bar();
    pub fn baz();
}

and since only crate A can provide a definition for bar, then only crate A can provide implementations for Foo.

I'll leave this out for now tho :)

[Mark-Simulacrum]

I'd like to say that the priv vs pub(self) etc debate is also something to solve after merging the RFC.

[Centril]

Absolutely; Now that I know pub(self) is stable, we should punt on priv.

[kennytm]

Not negative bounds, but you do need to consider effect of negative impls of auto-traits:

priv impl !Send for MyUnsafeType {}

I suggest that the visibility of a negative impl must be ≥ that of the trait, otherwise it would be an error.

[Centril]

Hmm... this one is tricky... The impl above should be well-behaved (and not unsound)? and be interpreted as un-implementing Send for MyUnsafeType inside the module, but not elsewhere. Thus, the fact that MyUnsafeType: Send may be observed outside but not inside the module.

However; I can't see any use cases for this, and it will likely just lead to bad places; so your proposed rule sounds good, at least for now.

[kennytm]

One of the biggest unresolved question is that, given rust-lang/rust#39935 is still not fixed (which forced every impl in libstd to be insta-stable), how would I know this RFC would be implementable 🤔

[Centril]

Addressed all review comments thus far and made other improvements. :)

[aturon]

I had time to read up through the start of the reference section; will read the rest later. Overall, this seems very solid and thoroughly thought out, and I think would fit nicely with some other proposals in the air (like being able to write inherent impls for nonlocal types as long as those impls are marked with sufficient privacy).

[aturon]

I had time to read up through the start of the reference section; will read the rest later. Overall, this seems very solid and thoroughly thought out, and I think would fit nicely with some other proposals in the air (like being able to write inherent impls for nonlocal types as long as those impls are marked with sufficient privacy).

[aturon]

Solid, well-explained motivation!

[aturon]

Note that there's a non-trivial interaction with macros here; currently, "privacy hygiene" is not a thing.

[Centril]

Could you elaborate a bit here? The way I'm thinking is that if we have a macro with say:

macro_rules! mac {
    () => {
        fn return_property() -> impl Property {
            make_a_thing() // ← error[E0277]
        }
    }
}

which is then called at some site, then the visibility context used is that of the call site of mac!().
The same should be the case with a macro defining an implementation; it too is visible according to the call-site and not the definition site of the macro.

[aturon]

Excellent.

[aturon]

👍

[aturon]

This is, to my mind, the biggest drawback of the proposal. I don't see a good way around it, though.

[Centril]

Yup, I agree on this being a drawback :) I added a paragraph discussing it in the section on Drawbacks.

[aturon]

👍

[aturon]

👍

[aturon]

👍

[aturon]

👍

[Mark-Simulacrum]

One thing to potentially add/explore perhaps is to take a look at the compiler's TyCtxt and similar types that are used throughout, but can't currently be implemented directly on outside of librustc; it feels loosely like that's another significant motivation -- currently there's lots of functions that should/could be inherent on tcx but can't be.

[Centril]

Time to publish.
Thanks all for participating in this review! :)