"Private trait in exported type parameter bound"

[tbu-]

trait Trait { }
impl Trait for () { }
impl Trait for ((),) { }

pub fn function<K:Trait>() {
}

pub struct Struct<K:Trait>;

fn main() { }

Errors:

a.rs:5:19: 5:24 error: private trait in exported type parameter bound
a.rs:5 pub fn function<K:Trait>() {
                         ^~~~~
a.rs:8:21: 8:26 error: private trait in exported type parameter bound
a.rs:8 pub struct Struct<K:Trait>;
                           ^~~~~

This stops me from providing a trait that is an implementation detail and as such should not be exported (it could change anytime, no backwards-compatiblity at all).

[steveklabnik]

updated code:

trait Trait { }
impl Trait for () { }
impl Trait for ((),) { }

pub fn function<K:Trait>() {
}

pub struct Struct<K:Trait> {
    phantom: std::marker::PhantomData<K>,
}

fn main() { }

The error is now

hello.rs:5:19: 5:24 error: private trait in public interface [E0445]
hello.rs:5 pub fn function<K:Trait>() {
                             ^~~~~

I believe that this is intended behavior. @rust-lang/lang?

[nikomatsakis]

Hmm. Actually, I sort of expected the same errors as before. I'm a bit surprised that the error on the struct went away. cc @petrochenkov

[nikomatsakis]

Oh, but when I try it on play, I see the same errors as before.

[petrochenkov]

Guess: Steve just trimmed the output to demonstrate the new error message.

[petrochenkov]

Also, this is intended (at least currently).

The official workaround is

mod private_module {
    pub trait Trait { }
    impl Trait for () { }
    impl Trait for ((),) { }
}


pub fn function<K:private_module::Trait>() {
}

pub struct Struct<K:private_module::Trait> {
    phantom: std::marker::PhantomData<K>,
}

fn main() { }

it is mentioned in the expanded error message for E0445.

[nikomatsakis]

Right, so I think we can close this as "working as designed", for better or worse. :) @tbu-, you may be interested in RFC rust-lang/rfcs#1422, which aims to address this issue. There has also been some discussion about the current rules and the reasoning behind them, but I can't find the links right now... let me know if you want me to dig them up.

[tbu-]

Thanks for the link to the RFC!

[pnkfelix]

I don't think RFC PR 1422 actually addresses this use case. The question as I see it here is whether traits that appear in bounds/where-clauses should be required to have at least the same visibility as the item itself. That RFC PR doesn't attempt to change those rules.

(Update: I did write a blog post related to this topic: http://blog.pnkfx.org/blog/2015/12/19/signatures-and-surfaces-thoughts-on-privacy-versus-dependency/ I should probably write a follow up)

[nikomatsakis]

@pnkfelix

I don't think RFC PR 1422 actually addresses this use case. The question as I see it here is whether traits that appear in bounds/where-clauses should be required to have at least the same visibility as the item itself. That RFC PR doesn't attempt to change those rules.

It depends on the specific situation I suppose. I was assuming (perhaps incorrectly) that the intention was for the function not to be fully public, but public within some subtree.