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

associated_type_defaults not working correctly #35986

Closed
mtanski opened this issue Aug 25, 2016 · 5 comments
Closed

associated_type_defaults not working correctly #35986

mtanski opened this issue Aug 25, 2016 · 5 comments
Labels
A-associated-items Area: Associated items (types, constants & functions) C-bug Category: This is a bug. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@mtanski
Copy link

mtanski commented Aug 25, 2016

It seams like associated_type_defaults are not working. I have an example below from a query processing engine where I'm trying to use traits and associated types to express the application level Types of the (sql like) schema.

#![feature(associated_consts)]
#![feature(associated_type_defaults)]

use std::mem;
use std::convert::Into;

// types.rs file

// Represents Type stored on disk
pub enum Type {
    UINT32,
    // ... Lots of types
}

pub trait TypeInfo {
    // type DiskType;
    type DiskType = u8;

    const ID: Type;
    const SIZE_OF: usize;
    // ... Lots of additional consts
}

pub struct UInt32;

impl TypeInfo for UInt32 {
    type DiskType = u32;
    const ID: Type = Type::UINT32;
    // Also broken, std::mem::size_of cannot be used in const expr
    const SIZE_OF: usize =  std::mem::size_of::<UInt32::DiskType>();
}

// ... Lots of types

static uint32: UInt32 = UInt32 {};

impl Into<&'static TypeInfo> for Type {
    fn into(self) -> &'static TypeInfo {
        match self {
            UINT32 => &uint32,
        }
    }
}

// consuming file

fn main() {
    let attr = Type::UINT32;
    let info = attr.info();
}

playpen link: https://play.rust-lang.org/?gist=2d2295013a3b9bb859b3e04bc1b9dc18&version=nightly&backtrace=0

leads to the result of:

error[E0191]: the value of the associated type `DiskType` (from the trait `TypeInfo`) must be specified
  --> <anon>:34:20
   |
34 | impl Into<&'static TypeInfo> for Type {
   |                    ^^^^^^^^ missing associated type `DiskType` value

error[E0191]: the value of the associated type `DiskType` (from the trait `TypeInfo`) must be specified
  --> <anon>:35:31
   |
35 |     fn into(self) -> &'static TypeInfo {
   |                               ^^^^^^^^ missing associated type `DiskType` value

error: aborting due to 2 previous errors

Which is the same error you get when there is no DiskType default. I would like that case to work too, but it's somewhat out of scope of what I'm asking for here.

@apasel422 apasel422 added the A-associated-items Area: Associated items (types, constants & functions) label Aug 25, 2016
@Mark-Simulacrum Mark-Simulacrum added the C-bug Category: This is a bug. label Jul 26, 2017
@nrc nrc added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. I-nominated labels Nov 13, 2017
@nrc
Copy link
Member

nrc commented Nov 13, 2017

I'm also seeing this issue. To be precise, it seems that the default associated type is not used to type check the body of an impl.

My example:

trait Foo {
    type B: A = C;
    fn foo(&self) -> Option<Self::B>;
}

struct Bar;

impl Foo for Bar {
    fn foo(&self) -> Option<Self::B> {
        B { ... } // ~ERROR: expected associated type, found struct `B`
    }
}

@nrc
Copy link
Member

nrc commented Nov 13, 2017

Adding type B = C; to the impl fixes the error, but IMO should make no difference.

@nikomatsakis
Copy link
Contributor

So the original issue was a kind of feature request, related to trait objects and the requirements on them. I've added it to the tracking issue for associated type defaults (#29661) because I agree it's a useful data point.

@nrc, the thing you mentioned seems like a separate issue -- arguably a bug, although this interacts with specialization. Basically the reason that the type B = C is not resolving is because it is interacting with the specialization rules around 'revealing' types.

In short, defaults aren't really intended for use right now, and don't have agreed upon semantics. =)

@nikomatsakis
Copy link
Contributor

(To be clear, though, I think that the @nrc example should probably work, even in the current "in between" state.)

@nikomatsakis nikomatsakis added T-lang Relevant to the language team, which will review and decide on the PR/issue. and removed I-nominated labels Nov 16, 2017
@arielb1 arielb1 removed the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Nov 16, 2017
@Centril
Copy link
Contributor

Centril commented Feb 25, 2019

This was resolved by rust-lang/rfcs#2532 specifying that defaults should be accounted for when using dyn Trait.

@Centril Centril closed this as completed Feb 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-associated-items Area: Associated items (types, constants & functions) C-bug Category: This is a bug. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

7 participants