Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: settle rules about visibility of impls #3600

Closed
nikomatsakis opened this issue Sep 26, 2012 · 4 comments
Closed

RFC: settle rules about visibility of impls #3600

nikomatsakis opened this issue Sep 26, 2012 · 4 comments
Labels
A-trait-system Area: Trait system
Milestone

Comments

@nikomatsakis
Copy link
Contributor

Right now, I think, an impl of trait T for type X is always visible from within a crate, but to be visible from outside a crate they must be public. I am frankly unsure if these rules are good or bad but I do believe they are to some extent accidental. We should decide when and if impls are visible.

For example, I could imagine any of the following rules:

  • the rule we have now;
  • impls of traits are always visible;
  • impls of traits are subject to the typical visibility rules, meaning that if the impl is public in module A, it can only be used from modules that could import A.

Some related questions:

  • currently coherence is enforced at the crate level. You can implement an impl for trait T and type X if it is T or X is defined in your crate. Module-level visibility has nothing to do with it.
  • if we went with module-level visibility rules, does it interact with coherence at all? I guess it cannot, we still do not want to allow multiple impls of a given trait for a given type.
@brson
Copy link
Contributor

brson commented Oct 8, 2012

For consistency, enforcing normal module visibility rules on impls of traits makes sense, but I can't think of a reason it matters that much. From a library user's point of view, a private trait impl is the same as no trait impl.

The behavior of visibility on the anonymous impl should be considered too. I'm not sure if that's understood yet either or if it's assumed to be the same. Right now 'pub' does nothing on it I think.

My preference is that pub and priv everywhere mean module level visibility and everything is priv by default. Currently fields and methods are pub by default.

@brson
Copy link
Contributor

brson commented Oct 8, 2012

Making a priv trait impl does allow you to enforce some discipline on yourself as a library writer.

With private by default impls you will frequently run into the problem of forgetting to make impls public, but I'm wary of more special cases.

What if we have a consistent priv by default policy everywhere, but offered policy control via attributes?

@Dretch
Copy link
Contributor

Dretch commented Oct 9, 2012

Is there a similar issue with the visibility of traits themselves? Currently they seem to always be visible within a crate, even if marked priv.

This can cause issues. For example:

struct S {field: int}

mod a {
    priv trait A { fn x(); }
    impl S : A { fn x(){} }
}

mod b {
    priv trait B { fn x(); }
    impl S : B { fn x(){} }
}

fn main() {
    let s = S {field: 3};
    s.x();
}

Produces:

test-trait-visibility.rs:17:4: 17:7 error: multiple applicable methods in scope
test-trait-visibility.rs:17     s.x();
                                ^~~
test-trait-visibility.rs:7:17: 7:25 note: candidate #1 is `a::__extensions__::x`
test-trait-visibility.rs:7     impl S : A { fn x(){} }
                                            ^~~~~~~~
test-trait-visibility.rs:12:17: 12:25 note: candidate #2 is `b::__extensions__::x`
test-trait-visibility.rs:12     impl S : B { fn x(){} }
                                             ^~~~~~~~
error: aborting due to previous error

I found this surprising because I expected neither A nor B to be in scope.

OTOH this may in-fact be the same issue.

@catamorphism
Copy link
Contributor

Also see #3985

bors pushed a commit to rust-lang-ci/rust that referenced this issue May 15, 2021
RalfJung pushed a commit to RalfJung/rust that referenced this issue May 19, 2024
Use non-null pointer for size 0 posix memalign

Fixes rust-lang#3576
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-trait-system Area: Trait system
Projects
None yet
Development

No branches or pull requests

5 participants