Jefffrey opened a new issue, #24135: URL: https://github.com/apache/datafusion/issues/24135
### Is your feature request related to a problem or challenge? https://github.com/apache/datafusion/blob/f27e50c13647efa5292d5ef5b1e4ed6af3015962/datafusion/expr-common/src/signature.rs#L1102-L1119 Example usages: https://github.com/apache/datafusion/blob/f27e50c13647efa5292d5ef5b1e4ed6af3015962/datafusion/functions/src/unicode/reverse.rs#L65-L69 https://github.com/apache/datafusion/blob/f27e50c13647efa5292d5ef5b1e4ed6af3015962/datafusion/functions-aggregate/src/approx_percentile_cont.rs#L142-L146 When `desired_type` is a `TypeSignatureClass::Native(_)`, its confusing to need to specify `default_casted_type` to be the same; we already know our desired native type. ### Describe the solution you'd like Perhaps a new API like ```rust pub fn new_implicit_native( desired_type: LogicalTypeRef, allowed_source_types: Vec<TypeSignatureClass>, ) -> Self { Self::new_implicit( TypeSignatureClass::Native(desired_type), allowed_source_types, desired_type.native().clone(), ) } ``` Then we could use it like ```rust Coercion::new_implicit_native( logical_string(), vec![TypeSignatureClass::Any], ) ``` And see where we can use this hopefully more intuitive API ### Describe alternatives you've considered Is there a better/cleaner way to handle this? Open to suggestions ### Additional context _No response_ -- 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]
