What's going on with this bizarre recursive type error in Rust?
up vote
5
down vote
favorite
I have an iterable struct called Join
:
use std::iter::Peekable;
#[derive(Debug)]
pub struct Join<T, S> {
container: T,
separator: S,
}
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum JoinItem<T, S> {
Element(T),
Separator(S),
}
pub struct JoinIter<Iter: Iterator, Sep> {
iter: Peekable<Iter>,
sep: Sep,
next_sep: bool,
}
impl<Iter: Iterator, Sep> JoinIter<Iter, Sep> {
fn new(iter: Iter, sep: Sep) -> Self {
JoinIter {
iter: iter.peekable(),
sep,
next_sep: false,
}
}
}
impl<I: Iterator, S: Clone> Iterator for JoinIter<I, S> {
type Item = JoinItem<I::Item, S>;
/// Advance to the next item in the Join. This will either be the next
/// element in the underlying iterator, or a clone of the separator.
fn next(&mut self) -> Option<Self::Item> {
let sep = &self.sep;
let next_sep = &mut self.next_sep;
if *next_sep {
self.iter.peek().map(|_| {
*next_sep = false;
JoinItem::Separator(sep.clone())
})
} else {
self.iter.next().map(|element| {
*next_sep = true;
JoinItem::Element(element)
})
}
}
}
A reference to Join
implements IntoIterator
:
impl<'a, T, S> IntoIterator for &'a Join<T, S>
where
&'a T: IntoIterator,
{
type IntoIter = JoinIter<<&'a T as IntoIterator>::IntoIter, &'a S>;
type Item = JoinItem<<&'a T as IntoIterator>::Item, &'a S>;
fn into_iter(self) -> Self::IntoIter {
JoinIter::new(self.container.into_iter(), &self.separator)
}
}
This compiles and passes usage tests.
I also have an iter
method defined on my Join
struct:
impl<T, S> Join<T, S>
where
for<'a> &'a T: IntoIterator,
{
pub fn iter(&self) -> JoinIter<<&T as IntoIterator>::IntoIter, &S> {
self.into_iter()
}
}
This compiles fine, but when I actually try to use it:
fn main() {
// Create a join struct
let join = Join {
container: vec![1, 2, 3],
separator: ", ",
};
// This works fine
let mut good_ref_iter = (&join).into_iter();
assert_eq!(good_ref_iter.next(), Some(JoinItem::Element(&1)));
assert_eq!(good_ref_iter.next(), Some(JoinItem::Separator(&", ")));
assert_eq!(good_ref_iter.next(), Some(JoinItem::Element(&2)));
assert_eq!(good_ref_iter.next(), Some(JoinItem::Separator(&", ")));
assert_eq!(good_ref_iter.next(), Some(JoinItem::Element(&3)));
assert_eq!(good_ref_iter.next(), None);
// This line fails to compile; comment out this section and it all works
let bad_ref_iter = join.iter();
assert_eq!(bad_ref_iter.next(), Some(JoinItem::Element(&1)));
assert_eq!(bad_ref_iter.next(), Some(JoinItem::Separator(&", ")));
assert_eq!(bad_ref_iter.next(), Some(JoinItem::Element(&2)));
assert_eq!(bad_ref_iter.next(), Some(JoinItem::Separator(&", ")));
assert_eq!(bad_ref_iter.next(), Some(JoinItem::Element(&3)));
assert_eq!(bad_ref_iter.next(), None);
}
I get some kind of weird type recursion error:
error[E0275]: overflow evaluating the requirement `&_: std::marker::Sized`
--> src/join.rs:288:29
|
96 | let mut iter = join.iter();
| ^^^^
|
= help: consider adding a `#![recursion_limit="128"]` attribute to your crate
= note: required because of the requirements on the impl of `std::iter::IntoIterator` for `&_`
= note: required because of the requirements on the impl of `std::iter::IntoIterator` for `&join::Join<_, _>`
= note: required because of the requirements on the impl of `std::iter::IntoIterator` for `&join::Join<join::Join<_, _>, _>`
= note: required because of the requirements on the impl of `std::iter::IntoIterator` for `&join::Join<join::Join<join::Join<_, _>, _>, _>`
= note: required because of the requirements on the impl of `std::iter::IntoIterator` for `&join::Join<join::Join<join::Join<join::Join<_, _>, _>, _>, _>`
= note: required because of the requirements on the impl of `std::iter::IntoIterator` for `&join::Join<join::Join<join::Join<join::Join<join::Join<_, _>, _>, _>, _>, _>`
= note: required because of the requirements on the impl of `std::iter::IntoIterator` for `&join::Join<join::Join<join::Join<join::Join<join::Join<join::Join<_, _>, _>, _>, _>, _>, _>`
...
(I redacted about 100 more lines of recursive type error in the ...)
As best I can tell, it appears to be attempting to proactively evaluate whether &Join<_, _>
implements IntoIterator
, which requires checking if &Join<Join<_, _>, _>
fulfills IntoIterator, and so on forever. What I can't figure out is why it thinks it has to do this, since my actual type is fully qualified as Join<Vec<{integer}, &'static str>
. Some things I've tried:
Moving the trait bound off of the impl header and into the
iter
function, like so:
fn iter(&'a self) -> JoinIter<<&'a T as IntoIterator>::IntoIter, &'a S>
where &'a T: IntoIterator
This has the same result.
Replacing
self.into_iter()
with the underlying expression,JoinIter::new(self.container.into_iter(), self.separator)
, in the hopes that maybe it's struggling to differentiateself.into_iter()
from(&self).into_iter()
. I've tried all of the following patterns:
fn iter(&self) -> ... { self.into_iter() }
fn iter(&self) -> ... { (&self).into_iter() }
fn iter(&self) -> ... { JoinIter::new(self.container.into_iter(), &self.separator) }
fn iter(&self) -> ... { JoinIter::new((&self.container).into_iter(), &self.separator) }
- Speaking of which, replacing the call to
self.iter()
with(&self).into_iter()
fixes the problem, but replacing it with(&self).iter()
does not.
Why does (&join).into_iter()
work, but join.iter()
does not, even though iter()
simply calls self.into_iter()
under the hood?
This complete example, with identical code, is also available in the Rust Playground
For more context about Join
, see my older Stack Overflow question and my actual source code.
types reference rust type-inference
add a comment |
up vote
5
down vote
favorite
I have an iterable struct called Join
:
use std::iter::Peekable;
#[derive(Debug)]
pub struct Join<T, S> {
container: T,
separator: S,
}
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum JoinItem<T, S> {
Element(T),
Separator(S),
}
pub struct JoinIter<Iter: Iterator, Sep> {
iter: Peekable<Iter>,
sep: Sep,
next_sep: bool,
}
impl<Iter: Iterator, Sep> JoinIter<Iter, Sep> {
fn new(iter: Iter, sep: Sep) -> Self {
JoinIter {
iter: iter.peekable(),
sep,
next_sep: false,
}
}
}
impl<I: Iterator, S: Clone> Iterator for JoinIter<I, S> {
type Item = JoinItem<I::Item, S>;
/// Advance to the next item in the Join. This will either be the next
/// element in the underlying iterator, or a clone of the separator.
fn next(&mut self) -> Option<Self::Item> {
let sep = &self.sep;
let next_sep = &mut self.next_sep;
if *next_sep {
self.iter.peek().map(|_| {
*next_sep = false;
JoinItem::Separator(sep.clone())
})
} else {
self.iter.next().map(|element| {
*next_sep = true;
JoinItem::Element(element)
})
}
}
}
A reference to Join
implements IntoIterator
:
impl<'a, T, S> IntoIterator for &'a Join<T, S>
where
&'a T: IntoIterator,
{
type IntoIter = JoinIter<<&'a T as IntoIterator>::IntoIter, &'a S>;
type Item = JoinItem<<&'a T as IntoIterator>::Item, &'a S>;
fn into_iter(self) -> Self::IntoIter {
JoinIter::new(self.container.into_iter(), &self.separator)
}
}
This compiles and passes usage tests.
I also have an iter
method defined on my Join
struct:
impl<T, S> Join<T, S>
where
for<'a> &'a T: IntoIterator,
{
pub fn iter(&self) -> JoinIter<<&T as IntoIterator>::IntoIter, &S> {
self.into_iter()
}
}
This compiles fine, but when I actually try to use it:
fn main() {
// Create a join struct
let join = Join {
container: vec![1, 2, 3],
separator: ", ",
};
// This works fine
let mut good_ref_iter = (&join).into_iter();
assert_eq!(good_ref_iter.next(), Some(JoinItem::Element(&1)));
assert_eq!(good_ref_iter.next(), Some(JoinItem::Separator(&", ")));
assert_eq!(good_ref_iter.next(), Some(JoinItem::Element(&2)));
assert_eq!(good_ref_iter.next(), Some(JoinItem::Separator(&", ")));
assert_eq!(good_ref_iter.next(), Some(JoinItem::Element(&3)));
assert_eq!(good_ref_iter.next(), None);
// This line fails to compile; comment out this section and it all works
let bad_ref_iter = join.iter();
assert_eq!(bad_ref_iter.next(), Some(JoinItem::Element(&1)));
assert_eq!(bad_ref_iter.next(), Some(JoinItem::Separator(&", ")));
assert_eq!(bad_ref_iter.next(), Some(JoinItem::Element(&2)));
assert_eq!(bad_ref_iter.next(), Some(JoinItem::Separator(&", ")));
assert_eq!(bad_ref_iter.next(), Some(JoinItem::Element(&3)));
assert_eq!(bad_ref_iter.next(), None);
}
I get some kind of weird type recursion error:
error[E0275]: overflow evaluating the requirement `&_: std::marker::Sized`
--> src/join.rs:288:29
|
96 | let mut iter = join.iter();
| ^^^^
|
= help: consider adding a `#![recursion_limit="128"]` attribute to your crate
= note: required because of the requirements on the impl of `std::iter::IntoIterator` for `&_`
= note: required because of the requirements on the impl of `std::iter::IntoIterator` for `&join::Join<_, _>`
= note: required because of the requirements on the impl of `std::iter::IntoIterator` for `&join::Join<join::Join<_, _>, _>`
= note: required because of the requirements on the impl of `std::iter::IntoIterator` for `&join::Join<join::Join<join::Join<_, _>, _>, _>`
= note: required because of the requirements on the impl of `std::iter::IntoIterator` for `&join::Join<join::Join<join::Join<join::Join<_, _>, _>, _>, _>`
= note: required because of the requirements on the impl of `std::iter::IntoIterator` for `&join::Join<join::Join<join::Join<join::Join<join::Join<_, _>, _>, _>, _>, _>`
= note: required because of the requirements on the impl of `std::iter::IntoIterator` for `&join::Join<join::Join<join::Join<join::Join<join::Join<join::Join<_, _>, _>, _>, _>, _>, _>`
...
(I redacted about 100 more lines of recursive type error in the ...)
As best I can tell, it appears to be attempting to proactively evaluate whether &Join<_, _>
implements IntoIterator
, which requires checking if &Join<Join<_, _>, _>
fulfills IntoIterator, and so on forever. What I can't figure out is why it thinks it has to do this, since my actual type is fully qualified as Join<Vec<{integer}, &'static str>
. Some things I've tried:
Moving the trait bound off of the impl header and into the
iter
function, like so:
fn iter(&'a self) -> JoinIter<<&'a T as IntoIterator>::IntoIter, &'a S>
where &'a T: IntoIterator
This has the same result.
Replacing
self.into_iter()
with the underlying expression,JoinIter::new(self.container.into_iter(), self.separator)
, in the hopes that maybe it's struggling to differentiateself.into_iter()
from(&self).into_iter()
. I've tried all of the following patterns:
fn iter(&self) -> ... { self.into_iter() }
fn iter(&self) -> ... { (&self).into_iter() }
fn iter(&self) -> ... { JoinIter::new(self.container.into_iter(), &self.separator) }
fn iter(&self) -> ... { JoinIter::new((&self.container).into_iter(), &self.separator) }
- Speaking of which, replacing the call to
self.iter()
with(&self).into_iter()
fixes the problem, but replacing it with(&self).iter()
does not.
Why does (&join).into_iter()
work, but join.iter()
does not, even though iter()
simply calls self.into_iter()
under the hood?
This complete example, with identical code, is also available in the Rust Playground
For more context about Join
, see my older Stack Overflow question and my actual source code.
types reference rust type-inference
1
@Lucretiel I've reduced the playground example to a fraction of its size. Note that removing the emptyimpl
block makes the error go away. This gives some clues why it is occurring, but I don't really have an explanation yet. Also note that the line triggering the error now islet _ = join;
.
– Sven Marnach
Nov 21 at 21:10
@SvenMarnach that microexample has the same error as my code, but doesn't reproduce my specific issue. In my code,IntoIterator
DOES work fine; it's thefn iter()
(which literally just callsinto_iter()
) that inexplicably breaks
– Lucretiel
Nov 21 at 23:23
add a comment |
up vote
5
down vote
favorite
up vote
5
down vote
favorite
I have an iterable struct called Join
:
use std::iter::Peekable;
#[derive(Debug)]
pub struct Join<T, S> {
container: T,
separator: S,
}
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum JoinItem<T, S> {
Element(T),
Separator(S),
}
pub struct JoinIter<Iter: Iterator, Sep> {
iter: Peekable<Iter>,
sep: Sep,
next_sep: bool,
}
impl<Iter: Iterator, Sep> JoinIter<Iter, Sep> {
fn new(iter: Iter, sep: Sep) -> Self {
JoinIter {
iter: iter.peekable(),
sep,
next_sep: false,
}
}
}
impl<I: Iterator, S: Clone> Iterator for JoinIter<I, S> {
type Item = JoinItem<I::Item, S>;
/// Advance to the next item in the Join. This will either be the next
/// element in the underlying iterator, or a clone of the separator.
fn next(&mut self) -> Option<Self::Item> {
let sep = &self.sep;
let next_sep = &mut self.next_sep;
if *next_sep {
self.iter.peek().map(|_| {
*next_sep = false;
JoinItem::Separator(sep.clone())
})
} else {
self.iter.next().map(|element| {
*next_sep = true;
JoinItem::Element(element)
})
}
}
}
A reference to Join
implements IntoIterator
:
impl<'a, T, S> IntoIterator for &'a Join<T, S>
where
&'a T: IntoIterator,
{
type IntoIter = JoinIter<<&'a T as IntoIterator>::IntoIter, &'a S>;
type Item = JoinItem<<&'a T as IntoIterator>::Item, &'a S>;
fn into_iter(self) -> Self::IntoIter {
JoinIter::new(self.container.into_iter(), &self.separator)
}
}
This compiles and passes usage tests.
I also have an iter
method defined on my Join
struct:
impl<T, S> Join<T, S>
where
for<'a> &'a T: IntoIterator,
{
pub fn iter(&self) -> JoinIter<<&T as IntoIterator>::IntoIter, &S> {
self.into_iter()
}
}
This compiles fine, but when I actually try to use it:
fn main() {
// Create a join struct
let join = Join {
container: vec![1, 2, 3],
separator: ", ",
};
// This works fine
let mut good_ref_iter = (&join).into_iter();
assert_eq!(good_ref_iter.next(), Some(JoinItem::Element(&1)));
assert_eq!(good_ref_iter.next(), Some(JoinItem::Separator(&", ")));
assert_eq!(good_ref_iter.next(), Some(JoinItem::Element(&2)));
assert_eq!(good_ref_iter.next(), Some(JoinItem::Separator(&", ")));
assert_eq!(good_ref_iter.next(), Some(JoinItem::Element(&3)));
assert_eq!(good_ref_iter.next(), None);
// This line fails to compile; comment out this section and it all works
let bad_ref_iter = join.iter();
assert_eq!(bad_ref_iter.next(), Some(JoinItem::Element(&1)));
assert_eq!(bad_ref_iter.next(), Some(JoinItem::Separator(&", ")));
assert_eq!(bad_ref_iter.next(), Some(JoinItem::Element(&2)));
assert_eq!(bad_ref_iter.next(), Some(JoinItem::Separator(&", ")));
assert_eq!(bad_ref_iter.next(), Some(JoinItem::Element(&3)));
assert_eq!(bad_ref_iter.next(), None);
}
I get some kind of weird type recursion error:
error[E0275]: overflow evaluating the requirement `&_: std::marker::Sized`
--> src/join.rs:288:29
|
96 | let mut iter = join.iter();
| ^^^^
|
= help: consider adding a `#![recursion_limit="128"]` attribute to your crate
= note: required because of the requirements on the impl of `std::iter::IntoIterator` for `&_`
= note: required because of the requirements on the impl of `std::iter::IntoIterator` for `&join::Join<_, _>`
= note: required because of the requirements on the impl of `std::iter::IntoIterator` for `&join::Join<join::Join<_, _>, _>`
= note: required because of the requirements on the impl of `std::iter::IntoIterator` for `&join::Join<join::Join<join::Join<_, _>, _>, _>`
= note: required because of the requirements on the impl of `std::iter::IntoIterator` for `&join::Join<join::Join<join::Join<join::Join<_, _>, _>, _>, _>`
= note: required because of the requirements on the impl of `std::iter::IntoIterator` for `&join::Join<join::Join<join::Join<join::Join<join::Join<_, _>, _>, _>, _>, _>`
= note: required because of the requirements on the impl of `std::iter::IntoIterator` for `&join::Join<join::Join<join::Join<join::Join<join::Join<join::Join<_, _>, _>, _>, _>, _>, _>`
...
(I redacted about 100 more lines of recursive type error in the ...)
As best I can tell, it appears to be attempting to proactively evaluate whether &Join<_, _>
implements IntoIterator
, which requires checking if &Join<Join<_, _>, _>
fulfills IntoIterator, and so on forever. What I can't figure out is why it thinks it has to do this, since my actual type is fully qualified as Join<Vec<{integer}, &'static str>
. Some things I've tried:
Moving the trait bound off of the impl header and into the
iter
function, like so:
fn iter(&'a self) -> JoinIter<<&'a T as IntoIterator>::IntoIter, &'a S>
where &'a T: IntoIterator
This has the same result.
Replacing
self.into_iter()
with the underlying expression,JoinIter::new(self.container.into_iter(), self.separator)
, in the hopes that maybe it's struggling to differentiateself.into_iter()
from(&self).into_iter()
. I've tried all of the following patterns:
fn iter(&self) -> ... { self.into_iter() }
fn iter(&self) -> ... { (&self).into_iter() }
fn iter(&self) -> ... { JoinIter::new(self.container.into_iter(), &self.separator) }
fn iter(&self) -> ... { JoinIter::new((&self.container).into_iter(), &self.separator) }
- Speaking of which, replacing the call to
self.iter()
with(&self).into_iter()
fixes the problem, but replacing it with(&self).iter()
does not.
Why does (&join).into_iter()
work, but join.iter()
does not, even though iter()
simply calls self.into_iter()
under the hood?
This complete example, with identical code, is also available in the Rust Playground
For more context about Join
, see my older Stack Overflow question and my actual source code.
types reference rust type-inference
I have an iterable struct called Join
:
use std::iter::Peekable;
#[derive(Debug)]
pub struct Join<T, S> {
container: T,
separator: S,
}
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum JoinItem<T, S> {
Element(T),
Separator(S),
}
pub struct JoinIter<Iter: Iterator, Sep> {
iter: Peekable<Iter>,
sep: Sep,
next_sep: bool,
}
impl<Iter: Iterator, Sep> JoinIter<Iter, Sep> {
fn new(iter: Iter, sep: Sep) -> Self {
JoinIter {
iter: iter.peekable(),
sep,
next_sep: false,
}
}
}
impl<I: Iterator, S: Clone> Iterator for JoinIter<I, S> {
type Item = JoinItem<I::Item, S>;
/// Advance to the next item in the Join. This will either be the next
/// element in the underlying iterator, or a clone of the separator.
fn next(&mut self) -> Option<Self::Item> {
let sep = &self.sep;
let next_sep = &mut self.next_sep;
if *next_sep {
self.iter.peek().map(|_| {
*next_sep = false;
JoinItem::Separator(sep.clone())
})
} else {
self.iter.next().map(|element| {
*next_sep = true;
JoinItem::Element(element)
})
}
}
}
A reference to Join
implements IntoIterator
:
impl<'a, T, S> IntoIterator for &'a Join<T, S>
where
&'a T: IntoIterator,
{
type IntoIter = JoinIter<<&'a T as IntoIterator>::IntoIter, &'a S>;
type Item = JoinItem<<&'a T as IntoIterator>::Item, &'a S>;
fn into_iter(self) -> Self::IntoIter {
JoinIter::new(self.container.into_iter(), &self.separator)
}
}
This compiles and passes usage tests.
I also have an iter
method defined on my Join
struct:
impl<T, S> Join<T, S>
where
for<'a> &'a T: IntoIterator,
{
pub fn iter(&self) -> JoinIter<<&T as IntoIterator>::IntoIter, &S> {
self.into_iter()
}
}
This compiles fine, but when I actually try to use it:
fn main() {
// Create a join struct
let join = Join {
container: vec![1, 2, 3],
separator: ", ",
};
// This works fine
let mut good_ref_iter = (&join).into_iter();
assert_eq!(good_ref_iter.next(), Some(JoinItem::Element(&1)));
assert_eq!(good_ref_iter.next(), Some(JoinItem::Separator(&", ")));
assert_eq!(good_ref_iter.next(), Some(JoinItem::Element(&2)));
assert_eq!(good_ref_iter.next(), Some(JoinItem::Separator(&", ")));
assert_eq!(good_ref_iter.next(), Some(JoinItem::Element(&3)));
assert_eq!(good_ref_iter.next(), None);
// This line fails to compile; comment out this section and it all works
let bad_ref_iter = join.iter();
assert_eq!(bad_ref_iter.next(), Some(JoinItem::Element(&1)));
assert_eq!(bad_ref_iter.next(), Some(JoinItem::Separator(&", ")));
assert_eq!(bad_ref_iter.next(), Some(JoinItem::Element(&2)));
assert_eq!(bad_ref_iter.next(), Some(JoinItem::Separator(&", ")));
assert_eq!(bad_ref_iter.next(), Some(JoinItem::Element(&3)));
assert_eq!(bad_ref_iter.next(), None);
}
I get some kind of weird type recursion error:
error[E0275]: overflow evaluating the requirement `&_: std::marker::Sized`
--> src/join.rs:288:29
|
96 | let mut iter = join.iter();
| ^^^^
|
= help: consider adding a `#![recursion_limit="128"]` attribute to your crate
= note: required because of the requirements on the impl of `std::iter::IntoIterator` for `&_`
= note: required because of the requirements on the impl of `std::iter::IntoIterator` for `&join::Join<_, _>`
= note: required because of the requirements on the impl of `std::iter::IntoIterator` for `&join::Join<join::Join<_, _>, _>`
= note: required because of the requirements on the impl of `std::iter::IntoIterator` for `&join::Join<join::Join<join::Join<_, _>, _>, _>`
= note: required because of the requirements on the impl of `std::iter::IntoIterator` for `&join::Join<join::Join<join::Join<join::Join<_, _>, _>, _>, _>`
= note: required because of the requirements on the impl of `std::iter::IntoIterator` for `&join::Join<join::Join<join::Join<join::Join<join::Join<_, _>, _>, _>, _>, _>`
= note: required because of the requirements on the impl of `std::iter::IntoIterator` for `&join::Join<join::Join<join::Join<join::Join<join::Join<join::Join<_, _>, _>, _>, _>, _>, _>`
...
(I redacted about 100 more lines of recursive type error in the ...)
As best I can tell, it appears to be attempting to proactively evaluate whether &Join<_, _>
implements IntoIterator
, which requires checking if &Join<Join<_, _>, _>
fulfills IntoIterator, and so on forever. What I can't figure out is why it thinks it has to do this, since my actual type is fully qualified as Join<Vec<{integer}, &'static str>
. Some things I've tried:
Moving the trait bound off of the impl header and into the
iter
function, like so:
fn iter(&'a self) -> JoinIter<<&'a T as IntoIterator>::IntoIter, &'a S>
where &'a T: IntoIterator
This has the same result.
Replacing
self.into_iter()
with the underlying expression,JoinIter::new(self.container.into_iter(), self.separator)
, in the hopes that maybe it's struggling to differentiateself.into_iter()
from(&self).into_iter()
. I've tried all of the following patterns:
fn iter(&self) -> ... { self.into_iter() }
fn iter(&self) -> ... { (&self).into_iter() }
fn iter(&self) -> ... { JoinIter::new(self.container.into_iter(), &self.separator) }
fn iter(&self) -> ... { JoinIter::new((&self.container).into_iter(), &self.separator) }
- Speaking of which, replacing the call to
self.iter()
with(&self).into_iter()
fixes the problem, but replacing it with(&self).iter()
does not.
Why does (&join).into_iter()
work, but join.iter()
does not, even though iter()
simply calls self.into_iter()
under the hood?
This complete example, with identical code, is also available in the Rust Playground
For more context about Join
, see my older Stack Overflow question and my actual source code.
types reference rust type-inference
types reference rust type-inference
edited Nov 22 at 21:11
Shepmaster
145k11279413
145k11279413
asked Nov 21 at 4:31
Lucretiel
793823
793823
1
@Lucretiel I've reduced the playground example to a fraction of its size. Note that removing the emptyimpl
block makes the error go away. This gives some clues why it is occurring, but I don't really have an explanation yet. Also note that the line triggering the error now islet _ = join;
.
– Sven Marnach
Nov 21 at 21:10
@SvenMarnach that microexample has the same error as my code, but doesn't reproduce my specific issue. In my code,IntoIterator
DOES work fine; it's thefn iter()
(which literally just callsinto_iter()
) that inexplicably breaks
– Lucretiel
Nov 21 at 23:23
add a comment |
1
@Lucretiel I've reduced the playground example to a fraction of its size. Note that removing the emptyimpl
block makes the error go away. This gives some clues why it is occurring, but I don't really have an explanation yet. Also note that the line triggering the error now islet _ = join;
.
– Sven Marnach
Nov 21 at 21:10
@SvenMarnach that microexample has the same error as my code, but doesn't reproduce my specific issue. In my code,IntoIterator
DOES work fine; it's thefn iter()
(which literally just callsinto_iter()
) that inexplicably breaks
– Lucretiel
Nov 21 at 23:23
1
1
@Lucretiel I've reduced the playground example to a fraction of its size. Note that removing the empty
impl
block makes the error go away. This gives some clues why it is occurring, but I don't really have an explanation yet. Also note that the line triggering the error now is let _ = join;
.– Sven Marnach
Nov 21 at 21:10
@Lucretiel I've reduced the playground example to a fraction of its size. Note that removing the empty
impl
block makes the error go away. This gives some clues why it is occurring, but I don't really have an explanation yet. Also note that the line triggering the error now is let _ = join;
.– Sven Marnach
Nov 21 at 21:10
@SvenMarnach that microexample has the same error as my code, but doesn't reproduce my specific issue. In my code,
IntoIterator
DOES work fine; it's the fn iter()
(which literally just calls into_iter()
) that inexplicably breaks– Lucretiel
Nov 21 at 23:23
@SvenMarnach that microexample has the same error as my code, but doesn't reproduce my specific issue. In my code,
IntoIterator
DOES work fine; it's the fn iter()
(which literally just calls into_iter()
) that inexplicably breaks– Lucretiel
Nov 21 at 23:23
add a comment |
1 Answer
1
active
oldest
votes
up vote
2
down vote
It seems that the compiler is not able to resolve the trait requirement needed by iter()
return type JoinIter<<&T as IntoIterator>::IntoIter, &S>
.
I've received an hint for this from rustc --explain E0275
error explanation:
This error occurs when there was a recursive trait requirement that overflowed
before it could be evaluated. Often this means that there is unbounded
recursion in resolving some type bounds.
I don't know the details of the inference process of rust, I imagine the following is happening.
Take this signature:
fn iter(&self) -> JoinIter<<&T as IntoIterator>::IntoIter, &S>
The compiler try to infer the return type from:
JoinIter<<&T as IntoIterator>::IntoIter, &S>
but <&T as IntoIterator>::IntoIter
is inferred from the &'a Join
impl:
impl<'a, T, S> IntoIterator for &'a Join<T, S>
where &'a T: IntoIterator
{
type IntoIter = JoinIter<<&'a T as IntoIterator>::IntoIter, &'a S>;
type Item = JoinItem<<&'a T as IntoIterator>::Item, &'a S>;
fn into_iter(self) -> Self::IntoIter {
JoinIter::new(self.container.into_iter(), &self.separator)
}
}
and IntoIter
is again a JoinIter<<&'a T as IntoIterator>::IntoIter, &'a S>
that has an IntoIter
and so and so ad infinitum.
A way to make it compile it is to help the compiler with a turbofish:
let mut bad_ref_iter = Join::<Vec<i32>, &str>::iter(&join);
instead of:
let bad_ref_iter = join.iter();
Update
The line:
type IntoIter = JoinIter<<&'a T as IntoIterator>::IntoIter, &'a S>;
generate a recursion because Rust checks that traits are valid when they are defined rather than when they are used.
See this post for some more details and pointers to the progress of work
of lazy normalization, which may solve this problem.
1
I still don't have any clue where the infinite recursion is coming from. Why does<&T as IntoIterator>::IntoIter
need to be "inferred"? My understanding is theT
andS
are inferred from the type ofjoin
, but onceT
is known,<&T as IntoIterator>::IntoIter
is a complete type that does not require any inference. The work-around is nice, but the source of the problem remains a complete mystery to me.
– Sven Marnach
Nov 22 at 18:02
Could be that the recursion happens beforeT
andS
are inferred fromjoin
? Look at this
– attdona
Nov 23 at 6:41
cross-posted here
– attdona
Nov 23 at 7:24
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
It seems that the compiler is not able to resolve the trait requirement needed by iter()
return type JoinIter<<&T as IntoIterator>::IntoIter, &S>
.
I've received an hint for this from rustc --explain E0275
error explanation:
This error occurs when there was a recursive trait requirement that overflowed
before it could be evaluated. Often this means that there is unbounded
recursion in resolving some type bounds.
I don't know the details of the inference process of rust, I imagine the following is happening.
Take this signature:
fn iter(&self) -> JoinIter<<&T as IntoIterator>::IntoIter, &S>
The compiler try to infer the return type from:
JoinIter<<&T as IntoIterator>::IntoIter, &S>
but <&T as IntoIterator>::IntoIter
is inferred from the &'a Join
impl:
impl<'a, T, S> IntoIterator for &'a Join<T, S>
where &'a T: IntoIterator
{
type IntoIter = JoinIter<<&'a T as IntoIterator>::IntoIter, &'a S>;
type Item = JoinItem<<&'a T as IntoIterator>::Item, &'a S>;
fn into_iter(self) -> Self::IntoIter {
JoinIter::new(self.container.into_iter(), &self.separator)
}
}
and IntoIter
is again a JoinIter<<&'a T as IntoIterator>::IntoIter, &'a S>
that has an IntoIter
and so and so ad infinitum.
A way to make it compile it is to help the compiler with a turbofish:
let mut bad_ref_iter = Join::<Vec<i32>, &str>::iter(&join);
instead of:
let bad_ref_iter = join.iter();
Update
The line:
type IntoIter = JoinIter<<&'a T as IntoIterator>::IntoIter, &'a S>;
generate a recursion because Rust checks that traits are valid when they are defined rather than when they are used.
See this post for some more details and pointers to the progress of work
of lazy normalization, which may solve this problem.
1
I still don't have any clue where the infinite recursion is coming from. Why does<&T as IntoIterator>::IntoIter
need to be "inferred"? My understanding is theT
andS
are inferred from the type ofjoin
, but onceT
is known,<&T as IntoIterator>::IntoIter
is a complete type that does not require any inference. The work-around is nice, but the source of the problem remains a complete mystery to me.
– Sven Marnach
Nov 22 at 18:02
Could be that the recursion happens beforeT
andS
are inferred fromjoin
? Look at this
– attdona
Nov 23 at 6:41
cross-posted here
– attdona
Nov 23 at 7:24
add a comment |
up vote
2
down vote
It seems that the compiler is not able to resolve the trait requirement needed by iter()
return type JoinIter<<&T as IntoIterator>::IntoIter, &S>
.
I've received an hint for this from rustc --explain E0275
error explanation:
This error occurs when there was a recursive trait requirement that overflowed
before it could be evaluated. Often this means that there is unbounded
recursion in resolving some type bounds.
I don't know the details of the inference process of rust, I imagine the following is happening.
Take this signature:
fn iter(&self) -> JoinIter<<&T as IntoIterator>::IntoIter, &S>
The compiler try to infer the return type from:
JoinIter<<&T as IntoIterator>::IntoIter, &S>
but <&T as IntoIterator>::IntoIter
is inferred from the &'a Join
impl:
impl<'a, T, S> IntoIterator for &'a Join<T, S>
where &'a T: IntoIterator
{
type IntoIter = JoinIter<<&'a T as IntoIterator>::IntoIter, &'a S>;
type Item = JoinItem<<&'a T as IntoIterator>::Item, &'a S>;
fn into_iter(self) -> Self::IntoIter {
JoinIter::new(self.container.into_iter(), &self.separator)
}
}
and IntoIter
is again a JoinIter<<&'a T as IntoIterator>::IntoIter, &'a S>
that has an IntoIter
and so and so ad infinitum.
A way to make it compile it is to help the compiler with a turbofish:
let mut bad_ref_iter = Join::<Vec<i32>, &str>::iter(&join);
instead of:
let bad_ref_iter = join.iter();
Update
The line:
type IntoIter = JoinIter<<&'a T as IntoIterator>::IntoIter, &'a S>;
generate a recursion because Rust checks that traits are valid when they are defined rather than when they are used.
See this post for some more details and pointers to the progress of work
of lazy normalization, which may solve this problem.
1
I still don't have any clue where the infinite recursion is coming from. Why does<&T as IntoIterator>::IntoIter
need to be "inferred"? My understanding is theT
andS
are inferred from the type ofjoin
, but onceT
is known,<&T as IntoIterator>::IntoIter
is a complete type that does not require any inference. The work-around is nice, but the source of the problem remains a complete mystery to me.
– Sven Marnach
Nov 22 at 18:02
Could be that the recursion happens beforeT
andS
are inferred fromjoin
? Look at this
– attdona
Nov 23 at 6:41
cross-posted here
– attdona
Nov 23 at 7:24
add a comment |
up vote
2
down vote
up vote
2
down vote
It seems that the compiler is not able to resolve the trait requirement needed by iter()
return type JoinIter<<&T as IntoIterator>::IntoIter, &S>
.
I've received an hint for this from rustc --explain E0275
error explanation:
This error occurs when there was a recursive trait requirement that overflowed
before it could be evaluated. Often this means that there is unbounded
recursion in resolving some type bounds.
I don't know the details of the inference process of rust, I imagine the following is happening.
Take this signature:
fn iter(&self) -> JoinIter<<&T as IntoIterator>::IntoIter, &S>
The compiler try to infer the return type from:
JoinIter<<&T as IntoIterator>::IntoIter, &S>
but <&T as IntoIterator>::IntoIter
is inferred from the &'a Join
impl:
impl<'a, T, S> IntoIterator for &'a Join<T, S>
where &'a T: IntoIterator
{
type IntoIter = JoinIter<<&'a T as IntoIterator>::IntoIter, &'a S>;
type Item = JoinItem<<&'a T as IntoIterator>::Item, &'a S>;
fn into_iter(self) -> Self::IntoIter {
JoinIter::new(self.container.into_iter(), &self.separator)
}
}
and IntoIter
is again a JoinIter<<&'a T as IntoIterator>::IntoIter, &'a S>
that has an IntoIter
and so and so ad infinitum.
A way to make it compile it is to help the compiler with a turbofish:
let mut bad_ref_iter = Join::<Vec<i32>, &str>::iter(&join);
instead of:
let bad_ref_iter = join.iter();
Update
The line:
type IntoIter = JoinIter<<&'a T as IntoIterator>::IntoIter, &'a S>;
generate a recursion because Rust checks that traits are valid when they are defined rather than when they are used.
See this post for some more details and pointers to the progress of work
of lazy normalization, which may solve this problem.
It seems that the compiler is not able to resolve the trait requirement needed by iter()
return type JoinIter<<&T as IntoIterator>::IntoIter, &S>
.
I've received an hint for this from rustc --explain E0275
error explanation:
This error occurs when there was a recursive trait requirement that overflowed
before it could be evaluated. Often this means that there is unbounded
recursion in resolving some type bounds.
I don't know the details of the inference process of rust, I imagine the following is happening.
Take this signature:
fn iter(&self) -> JoinIter<<&T as IntoIterator>::IntoIter, &S>
The compiler try to infer the return type from:
JoinIter<<&T as IntoIterator>::IntoIter, &S>
but <&T as IntoIterator>::IntoIter
is inferred from the &'a Join
impl:
impl<'a, T, S> IntoIterator for &'a Join<T, S>
where &'a T: IntoIterator
{
type IntoIter = JoinIter<<&'a T as IntoIterator>::IntoIter, &'a S>;
type Item = JoinItem<<&'a T as IntoIterator>::Item, &'a S>;
fn into_iter(self) -> Self::IntoIter {
JoinIter::new(self.container.into_iter(), &self.separator)
}
}
and IntoIter
is again a JoinIter<<&'a T as IntoIterator>::IntoIter, &'a S>
that has an IntoIter
and so and so ad infinitum.
A way to make it compile it is to help the compiler with a turbofish:
let mut bad_ref_iter = Join::<Vec<i32>, &str>::iter(&join);
instead of:
let bad_ref_iter = join.iter();
Update
The line:
type IntoIter = JoinIter<<&'a T as IntoIterator>::IntoIter, &'a S>;
generate a recursion because Rust checks that traits are valid when they are defined rather than when they are used.
See this post for some more details and pointers to the progress of work
of lazy normalization, which may solve this problem.
edited Nov 24 at 17:51
answered Nov 22 at 13:37
attdona
2,93411120
2,93411120
1
I still don't have any clue where the infinite recursion is coming from. Why does<&T as IntoIterator>::IntoIter
need to be "inferred"? My understanding is theT
andS
are inferred from the type ofjoin
, but onceT
is known,<&T as IntoIterator>::IntoIter
is a complete type that does not require any inference. The work-around is nice, but the source of the problem remains a complete mystery to me.
– Sven Marnach
Nov 22 at 18:02
Could be that the recursion happens beforeT
andS
are inferred fromjoin
? Look at this
– attdona
Nov 23 at 6:41
cross-posted here
– attdona
Nov 23 at 7:24
add a comment |
1
I still don't have any clue where the infinite recursion is coming from. Why does<&T as IntoIterator>::IntoIter
need to be "inferred"? My understanding is theT
andS
are inferred from the type ofjoin
, but onceT
is known,<&T as IntoIterator>::IntoIter
is a complete type that does not require any inference. The work-around is nice, but the source of the problem remains a complete mystery to me.
– Sven Marnach
Nov 22 at 18:02
Could be that the recursion happens beforeT
andS
are inferred fromjoin
? Look at this
– attdona
Nov 23 at 6:41
cross-posted here
– attdona
Nov 23 at 7:24
1
1
I still don't have any clue where the infinite recursion is coming from. Why does
<&T as IntoIterator>::IntoIter
need to be "inferred"? My understanding is the T
and S
are inferred from the type of join
, but once T
is known, <&T as IntoIterator>::IntoIter
is a complete type that does not require any inference. The work-around is nice, but the source of the problem remains a complete mystery to me.– Sven Marnach
Nov 22 at 18:02
I still don't have any clue where the infinite recursion is coming from. Why does
<&T as IntoIterator>::IntoIter
need to be "inferred"? My understanding is the T
and S
are inferred from the type of join
, but once T
is known, <&T as IntoIterator>::IntoIter
is a complete type that does not require any inference. The work-around is nice, but the source of the problem remains a complete mystery to me.– Sven Marnach
Nov 22 at 18:02
Could be that the recursion happens before
T
and S
are inferred from join
? Look at this– attdona
Nov 23 at 6:41
Could be that the recursion happens before
T
and S
are inferred from join
? Look at this– attdona
Nov 23 at 6:41
cross-posted here
– attdona
Nov 23 at 7:24
cross-posted here
– attdona
Nov 23 at 7:24
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53405287%2fwhats-going-on-with-this-bizarre-recursive-type-error-in-rust%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
@Lucretiel I've reduced the playground example to a fraction of its size. Note that removing the empty
impl
block makes the error go away. This gives some clues why it is occurring, but I don't really have an explanation yet. Also note that the line triggering the error now islet _ = join;
.– Sven Marnach
Nov 21 at 21:10
@SvenMarnach that microexample has the same error as my code, but doesn't reproduce my specific issue. In my code,
IntoIterator
DOES work fine; it's thefn iter()
(which literally just callsinto_iter()
) that inexplicably breaks– Lucretiel
Nov 21 at 23:23