Trait bounds are not yet enforced in type definitions

View all comments

Opening an issue since I could not find any information on when/if this will be enforced. Would be really useful for some generalizing I am trying for parser-combinators which I can't do currently without complicating the API.

Specifically I'd like to use a trait bound in a type definition to access an associated type to avoid passing it seperately but due to this issue I simply get a compiler error.

Simplified code which exhibits the error:

trait Stream {
    type Item;
}

trait Parser {
    type Input: Stream;
}

fn test<T>(u: T) -> T
    where T: Parser {
    panic!()
}

type Res<I: Stream> = (I, <I as Stream>::Item);

impl <'a> Stream for &'a str { type Item = char; }
impl <I> Parser for fn (I) -> Res<I> where I: Stream { type Input = I; }

//Works
//fn f(_: &str) -> (&str, char) {

//Errors
fn f(_: &str) -> Res<&str> {
    panic!()
}

fn main() {
    let _ = test(f as fn (_) -> _);
}

@nikomatsakis

At first glance this is probably related to the internal messy-ness of bounds vs. where-clauses. I'm not sure if the predicate constraints for type aliases are propagated correctly. You should be able to use a newtype as a work around:

struct Res<I: Stream>((I, <I as Stream>::Item))

Seems to work just fine on playground with the newtype: http://is.gd/krOTZv.

cc @nikomatsakis

I would use a newtype but since the type I want to define is a specialized Result type that isn't possible in my case. I didn't really mention that since it is tangential to the bug itself.

Looks like warnings are now generated for this case, but not consistently[0].

Should this be a compile-time error instead?

[0] #20222 (comment)

What is the status on trait bounds in type definitions? I worked around it the best I could for combine but it won't be as clean as it could be until bounds are allowed.

Where bounds are allowed, they're not checked properly.

I'm using this one and it compiles from Rust 1.0 or later

pub type MapFn<I, B> where I: Iterator = iter::Map<I, fn(I::Item) -> B>;

Nominating for discussion. Seems like backcompat hazard we should consider trying to address with a feature gate.

Since the bounds provide writing types you couldn't do otherwise, they are very useful. A feature gate would be a breaking change without recourse(?).

triage: P-medium

I think this might be not that hard to fix though!

Unless I'm missing something, this isn't a huge problem because bad things will still fail to type check right? For example the following doesn't compile.

trait Foo {
    fn foo(&self) -> u32 {
        1
    }
}

type Bar<F: Foo> = F;

fn foo(f: Bar<&str>) -> Bar<&str> {
    f
}

fn main() {
    let bar: Bar<&str> = "";
    println!("{:?}", foo(bar.foo()));
}

@nixpulvis

@nixpulvis I think the argument for checking type definitions is analogous to our philosophy about other polymorphic code: we don't do C++ style post template-instantiation type-checking; instead we check the polymorphic code at the definition site (even though both strategies are sound)

Or maybe you are just saying the backwards incompatibility hit won't be that bad? (To which I say: famous last words. .. ;)

@pnkfelix

@pnkfelix I was really just posting to confirm that I wasn't missing something. The warning sounds a bit scarier than it is in reality. I think this is tangental to #30503, as I do feel having type aliases which aren't check could be useful.

this would be such a juicy feature, is there any chance this will ever be implemented?

I just encounter a case where depending on conditional compilation, my type alias could change but I wanted to make sure that whatever concrete type was chosen, at the end it will implement a trait. I posted about it here

I wanted to do something like this:

#[cfg(target_arch = "x86_64")]
type MyAlias: MyTrait = A;
#[cfg(target_arch = "riscv64")]
type MyAlias: MyTrait = B;

rustdoc: list matching impls on type aliases

To give an update to the people subscribed to this issue, the (incomplete) feature lazy_type_alias implements the expected semantics for type aliases:

where-clauses and bounds on type parameters of type aliases are enforced
type aliases are checked for well-formedness
where-clauses are trailing instead of leading just like with associated types (see also Proposal: Change syntax of where clauses on type aliases #89122)

The feature is nominated for stabilization in a future edition (202X). Its tracking issue #112792 basically supersedes this issue in my humble opinion. See also https://github.com/rust-lang/rust/labels/F-lazy_type_alias.

Rollup merge of rust-lang#115201 - notriddle:notriddle/type-alias-imp…

Unrolled build for rust-lang#115201

Merge pull request rust-lang#21903 from A4-Tacks/postfix-include-nots

Navigation Menu

Repository navigation

Trait bounds are not yet enforced in type definitions #21903

30 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Trait bounds are not yet enforced in type definitions #21903

Description

Activity

jroesch commented on Feb 3, 2015

Marwes commented on Feb 3, 2015

tamird commented on Apr 22, 2015

Marwes commented on Aug 9, 2015

bluss commented on Nov 26, 2015

nikomatsakis commented on Dec 15, 2015

bluss commented on Dec 15, 2015

nikomatsakis commented on Dec 17, 2015

nixpulvis commented on Feb 9, 2016

pnkfelix commented on Feb 9, 2016

nixpulvis commented on Feb 9, 2016

30 remaining items

cedricschwyter commented on May 19, 2022

Skallwar commented on Jun 10, 2022

fmease commented on Aug 25, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions