Extend at-specialize to force specialization of arguments

[rfourquet]

A trick currently used in Base (and probably elsewhere) to force specialization on functions is to artificially declare a type parameter, e.g. foo(f::F) where F = f(1). I would bet that the majority of Julia users don't know about this and would look at this piece of code without any idea about the role of F, and would even fix what appears as a naive use of type parameters by simplifying it to foo(f) = f(1).
What about adding some explicit means to this end, for example reusing @specialize: foo(@specialize(f)) = f(1) ?
xref: #33917 (comment)

[cafaxo]

Since in foo(f::F) where F = f(1) the function f is called, it would be equivalent to foo(f) = f(1), right? Of course, for the other cases, it would be nice to have @specialize.

[rfourquet]

it would be equivalent to foo(f) = f(1), right?

I'm not the right person to answer, but this kind of prove the point that the exact rules are not obvious to everyone (talking of me!)

[cafaxo]

It is worth mentioning that #32817 added documentation on when a Function argument is specialized.
After thinking more about this, my opinion shifted somewhat: Having @specialize act in this way would not really clear up the confusion. The current syntax foo(f::F) where F is hacky, but so is overriding compiler heuristics. :)

[timholy]

But I do think the intent of @specialize(f) is much more transparent than f::F ... where F. For a person with just enough knowledge of Julia to be dangerous 😈, the latter might induce him/her to "clean up" and remove that little annotation. And since we currently don't have tests for such specializations, and don't make performance regressions a "fail," we don't catch those kinds of changes.

[rfourquet]

It is worth mentioning that #32817 added documentation on when a Function argument is specialized.

Nice, I was wondering whether it was documented somewhere, but got too lazy to check. Otherwise I agree with Tim, the current way to force specialization is too easy to miss out, and is brittle. Overrriding compiler heuristics might be hacky, but we all love to do it :D And @inline gets its own explicit name.

If you think @specialize is not the right word to clear up the confusion, would another name do it? @force_specialize ?

[c42f]

I agree we need a way to do this.

In the last year I've noticed people start to use the static parameter trick more often, and each time I have to ask the question

"Is foo(x::T) where {T} an attempt to force specialization, or an ugly way to get at typeof(x)?"

Furthermore, we're then forced to leave a comment that this is indeed to force specialization, lest someone clean up the code later.

To make matters worse, the specialization heuristics are somewhat subtle (and presumably subject to change) so I've seen people start to throw this in at the first sign of trouble in the hope that it will help.

[c42f]

So looking at the code which processes @specialize, it seems that the per-argument form is currently ignored, ie the following doesn't actually do anything:

function foo(@specialize(x))
     body
end

See

julia/src/method.c

Lines 554 to 558 in 52c55d7

	else if (nargs >= 1 && jl_exprarg(st, 0) == (jl_value_t*)specialize_sym) {
	if (nargs == 1) // bare `@specialize` is special: it causes specialization on all args
	m->nospecialize = 0;
	st = jl_nothing;
	}

So in principle we could steal @specialize(x) to mean "force specialize". However this form would be inconsistent with

function foo(x)
     @specialize
     body
end

which just resets the nospecialize flag for the method.

[adienes]

in another case of adding a feature because ChatGPT incorrectly thinks it exists, it seems that LLMs are very convinced that this is already what @specialize does. maybe this proposal should be revisited?

(I mean, besides appeasing the machine lords, I like the idea anyway)