# Function signature with vector types

**URL:** <https://discourse.julialang.org/t/function-signature-with-vector-types/131704>\
**Category:** New to Julia\
**Created:** [August 19, 2025, 11:11am UTC](https://discourse.julialang.org/t/function-signature-with-vector-types/131704 "2025-08-19T11:11:31Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Mastomaki](https://avatars.discourse-cdn.com/v4/letter/m/779978/32.png) [@Mastomaki](https://discourse.julialang.org/u/Mastomaki)\
**Post date:** [August 19, 2025, 11:11am UTC](https://discourse.julialang.org/t/function-signature-with-vector-types/131704/1 "2025-08-19T11:11:31Z")

</div>

Suppose I have a function which plots timeseries stored in [TSFrames.jl](https://xkdr.github.io/TSFrames.jl/stable/user_guide/#Installation) TSFrames.

`plot_multirowts(x::Vector{TSFrame}}, seriesnames::Vector{String})`

Sometimes, such as when subsetting dataframes, my data will have type Vector{Any}. The function does not work with such input. Should I

1. convert the input data to Vector{TSFrame}} or
2. use the Vector{Any} type in the function definition, although in this case the user does not know what type of data the function will accept?

---

<div class="post-metadata">

**Author:** ![Sevi](https://avatars.discourse-cdn.com/v4/letter/s/c67d28/32.png) [@Sevi](https://discourse.julialang.org/u/Sevi)\
**Post date:** [August 19, 2025, 11:18am UTC](https://discourse.julialang.org/t/function-signature-with-vector-types/131704/2 "2025-08-19T11:18:18Z")

</div>

Just writing `Vector` works, but unless you need to use dispatch to make specific methods of `plot_multirowts` that deal with specific kinds of input in different ways, the “most Julian” way of doing this is, I think,

- don’t use any types in the function signature, just `plot_multirowts(x, seriesnames)`
- document your function with a docstring and write tests, indicating what types you function will accept
- (perhaps) assert/check that the element type can actually be used within the function, e.g. printing a more expicit error message than some `MethodError` down the line

Besides the unnecessary restriction that you already encountered, another advantage of removing the type annotation here is that it doesn’t exclude other types that might or might not work with your code (this can also be a downside, depends on the situation really).