I would suggest that you implement it in whichever form is best (performant, simple, whatever) for the package and then just provide a few different methods
somefunction(coords)
somefunction(xs, ys)
If performance is important perhaps document which is the most performant method.
I would give the opposite advice. Just pick one, and make that the only interface. People that want to use or integrate your package into a wider piece of software can handle the translation.
The most natural here is to take an AbstractVector of tuples (or svectors). Then, if your algorithm is natively working with a vector of tuples – then use it as-is. If it’s most efficient with two separate vectors – convert all abstractvectors to StructArray.
This way, both you and users only care about one input “type”, limiting potential confusion.
Thank you to all of you for your relevant remarks! Does that mean one could provide a PR to improve Concorde.jl on that point? I believe they did not mean to provide a 2D-Grid but points instead.
I would go with two distinct vectors if it is reasonable to expect that the user will frequently have the data already in this format, and no unnecessary copy is needed. It is what is often done in mathematical programming.
StructArrays is great for this usecase: no copy is needed, just do StructArray(; x, y) where x and y are your vectors. And you get all benefits, like ensuring consistent axes, convenient access to elements, and uniform familiar array interface.