Skip to content

trait objects of a fundamental trait are treated as fundamental types #56503

Closed
@arielb1

Description

@arielb1
Contributor

I don't think this is intentional, at least it is not documented in the RFCs 1023 or 2451:

STR

Crate a (compile with should_not_have_an_effect):

#![feature(fundamental)]

pub trait Abc {}

#[cfg_attr(should_not_have_an_effect, fundamental)]
pub trait Foo<T> {}

Crate b:

extern crate a;

pub struct Bar;
impl a::Abc for a::Foo<Bar> {}

Expected Result

The cfg_attr does not have an effect - the code gives this error:

error[E0117]: only traits defined in the current crate can be implemented for arbitrary types
 --> b.rs:4:1
  |
4 | impl a::Abc for a::Foo<Bar> {}
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ impl doesn't use types inside crate
  |
  = note: the impl does not reference any types defined in this crate
  = note: define and implement a trait or new type instead

error: aborting due to previous error

Actual result

With --cfg should_not_have_an_effect, the code compiles

Stability consequences

This can't be observed in stable code right now - the only stable #[fundamental] traits are Sized (which doesn't have type parameters) and the Fn traits (which can only be implemented for tuples, and these are never fundamental). However, if we did stabilize a "normal" #[fundamental] trait with type parameters, this would be visible on stable.

Activity

arielb1

arielb1 commented on Dec 4, 2018

@arielb1
ContributorAuthor

This should either be fixed (#[fundamental] trait objects don't act as #[fundamental] types) or documented in the RFCs.

nikomatsakis

nikomatsakis commented on Dec 13, 2018

@nikomatsakis
Contributor

Discussed in the @rust-lang/lang meeting. We decided that for now we should just make #[fundamental] trait objects not act as #[fundamental] types.

added
E-mentorCall for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.
on Dec 14, 2018
arielb1

arielb1 commented on Dec 14, 2018

@arielb1
ContributorAuthor

No warning period needed because this is a nightly feature? I think I'll E-mentor this or not, this looks too simple.

removed
E-mentorCall for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.
on Dec 14, 2018
added a commit that references this issue on Dec 15, 2018
c4fa1d2
added a commit that references this issue on Dec 20, 2018

Rollup merge of rust-lang#56862 - arielb1:fundamentally-clean, r=niko…

234c340
added a commit that references this issue on Dec 21, 2018

Rollup merge of rust-lang#56862 - arielb1:fundamentally-clean, r=niko…

b882acb
added a commit that references this issue on Dec 22, 2018

Rollup merge of rust-lang#56862 - arielb1:fundamentally-clean, r=niko…

06b0f46
added a commit that references this issue on Dec 22, 2018

Auto merge of #56862 - arielb1:fundamentally-clean, r=nikomatsakis

9966590

1 remaining item

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-trait-systemArea: Trait systemT-langRelevant to the language team

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @nikomatsakis@Centril@arielb1

        Issue actions

          trait objects of a fundamental trait are treated as fundamental types · Issue #56503 · rust-lang/rust