Type constraints on `typealias`es are evaluated eagerly about pkl HOT 3 OPEN

My understanding is that accessing bar from within a type constraint isn’t allowed because it isn’t const. If you don’t get an error for that it’s probably a bug.

from pkl.

I think @sin-ack is using 0.26.0-dev, which reproduces for me.

We currently have an issue in the latest dev version where typealias bodies are not late-bound (changed a fix for a scoping bug in #144). But, at the same time, they aren't required to be const.

We're thinking through whether typealias bodies should be late-bound, or if this is actually the correct behavior. If this is the correct behavior, then we will add an additional rule that references must be const. If not, then we need to adjust the behavior here so that those references are late-bound.

from pkl.

I can't reproduce this (but also; the snippets you included are not syntactically valid Pkl, so I think something got lost in reduction of the example).

There is a known bug that typealiases resolved names in their definition scope, instead of their use scope. This has been addressed in #373 and will be part of 0.26 (hopefully June).

By the way, toMap() already forces the entire Mapping (keys and values). If you want to keep things lazy, consider keys.intersect(bar.keys) == keys instead.

from pkl.