Tracking issue for `fundamental` feature

[aturon]

This feature flag, part of RFC 1023, is not intended to be stabilized as-is. But this issue tracks discussion about whether some external feature it needed. Perhaps there is a cleaner way to address the balance between negative reasoning and API evolution. See the RFC for details.

todo

• enforce types are generic (Tracking issue for fundamental feature #29635 (comment))

[steveklabnik]

Triage: no changes

[khuey]

See rust-lang/futures-rs#479 for an example of something this would solve.

[steveklabnik]

Triage: not aware of any change.

[eddyb]

So here's a fun bug due to lacking validation:

a.rs:

#![feature(fundamental)]

#[fundamental]
pub struct Foo;

b.rs:

extern crate a;

impl Clone for a::Foo {
    fn clone(&self) -> Self { a::Foo }
}

I think the rule we should enforce is that #[fundamental] types have at least one type parameter, as only types can be local (e.g. constants are only ever "builtin", parameters or projections).

[Diggsey]

I think it would make more sense to say that outside the defining crate, the coherence rules for #[fundamental] types are identical to a tuple of its generic parameters. You can't implement Clone for Foo for the same reason that you can't implement Clone for ().

[Diggsey]

How do people feel about just stabilizing #[fundamental] on types as-is? I'm sure there could be a "more precise" way to exert control over the coherence rules, but honestly I've only needed to do that two or three times, and in each case #[fundamental] was sufficient.

Even if a more precise way is found, it's not the end of the world to have #[fundamental] as well, and it would be easy to remove with an edition change.

Has anyone actually encountered a situation where more control was needed?