@mdempsky

I think the error is correct. StringParser[T]'s ToListParser method has a return type of StringParser[[]T]. This means if we want to instantiate StringParser[int], then we'll also have to instantiate StringParser[[]int] too; which then means we'll also have to instantiate StringParser[[][]int], etc etc.

@mdempsky thank you, i got it.

it' may better be reported as infinite instantiation instead of cycle ?

which then means we'll also have to instantiate StringParser[[][]int],

Could you explain how this follows from the previous part? There are no method calls for StringParser[[]int], so it looks like there should never be any need to consider StringParser[[][]int].

Similar code in (say) Rust compiles just fine:

struct StringParser<T> {
    f: Box<dyn Fn(String) -> Option<T>>
}

impl<T> StringParser<T> {
    fn to_list_parser(self) -> StringParser<Vec<T>> {
        todo!()
    }
}

fn parse_list<T>(p: StringParser<T>, s: String) -> Option<Vec<T>> {
    todo!()
}

fn main() {
    let p = StringParser { f: Box::new(|s| str::parse::<i64>(&s).ok()) };
    (p.to_list_parser().f)("1,2,3".to_string());
}

Could you explain how this follows from the previous part?

Go allows method calls to happen dynamically through interface assertions or reflection. As a result, if a type is instantiated, all of its methods must be instantiated too, even if not statically called.

There are certainly cases where we could determine this isn't actually needed, but that would complicate the language specification.