kosiew opened a new pull request, #19524:
URL: https://github.com/apache/datafusion/pull/19524
## Which issue does this PR close?
* Closes #18685.
---
## Rationale for this change
Function signatures in DataFusion currently define parameter
*types/coercions* and parameter *names* in separate places (e.g.
`TypeSignature::Coercible(...)` plus a later `.with_parameter_names(...)`).
This separation makes signatures harder to read and increases the risk of names
and types getting out of sync during maintenance.
This PR introduces an ergonomic builder API that lets authors define
parameter names together with their expected `DataType` or `Coercion` rules in
one place, improving readability and reducing duplication.
---
## What changes are included in this PR?
* Added a new helper enum `ParameterKind` to represent either:
* a concrete `DataType` (for `TypeSignature::Exact` and
`TypeSignature::Uniform`), or
* a `Coercion` rule (for `TypeSignature::Coercible`).
* Added `Signature::with_parameter(...)` and
`Signature::with_parameters(...)` builder methods to:
* store parameter names on the signature,
* validate arity consistently via existing validation,
* populate the underlying `TypeSignature` where applicable:
* `Exact`: fills/overwrites the type list (with arity checks when
already set)
* `Coercible`: fills/overwrites coercion rules (with arity checks when
already set)
* `Uniform`: validates that provided types are among the allowed types
and validates arity
* reject unsupported cases (e.g. variable arity signatures) via existing
validation.
* Refactored `unicode::substr` signature construction to use
`.with_parameters(&[...])`, co-locating parameter names with their coercion
rules.
* Added unit tests covering:
* `Exact`, `Coercible`, and `Uniform` usage
* mismatched arity errors
* duplicate parameter name validation
* variadic signature rejection
---
## Are these changes tested?
Yes.
* Added new unit tests in `signature.rs` validating correct behavior and
error cases for `with_parameters`.
* Existing tests continue to cover signature validation behavior, and the
`substr` refactor is a mechanical adoption of the new API.
---
## Are there any user-facing changes?
No user-facing behavior changes are intended.
This is a developer-facing refactor / ergonomics improvement for defining
function signatures. Function semantics and runtime behavior should remain the
same.
> Note: There is a small public API surface addition
(`Signature::with_parameter(s)` and `ParameterKind`). This should be
non-breaking and additive.
---
## LLM-generated code disclosure
This PR includes LLM-generated code and comments. All LLM-generated content
has been manually reviewed and tested.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
