Repository navigation
Admit attached command handlers beside produces - #1075
Merged
Merged
Conversation
Contributor
Author
|
Corpus impact: tracked in Cratis/AI#945 (attached handler admission, PLAY0035 retirement, PLAY0800 narrowing, duplicate attached handlers). Reviewer notes:
|
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
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.
Added
producesbeside an attachedhandlerwhose body is a nonempty language-tagged code fence or a resolvedfile. The pair binds in executable model v23, andproducesacts as the handler's fixed result contract. Bodies remain opaque: reference execution still reports body execution as unsupported, and a target must admit the language and implementation separately. (Research source-native command-handler admission without weakening PLAY0800 #1068)Changed
PLAY0035is retired and no longer reported. Attached handlers without unconditionalproduces, or without a resolved nonempty body or a known file language, keep reportingPLAY0800.handler, including across composed command fragments, now reports a duplicate declaration (PLAY0168) instead of letting one body replace the other.