Skip to content

Add higher-order types (Kinds) - #351

Merged
joeldrapper merged 1 commit into
mainfrom
kinds
Feb 20, 2026
Merged

Add higher-order types (Kinds)#351
joeldrapper merged 1 commit into
mainfrom
kinds

Conversation

@joeldrapper

@joeldrapper joeldrapper commented Feb 20, 2026

Copy link
Copy Markdown
Collaborator

Added a _Kind generic to create higher-order types (kinds). This type constructor takes a type and return the type of its type. In other words, it will match the type itself or any subtype of that type.

IntegerKind = _Kind(Integer)

This is useful in situations where you want to take a type as an argument and you want to constrain what kinds of types are allowed.

_Kind works for complex types too

ArrayOfIntegerKind = _Kind(_Array(Integer))

If you want to compose one kind into another, you can lift it with type.

IntegerKind = _Kind(Integer)
ArrayOfIntegerKind = _Kind(IntegerKind.type)

I am using this to create operation classes where parameters must be only serialisable types. It means we can know at boot time rather than runtime that all types on the operations can only match objects that can be serialized / deserialized.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

馃挕 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 0993ab58ea

鈩癸笍 About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 馃憤.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

attr_reader :type

def ===(object)
Literal.subtype?(object, @type)

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Accept wrapped container types in kind matching

KindType#=== currently relies on Literal.subtype?(object, @type), but module-based subtyping only succeeds for a small subset of literal wrapper types (ConstraintType, IntersectionType, UnionType, NeverType). As a result, _Kind(Array) rejects _Array(Integer) (and similarly for other wrappers like _Hash), even though those types are semantically constrained to arrays. This makes higher-order constraints unexpectedly fail for common generic type arguments.

Useful? React with 馃憤聽/ 馃憥.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No it doesn't. Look at the implementation of Literal.subtype?

@joeldrapper
joeldrapper merged commit 68c5d58 into main Feb 20, 2026
17 checks passed
@fractaledmind
fractaledmind deleted the kinds branch February 20, 2026 15:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant