Skip to content

🎨 Allow extensions of services that aren't exported - #989

Merged
bdeane-intel merged 2 commits into
intel:mainfrom
elbeno:allow-extension-fail
Oct 21, 2026
Merged

bdeane-intel merged 2 commits into
intel:mainfrom
elbeno:allow-extension-fail

Conversation

@elbeno

@elbeno elbeno commented Oct 21, 2026

Copy link
Copy Markdown
Contributor

Problem:

  • It is sometimes useful to extend a service that isn't necessarily exported. e.g. the export might have a well-known name, but be controlled by generated configuration, and IFF the service is exported and called, another unrelated piece of code wants to hook in to it.

Solution:

  • Allow maybe_extend to express this use case.

Note:

  • The default is still to produce a compile-time error when extending services that aren't exported.

Problem:
- When extending a service by type, the type might have a name; this isn't used
  when issuing a diagnostic for trying to extend an unexported service.

Solution:
- If the extension type has a name, use it.
Problem:
- It is sometimes useful to extend a service that isn't necessarily exported.
  e.g. the export might have a well-known name, but be controlled by generated
  configuration, and IFF the service is exported and called, another unrelated
  piece of code wants to hook in to it.

Solution:
- Allow `maybe_extend` to express this use case.

Note:
- The default is still to produce a compile-time error when extending services
  that aren't exported.
Comment thread include/nexus/detail/extend.hpp Resolved
@bdeane-intel
bdeane-intel merged commit 7300c15 into intel:main Oct 21, 2026
28 checks passed
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.

3 participants