add static interfaces in the form of signature types - #1543
Draft
zerbina wants to merge 20 commits into
Draft
Conversation
zerbina
added
enhancement
beef331
reviewed
May 12, 2025
beef331
reviewed
May 12, 2025
beef331
reviewed
May 12, 2025
zerbina
changed the title
* there's a dedicated `signature` type constructor now. This is better
than the concept + pragma approach, but still not ideal
* `method`s are no longer allowed in signatures. I couldn't think of a
good reason for allowing them ("why not" doesn't count)
* call operators are now allowed. This rule might need to be narrowed
down again
To represent signature types and applied signature types, respectively.
Applied signature types are concrete types and may thus be used anywhere concrete types may be used; raw signature types are meta types.
In the context of hooks, applied signature types are ignored and treated as if they were their underlying type.
They're handled much like concepts, in that they're treated as their underlying type.
Picking a symbol to borrow via regular overload resolution is wrong because: * it cannot enforce specific effects for the overload (raises, tags, and noSideEffect) * it admits conversions * it effectively ignores `sink` and other type modifiers all of which are things that are not desired when picking a routine to borrow from.
* handle pragma lists * set up the types w.r.t. effects * set the correct default calling convention for iterators
They're not good, but neither are most of the existing specification tests...
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
2 participants
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.
Signature types are meant to provide static interfaces, which would be a first step towards type-checked generic routines and (maybe) eventually removing
.borrow.The name
signatureis a working title. It's not yet clear whether the feature will take overconceptor stay as its own entity, and thus theconceptsyntax is simply reused.The current specification is not meant to represent the final form. It's a version of the feature as discussed so far that's narrowed-down as much as possible in order to make a robust implementation feasible/possible with the current compiler. Further restrictions due to issues discovered during implementation are likely.
The feature was inspired by the
signaturefeature of Standard ML.To-Do
add a signature pragmaTTypekinds for signature types and their applied form