Repository navigation
feat(kernel-utils): narrowInterfaceGuard - #1051
Closed
ci-belphegor wants to merge 1 commit into
Closed
ci-belphegor wants to merge 1 commit into
ci-belphegor wants to merge 1 commit into
Conversation
ci-belphegor
force-pushed
the
grypez/narrowing-5-narrow-interface-guard
branch
from
September 11, 2026 11:42
64369a0 to
810752b
Compare
ci-belphegor
added this pull request to stack #1060
September 11, 2026 11:44
ci-belphegor
force-pushed
the
grypez/narrowing-5-narrow-interface-guard
branch
from
September 29, 2026 17:36
810752b to
217d124
Compare
ci-belphegor
added
the
no-changelog
Contributor
Coverage Report
File Coverage
|
||||||||||||||||||||||||||||||||||||||||||||||||||
ci-belphegor
force-pushed
the
grypez/narrowing-5-narrow-interface-guard
branch
from
September 30, 2026 13:44
217d124 to
ef85f47
Compare
ci-belphegor
force-pushed
the
grypez/narrowing-5-narrow-interface-guard
branch
from
September 30, 2026 16:18
ef85f47 to
b70cc93
Compare
ci-belphegor
removed this pull request from stack #1060
September 30, 2026 16:44
ci-belphegor
added this pull request to stack #1130
September 30, 2026 16:45
Derive the interface guard of a narrowing: conjoin each delta pattern onto the base's guard at the argument position it addresses, inherit arity, the required/optional/rest split, and return guards verbatim, drop methods the delta does not name, and asyncify every method guard for forwarding. The guard is constructed as a conjunction with the base's own rather than checked against it, so it admits no call the base does not. That is the precondition join needs to disjoin two deltas without a pattern subtyping decision procedure. A delta naming a method the base guards by default still throws; PR-8 relaxes that arm into synthesizing a guard from the delta. No exos, promises, or provenance — narrow wraps this. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ci-belphegor
force-pushed
the
grypez/narrowing-5-narrow-interface-guard
branch
from
October 1, 2026 18:38
b70cc93 to
9ee7180
Compare
3 of 4 tasks
Contributor
Author
|
Superseded by #1134, which lands the narrowing library as one PR with no stubs. This PR's change is kept as a commit there for review. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Explanation
The algebraic heart of narrowing, and the PR that most deserves scrutiny — hence deliberately free of exos, promises, and provenance. A pure
narrowInterfaceGuard({ name, baseGuard, delta }) => InterfaceGuardthat conjoins each delta pattern onto the corresponding argument position, inherits arity, optional and rest positions and return guards verbatim, drops methods the delta does not name, and asyncifies every method guard.Position
iaddresses the base's guard atiwalking required arguments, then optionals, then the rest guard, and stays in whichever category it lands in. A delta cannot promote an optional to required and cannot change arity.Dropping unlisted methods makes the safe outcome the default: forgetting a method removes authority rather than granting it.
narrowInterfaceGuardis not exported:narrowis its only caller, so it stays internal tokernel-utilsand this PR carries no changelog entry (labelledno-changelog).Notes for reviewers
A position landing in the rest guard conjoins onto that one guard, and therefore constrains every trailing argument rather than only the position named — a rest guard is a single pattern, so per-position narrowing is unrepresentable there without changing arity. It stays ⊆ the base, and the surprise runs in the safe direction: the author gets less authority than intended, never more. Tested, and specified in the design doc.
An empty delta must be a no-op, not a narrowing.
{ readFile: [] }is defined as keeping a method entirely unchanged, so the claim soundness needs is ⊆, not ⊂.The two "method not in
methodGuards" errors are split ondefaultGuards, which is a seam rather than a stylistic choice: a strict interface hasdefaultGuards: undefined, so the method genuinely does not exist, whereas a'passable'interface admits it and merely guards it by default. PR 8 replaces only the second arm.getGuardAtis deliberately not reused here. It maps a position to a guard, but narrowing has to write back into the category the position landed in; threading it through would have forced a non-null assertion or an unreachableundefinedbranch. Mapping over the base's ownargGuards/optionalArgGuardsmakes the category boundary the loop bound, so it is the same walk with no duplicated logic.Unmarks no ratchet cases.
Stack
PR 5 of 12. Base: #1050.