# Is it possible to splat into ccall?

**URL:** <https://discourse.julialang.org/t/is-it-possible-to-splat-into-ccall/95761>\
**Category:** General Usage\
**Tags:** ccall\
**Created:** [March 8, 2023, 7:49pm UTC](https://discourse.julialang.org/t/is-it-possible-to-splat-into-ccall/95761 "2023-03-08T19:49:46Z")\
**Posts on this page:** 1\
**Showing post:** 8

<div class="post-metadata">

**Author:** ![lmtzx9h4qqnt](https://avatars.discourse-cdn.com/v4/letter/l/74df32/32.png) [@lmtzx9h4qqnt](https://discourse.julialang.org/u/lmtzx9h4qqnt)\
**Post date:** [March 9, 2023, 9:15pm UTC](https://discourse.julialang.org/t/is-it-possible-to-splat-into-ccall/95761/8 "2023-03-09T21:15:21Z")

</div>

> [@Sukera](#):
>
> The error you see is a syntax error, because `ccall` needs special casing during parsing/lowering to be able to be passed through the compiler and handled as a foreign call, as well as for inserting the calls to `cconvert` and `unsafe_convert`.

This doesn’t seem to match with @c42f’s statement in the linked thread:

> [@Why is ccall syntax?](https://discourse.julialang.org/t/why-is-ccall-syntax/72427/3):
>
> #### The basic answer
> 
> It doesn’t need to be syntax. `@ccall` is a more recent and much more attractive syntax for the same thing which doesn’t need special support from the parser or lowering.

Not sure who’s right here? 😉

> [@Sukera](#):
>
> Since it fails at the syntax level, there is no later type based compiler magic you can do to fix this, you need to (at minimum) change how `ccall` is handled in parsing & lowering.

Yes, this is what I’m saying: This _shouldn’t_ fail at the syntax level. The length check should instead be done at compile- or runtime.

> [@Sukera](#):
>
> `@ccall` is the “escape hatch” that we use right now in lieu of modifying the parser to make `ccall` more special - not to mention that any change to the parser there needs to be backwards compatible with the existing syntax, as to not introduce a breaking change.

What I’m arguing for is making `ccall` _less_ special. Normal function calls in Julia don’t behave like this syntactically, and given that it looks the same, it would be better for `ccall` to behave as closely to a normal function call as possible.

> [@Sukera](#):
>
> The relevant Scheme code in the parser is [here](https://github.com/JuliaLang/julia/blob/f288f8886b34949a984c04feb606115904494d1f/src/julia-syntax.scm#L1095-L1128) and [here](https://github.com/JuliaLang/julia/blob/f288f8886b34949a984c04feb606115904494d1f/src/julia-syntax.scm#L2613-L2631). There is a mention of `...` in there, so it does already seem to be aware of varargs to some extent, but not so far as to allow splatting of arguments

The `...` in the code refers to specifying varargs in the type signature, as in

```julia
julia> ccall(:printf, Cint, (Cstring, Cint...), "%d %d %d\n", 1, 2, 3);
1 2 3

```

which is yet another special-case syntax that only exists within the context of `ccall`.

> [@Sukera](#):
>
> but not so far as to allow splatting of arguments (likely in part because we’d still need to know how many arguments we actually want to pass during link time, if I’m not mistaken)

I don’t know if “link time” refers to something else in the context of Julia, but in C, you can link to functions perfectly fine without even specifying any function signature. And of course, with varargs you’ll also never know how many arguments are going to be passed, and this number can change, too. So I’m not sure what the problem would be here.

> [@Sukera](#):
>
> This is something the `@generated` approach avoids via sleight of hand, by not splatting at runtime, but during compilation/parsing, when the `@generated` function is compiled for the passed in (known & fixed length) arguments.

And the result is a clearer, more consistent, and more flexible syntax, even within the constraints of the current implementation of `ccall`. Wouldn’t it be better if `ccall` worked like this?

---

_[View the full topic](https://discourse.julialang.org/t/is-it-possible-to-splat-into-ccall/95761)._