Add `this` as a self type by HT154 · Pull Request #1708 · apple/pkl

HT154 · 2026-06-26T22:59:00Z

This PR:

Adds type this, a fully featured self type for use in modules or classes.
- Forbids use of this in typealias bodies.
Deprecates usage of the module type in class and typealias bodies with a warning, to be an error in a future release.
- In some cases this induces incorrect or undefined behavior (see module types as typelias type args are evaluated in the context of the alias's module, not where module is used #1712).
- Usages should either be replaced by this or a self-import and use of the current module.
Adopts this in the standard library:
- pkl.base#Any.getClass() now returns Class<this>.
- pkl.base#Any.ifNonNull() now accepts an argument of type (this) -> Result.
- pkl.ref#Domain.renderReference() now accepts a Reference<this, Any>.
This also a corner case with ReferenceTypeNode, module types, and type aliases that caused module types in the referent position to always be resolved to the module where the Reference type annotation is instead of where module is used.

For ease of review, this PR consists of two commits; the first is all implementation changes, the second includes regenerated pkl-doc test output.

Resolves #1612
Resolves #1712

HT154 · 2026-07-02T22:34:54Z

+  /**
+   * If {@code frame} is provided then self types should be resolved to real types, otherwise return
+   * the self PType
+   */
+  protected PType doExport(@Nullable VirtualFrame frame) {


ReferenceTypeNode needs to export the real class here, so when a frame is passed NonFinalSelfTypeNode uses it to get the target's class instead of exporting PType.MODULE/PType.THIS.

bioball

Left some comments!

The major ones are:

Much of the resolution logic should happen inside AstBuilder; we shouldn't need to traverse the truffle tree
Not sure about the realTypeAliasFrame logic added to type node execution; this feels like a workaround to a deeper issue
Not sure if TypeNode.export() should be deferencing self types; this feels like the responsibility of the caller, not TypeNode itself

bioball · 2026-07-20T17:42:38Z

+              if (typeAliasNode.isBodyChild(prevParent)) {
+                throw exceptionBuilder()
+                    .evalError("invalidSelfTypeUsage", "this", "type alias")
+                    .build();


I think we should handle this error at parse time in AstBuilder, rather than here. We should walk the parser syntax tree, rather than Truffle

bioball · 2026-07-20T20:04:28Z

      }
+      PType.THIS -> {
+        +"this"
+      }


Need to also handle PType.THIS in SearchIndexGenerator and PackageDataGenerator

bioball · 2026-07-20T21:26:31Z

+
+      return VmUtils.getClass(getReceiverNode.executeGeneric(frame));
+    }
+  }


Same comment as above: I think this should be done at parse time (within AstBuilder), not here.

This truffle node can receive the (nullable) enclosing class name, and use a combination of GetModuleNode (in the case of no enclosing module) and ResolveSimpleDeclaredTypeNode (in the case of an enclosing module) to get the correct VmClass

Within AstBuilder, we can walk up the symbol table scope until we find a Class scope to find the class identifier.

We can also maybe introduce a ReadClassNode or something like that perhaps that receives the identifier name, whether it's local, and whether it's the module class.

bioball · 2026-07-20T21:32:09Z

+
+    private VirtualFrame getEffectiveFrame(VirtualFrame frame) {
+      var realFrame = VmLanguage.get(this).localContext.get().getRealTypeAliasFrame();
+      return realFrame != null ? realFrame : frame;


I'm trying to understand what this code is doing; is this to address the case of typealias Foo = module?'

If so, I think probably a better solution here is: when we execute a TypeAliasNode, we can replace the module type when we execute the type alias itself (e.g. inside TypeAliasNode#executeGeneric)

bioball · 2026-07-20T21:52:10Z

      // gets replaced upon instantiation, and Function can bubble up to users as a reference error
      // if accessed.
      result.add(type);
+      // PType.MODULE and PType.THIS can never be encountered here; caller must deref self types


I don't think this is actually happening here? This class is just calling clazz.export() in the constructor, which won't pass in a frame, which won't defer self types.

Also: I don't know if it's worth investing too much into this code path; I think we should introduce a VmType value. If we had that, the TypeNode.export() call wouldn't be used.

bioball · 2026-07-20T21:54:17Z

        }
      };

+  /** The type of the enclosing owner. */


Suggested change

/** The type of the enclosing owner. */

/** The {@code this} type. */

bioball · 2026-07-20T21:55:42Z

 `Reference` referent type argument may not include type constraints.
+
+invalidSelfTypeUsage=\
+`{0}` type annotations are not allowed in {1} bodies.


A "type annotation" is the thing on the right-hand side of a typed identifier; foo: Bar has type annotation : Bar

Suggested change

`{0}` type annotations are not allowed in {1} bodies.

`{0}` types are not allowed in {1} bodies.

bioball · 2026-07-20T21:56:59Z

  }

  @Override
+  @TruffleBoundary


Leftover code? This didn't need a truffle boundary before, so I wouldn't expect this to need one now

bioball · 2026-07-20T21:58:51Z

@@ -0,0 +1,14 @@
+–– Pkl Error ––
+`this` type annotations are not allowed in type alias bodies.


For consistency with other error messages, I think let's phrase this as:

Cannot declare `this` types inside type alias bodies.

HT154 force-pushed the this-type branch 3 times, most recently from 6fb74b2 to fa93f3d Compare June 28, 2026 18:50

HT154 mentioned this pull request Jun 28, 2026

module types as typelias type args are evaluated in the context of the alias's module, not where module is used #1712

Open

HT154 force-pushed the this-type branch 3 times, most recently from a1d16f8 to 55f923c Compare June 29, 2026 20:05

HT154 mentioned this pull request Jun 30, 2026

Correctly handle module types as typealias parameters #1713

Closed

HT154 force-pushed the this-type branch 19 times, most recently from 71958eb to a8c3282 Compare July 2, 2026 22:29

HT154 commented Jul 2, 2026

View reviewed changes

Comment thread pkl-core/src/main/java/org/pkl/core/ast/type/TypeNode.java Outdated

HT154 force-pushed the this-type branch from a8c3282 to cca7e7b Compare July 2, 2026 22:32

HT154 commented Jul 2, 2026

View reviewed changes

HT154 force-pushed the this-type branch 2 times, most recently from 41b3a9f to 9d20551 Compare July 3, 2026 06:18

HT154 marked this pull request as ready for review July 4, 2026 19:10

HT154 force-pushed the this-type branch 2 times, most recently from b00e394 to a5729f3 Compare July 4, 2026 19:12

HT154 force-pushed the this-type branch 4 times, most recently from 835f94f to 6c21103 Compare July 15, 2026 19:18

Add this as a self type

5867651

HT154 force-pushed the this-type branch from 6c21103 to 84c587e Compare July 15, 2026 22:39

bioball requested changes Jul 20, 2026

View reviewed changes

Regen pkl-doc test output

ad36a52

HT154 force-pushed the this-type branch from 84c587e to ad36a52 Compare July 20, 2026 23:03

	/** The type of the enclosing owner. */
	/** The {@code this} type. */

	`{0}` type annotations are not allowed in {1} bodies.
	`{0}` types are not allowed in {1} bodies.

		@@ -0,0 +1,14 @@
		–– Pkl Error ––
		`this` type annotations are not allowed in type alias bodies.

Uh oh!

Conversation

HT154 commented Jun 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bioball left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

HT154 commented Jun 26, 2026 •

edited

Loading