Skip to content

RFC 0000: resolve open questions on calling untyped R functions - #28

Merged
fabriceHategekimana merged 2 commits into
developfrom
rfc-0000-resolve-open-questions
Sep 12, 2026
Merged

fabriceHategekimana merged 2 commits into
developfrom
rfc-0000-resolve-open-questions

Conversation

@fabriceHategekimana

Copy link
Copy Markdown
Collaborator

Summary

rfcs/0000-calling-untyped-r-functions.md proposes making function(...) (and
untyped preloaded base-R builtins) callable, checked on arity only, returning
Any. It landed on develop directly rather than through the PR process
rfcs/README.md describes, and it still had three open questions blocking
acceptance. This PR resolves them against the actual compiler (0.5.12) so the
RFC can be reviewed and accepted or declined here, per that process.

  • Defaults and ...Lang::RFunction's parameters are parsed as bare
    names with an optional type annotation; there is no default-value syntax and
    no ... handling. function(a, b = 2) isn't parseable today, so arity
    checking is simply parameters.len() — no fallback case needed.
  • Any vs Foreign<Any> — settled on Any: Foreign<T> implies an
    accessor contract this RFC doesn't define, and an untyped call's result could
    be any R shape.
  • R { ... } blocks — out of scope. They already type-check as
    Type::Empty, not Type::Any, with more permissive unification rules;
    folding them into this RFC's Any/as! story would be a behavior change to
    existing code, not a footnote.

Test plan

  • Documentation-only change; no code, no tests to run.
  • Maintainer review of the resolved answers and a decision: rfc-accepted,
    rfc-draft (more to resolve), or rfc-rejected, per rfcs/README.md.

🤖 Generated with Claude Code

https://claude.ai/code/session_01ETPqhgWqDMt7UaUQXdxJmN

Grounds each in the current compiler (0.5.12) instead of leaving them
open: Lang::RFunction carries no default values or `...` handling
today (so arity checking is exactly parameters.len(), no fallback
needed), the untyped-call result stays Any rather than Foreign<Any>,
and R { ... } blocks are explicitly out of scope since they already
type-check as Type::Empty, not Type::Any, with different unification
rules.

Opens the RFC for the review this repo's rfcs/README.md describes —
it previously landed on develop without going through that process.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ETPqhgWqDMt7UaUQXdxJmN
Per rfcs/README.md: on acceptance the file is renamed to the PR's own
number and the header filled in. Tracking issue #29
opened for the implementation (J0 of registry.md's plan).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ETPqhgWqDMt7UaUQXdxJmN
@fabriceHategekimana fabriceHategekimana added the rfc-accepted RFC acceptée, fusionnée dans rfcs/ label Sep 12, 2026
@fabriceHategekimana
fabriceHategekimana merged commit e184721 into develop Sep 12, 2026
5 checks passed
@fabriceHategekimana
fabriceHategekimana deleted the rfc-0000-resolve-open-questions branch September 12, 2026 07:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

rfc-accepted RFC acceptée, fusionnée dans rfcs/

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant