Skip to content

Generic actual inference - #243

Open
QuentinOchem wants to merge 2 commits into
masterfrom
generic_actual_inference
Open

Generic actual inference#243
QuentinOchem wants to merge 2 commits into
masterfrom
generic_actual_inference

Conversation

@QuentinOchem

Copy link
Copy Markdown
Contributor

No description provided.

@QuentinOchem
QuentinOchem force-pushed the generic_actual_inference branch from de1e604 to 2aa4834 Compare August 13, 2026 20:59
* The `"<"` is deduced as per pre-existing instantiation rules.


Inference through generic packages

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This RFC is fundamentally a name-resolution change, so could you specify precisely how inference composes with overload resolution: in what order they run, which entities participate, and exactly which cases are considered ambiguous and rejected.

That precision matters for cost too: implementing this will be significant work in both GNAT and Libadalang, and their resolvers can only do it against well-defined name-resolution rules.

@sttaft

sttaft commented Aug 25, 2026

Copy link
Copy Markdown
Contributor

In the Prior Art section, you might want to talk about other languages that have done something similar. I asked Google: "What languages support implicit instantiation as part of function call" and here is the response:

Programming languages that use generics or templates and perform type inference during a regular function call support implicit instantiation (automatically generating a specialized function for specific types based on the arguments provided). [1, 2]

Languages with Implicit Instantiation on Function Calls

  • C++: The classic example. When you call a C++ Function Template with concrete arguments (e.g., max(1, 2)), the compiler implicitly instantiates the matching specialization (max). [1, 2]
  • Rust: Generic functions are implicitly instantiated (monomorphized) by the compiler when invoked with specific concrete types without requiring manual type parameters in the call syntax (e.g., some_function(5)infers ).
  • Swift: Uses generic functions where type parameters are implicitly deduced from function call arguments.
  • D: Supports function templates that implicitly instantiate based on the types of arguments passed during a call.
  • Scala (with generics/polymorphic methods): Type parameters on methods are inferred implicitly at the call site.

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