Skip to content

feat: searches nested modules for implicits#6084

Draft
christoph-dfinity wants to merge 2 commits into
masterfrom
christoph/nested-implicit-search
Draft

feat: searches nested modules for implicits#6084
christoph-dfinity wants to merge 2 commits into
masterfrom
christoph/nested-implicit-search

Conversation

@christoph-dfinity
Copy link
Copy Markdown
Contributor

@christoph-dfinity christoph-dfinity commented May 5, 2026

Motivation

This PR allows defining implicits in nested modules to allow library authors to define their own "type classes" without requiring an explicit import for every single instance.

It searches up to a depth of 8 (hardcoded for now) to avoid looping on recursive module type definitions.

Design considerations

As is, this PR is a breaking change, as it could theoretically change what existing code using implicits resolves to.

I've been thinking about adding implicit module definitions, that explicitly mark which modules are allowed to be recursively searched. They'd be semantically equivalent to NamedT("implicit", module { ...})

Compile performance wise we will search more modules for implicits then before, but nested modules are used rarely in Motoko at the moment. If this is a concern it could also be alleviated with the aforementioned implicit modules, as those would constrain the search space further.

TODO:

  • More tests
  • Update spec
  • Make maximum depth configurable?

@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented May 5, 2026

Comparing from 3c4fb6e to a85970d:
In terms of gas, no changes are observed in 5 tests.
In terms of size, no changes are observed in 5 tests.

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