# Is there already an auto-conversion macro for function signatures?

**URL:** <https://discourse.julialang.org/t/is-there-already-an-auto-conversion-macro-for-function-signatures/59320>\
**Category:** General Usage\
**Created:** [April 15, 2021, 9:05am UTC](https://discourse.julialang.org/t/is-there-already-an-auto-conversion-macro-for-function-signatures/59320 "2021-04-15T09:05:25Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://discourse.julialang.org/u/jules)\
**Post date:** [April 15, 2021, 9:05am UTC](https://discourse.julialang.org/t/is-there-already-an-auto-conversion-macro-for-function-signatures/59320/1 "2021-04-15T09:05:25Z")

</div>

I’ve thought about making a macro to auto-convert a more general type-signature to a specific one. Is there already something like this?

The reason is that often, a function realistically should only work for a couple of Float64 arguments, but users tend to pass whatever they have, like Ints, UInts, Rationals, etc. In order to reduce compilation time for each of those methods, it would be best to have a single one, and others that just convert to it.

Here’s how I envision it:

```julia
@autoconvert function expensive_to_compile(
        a::(Number -> Float64),
        b::(Number -> Float64),
        c::(Number -> Float64))

    # do a lot of stuff with a, b and c
end

```

This would expand to two definitions:

```julia
function expensive_to_compile(
    a::Float64,
    b::Float64,
    c::Float64)

    # do a lot of stuff with a, b and c
end

function expensive_to_compile(
    a::Number,
    b::Number,
    c::Number)

    expensive_to_compile(
        convert(Float64, a),
        convert(Float64, b),
        convert(Float64, c))
end

```

This is really meant for scenarios where there can’t possibly be a benefit from running the original types through the function as is. Like functions that call external libraries in between, that would convert anyway. It’s a bit like the default behavior of struct constructors.