Expressions in type definitions are evaluated before type parameters are bound

[MasonMcGill]

type ZeroGenerator = object
proc next(g: ZeroGenerator): int = 0

# This compiles.
type TripleOfInts = tuple
  a, b, c: type(new(ZeroGenerator)[].next)

# This raises a compiler error before it's even instantiated.
# The `new` proc can't be resolved because `Generator` is not defined.
type TripleLike[Generator] = tuple
  a, b, c: type(new(Generator)[].next)

I'm not sure if this is intended behavior or a bug. There is a workaround, but it's somewhat awkward: you can compute extra types in constructor/initializer routines, though this may lead to extraneous type parameters. e.g this:

type Peekable[Generator] = object
  first: type(new(Generator)[].next)
  rest: Generator

proc newPeekable(generator: any): auto =
  var result: Peekable[type(generator)]
  result.rest = generator
  result.first = result.rest.next
  result

becomes this:

type Peekable[Element, Generator] = object
  first: Element
  rest: Generator

proc newPeekable(generator: any): auto =
  var result: Peekable[type(generator.next), type(generator)]
  result.rest = generator
  result.first = result.rest.next
  result

[jangko]

surely this is another good example of generic early evaluation syndrom similar to #5540

[stale]

This issue has been automatically marked as stale because it has not had recent activity. If you think it is still a valid issue, write a comment below; otherwise it will be closed. Thank you for your contributions.

[shirleyquirk]

using typeof instead of type works. tested on nim 1.6.12

type ZeroGenerator = object
proc next(g:ZeroGenerator):int = 0

type TripleLike[Generator] = tuple
  a,b: typeof(new(Generator)[].next())
  c: typeof(default(Generator).next())

[metagn]

To make it work in general we might need to update mNew/mDefault/all semMagic in the compiler to propagate tyFromExpr as in #22029, #22499

[metagn]

Seems to work now probably because of #23983