starred/pkl
1
0
Fork 0
mirror of https://github.com/apple/pkl.git synced 2026-01-11 22:30:54 +01:00
Code Issues 198 Packages Projects Releases 10 Wiki Activity

[PR #510] [CLOSED] Restore late-binding for constraints within typealiases #592

New Issue
Closed
opened 2025-12-30 01:25:32 +01:00 by adam · 0 comments
adam commented 2025-12-30 01:25:32 +01:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/apple/pkl/pull/510
Author: @bioball
Created: 5/30/2024
Status: ❌ Closed

Base: main ← Head: typealias-late-binding

📝 Commits (1)

  • 5900247 Restore late-binding for constraints within typealiases

📊 Changes

12 files changed (+92 additions, -7 deletions)

View changed files

📝 pkl-core/src/main/java/org/pkl/core/ast/type/ResolveQualifiedDeclaredTypeNode.java (+2 -1)
📝 pkl-core/src/main/java/org/pkl/core/ast/type/TypeNode.java (+11 -4)
📝 pkl-core/src/main/java/org/pkl/core/ast/type/UnresolvedTypeNode.java (+20 -2)
📝 pkl-core/src/main/java/org/pkl/core/runtime/VmTyped.java (+10 -0)
➕ pkl-core/src/test/files/LanguageSnippetTests/input/types/helpers/someModule2.pkl (+3 -0)
➕ pkl-core/src/test/files/LanguageSnippetTests/input/types/helpers/someModule3.pkl (+3 -0)
➕ pkl-core/src/test/files/LanguageSnippetTests/input/types/typeAliasConstraint3.pkl (+25 -0)
➕ pkl-core/src/test/files/LanguageSnippetTests/input/types/typeAliasConstraint4.pkl (+5 -0)
➕ pkl-core/src/test/files/LanguageSnippetTests/output/types/helpers/someModule2.pcf (+1 -0)
➕ pkl-core/src/test/files/LanguageSnippetTests/output/types/helpers/someModule3.pcf (+1 -0)
➕ pkl-core/src/test/files/LanguageSnippetTests/output/types/typeAliasConstraint3.pcf (+9 -0)
➕ pkl-core/src/test/files/LanguageSnippetTests/output/types/typeAliasConstraint4.pcf (+2 -0)

📄 Description

This is one proposal to fix https://github.com/apple/pkl/issues/446.

This changes the behavior of typealiases such that:

  • If the current frame's receiver is amending the typealias's declared module, set the constraint to the current receiver.
  • Otherwise, set it to either the receiver of a qualified type declaration, or the typealias's enclosing receiver.

This implies that the meaning of a typealias can change depending on where it is resolved from. Given the following:

// module1.pkl
typealias MyTypeAlias = Any(isValid)

isValid = false

// module2.pkl
amends "module1.pkl"

isValid = true

These two properties have different type checks:

import "module1.pkl"
import "module2.pkl"

propA: module1.MyTypeAlias // always fails
propB: module2.MyTypeAlias // always passes

Despite this, they are considered the same typealias.

import "module1.pkl"
import "module2.pkl"

res = module1.MyTypeAlias == module2.MyTypeAlias // true

This is somewhat quirky. An alternative solution to this problem is to require any references from a constraint to be const. This is just like how classes work. However, this solution would limit the usefulness of typealiases.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/apple/pkl/pull/510 **Author:** [@bioball](https://github.com/bioball) **Created:** 5/30/2024 **Status:** ❌ Closed **Base:** `main` ← **Head:** `typealias-late-binding` --- ### 📝 Commits (1) - [`5900247`](https://github.com/apple/pkl/commit/59002471a1aef67bdd91d5cf397f94c612516c8a) Restore late-binding for constraints within typealiases ### 📊 Changes **12 files changed** (+92 additions, -7 deletions) <details> <summary>View changed files</summary> 📝 `pkl-core/src/main/java/org/pkl/core/ast/type/ResolveQualifiedDeclaredTypeNode.java` (+2 -1) 📝 `pkl-core/src/main/java/org/pkl/core/ast/type/TypeNode.java` (+11 -4) 📝 `pkl-core/src/main/java/org/pkl/core/ast/type/UnresolvedTypeNode.java` (+20 -2) 📝 `pkl-core/src/main/java/org/pkl/core/runtime/VmTyped.java` (+10 -0) ➕ `pkl-core/src/test/files/LanguageSnippetTests/input/types/helpers/someModule2.pkl` (+3 -0) ➕ `pkl-core/src/test/files/LanguageSnippetTests/input/types/helpers/someModule3.pkl` (+3 -0) ➕ `pkl-core/src/test/files/LanguageSnippetTests/input/types/typeAliasConstraint3.pkl` (+25 -0) ➕ `pkl-core/src/test/files/LanguageSnippetTests/input/types/typeAliasConstraint4.pkl` (+5 -0) ➕ `pkl-core/src/test/files/LanguageSnippetTests/output/types/helpers/someModule2.pcf` (+1 -0) ➕ `pkl-core/src/test/files/LanguageSnippetTests/output/types/helpers/someModule3.pcf` (+1 -0) ➕ `pkl-core/src/test/files/LanguageSnippetTests/output/types/typeAliasConstraint3.pcf` (+9 -0) ➕ `pkl-core/src/test/files/LanguageSnippetTests/output/types/typeAliasConstraint4.pcf` (+2 -0) </details> ### 📄 Description This is one proposal to fix https://github.com/apple/pkl/issues/446. This changes the behavior of typealiases such that: * If the current frame's receiver is amending the typealias's declared module, set the constraint to the current receiver. * Otherwise, set it to either the receiver of a qualified type declaration, or the typealias's enclosing receiver. This implies that the meaning of a typealias can change depending on where it is resolved from. Given the following: ```groovy // module1.pkl typealias MyTypeAlias = Any(isValid) isValid = false ``` ```groovy // module2.pkl amends "module1.pkl" isValid = true ``` These two properties have different type checks: ```groovy import "module1.pkl" import "module2.pkl" propA: module1.MyTypeAlias // always fails propB: module2.MyTypeAlias // always passes ``` Despite this, they are considered the same typealias. ```groovy import "module1.pkl" import "module2.pkl" res = module1.MyTypeAlias == module2.MyTypeAlias // true ``` This is somewhat quirky. An alternative solution to this problem is to require any references from a constraint to be `const`. This is just like how classes work. However, this solution would limit the usefulness of typealiases. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
adam added the pull-request label 2025-12-30 01:25:32 +01:00
adam closed this issue 2025-12-30 01:25:32 +01:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
duplicate
enhancement
good first issue
help wanted
pull-request
Mirrored from GitHub Pull Request
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/pkl#592
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?