Feature gate public items in private APIs #16463
Milestone
Comments
|
Nominating for P-Backcompat-lang |
pcwalton
changed the title
|
P-backcompat-lang, 1.0. |
pcwalton
added a commit
to pcwalton/rust
that referenced
this issue
Aug 16, 2014
public, including in trait bounds and typedefs.
There are three main patterns that this breaks. First is code that uses
private trait bounds in public APIs:
pub mod a {
trait Trait { ... }
pub fn f<T:Trait>() { ... }
}
Change that code to export the trait. For example:
pub mod a {
pub trait Trait { ... } // note `pub`
pub fn f<T:Trait>() { ... }
}
Second, this change breaks code that was relying on
`#[allow(visible_private_types)]`. That lint is now a hard error, and
cannot be overridden. For example:
mod helper {
pub struct Foo { ... }
}
pub mod public {
use helper::Foo;
pub fn f() -> Foo;
}
Because there is no way for code that uses `public::f` to name `Foo`,
this is no longer allowed. Change affected code to look like this:
pub mod helper { // note `pub`
pub struct Foo { ... }
}
pub mod public {
use helper::Foo;
pub fn f() -> Foo;
}
Third, this change breaks code that was relying on being able to
reference private typedefs in public APIs. For example:
pub mod b {
type Foo = int;
pub fn f(_: Foo) { ... }
}
Change this code to:
pub mod b {
pub type Foo = int; // note `pub`
pub fn f(_: Foo) { ... }
}
For now, the old behavior can be obtained with
`#[feature(visible_private_types)]`. However, the preciase semantics of
this feature gate may be unstable.
This implements RFC rust-lang#48.
Closes rust-lang#16463.
[breaking-change]
|
Nominating for removal from 1.0 milestone, as there is significant doubt about whether the rules make sense as specified. |
|
cc @nikomatsakis. (An updated RFC with rules that make more sense could be nominated for P-backcompat-lang, of course—I just want to make sure that the list of P-backcompat-lang bugs reflects reality right now.) |
|
consensus is to do nothing until updated RFC is merged. |
pcwalton
added a commit
to pcwalton/rust
that referenced
this issue
Sep 23, 2014
This breaks code like:
struct Foo {
...
}
pub fn make_foo() -> Foo {
...
}
Change this code to:
pub struct Foo { // note `pub`
...
}
pub fn make_foo() -> Foo {
...
}
The `visible_private_types` lint has been removed, since it is now an
error to attempt to expose a private type in a public API. In its place
a `#[feature(visible_private_types)]` gate has been added.
Closes rust-lang#16463.
RFC rust-lang#48.
[breaking-change]
bors
added a commit
that referenced
this issue
Sep 23, 2014
…alexcrichton
This breaks code like:
struct Foo {
...
}
pub fn make_foo() -> Foo {
...
}
Change this code to:
pub struct Foo { // note `pub`
...
}
pub fn make_foo() -> Foo {
...
}
The `visible_private_types` lint has been removed, since it is now an
error to attempt to expose a private type in a public API.
Closes #16463.
RFC #48.
[breaking-change]
r? @alexcrichton
matthiaskrgr
pushed a commit
to matthiaskrgr/rust
that referenced
this issue
Feb 5, 2024
…=lnicola internal: Remove `abi_amdgpu_kernel` references This feature was removed in rust-lang#120495
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Tracking issue for RFC 136 (formerly numbered as RFC 48).
The text was updated successfully, but these errors were encountered: