Yeah, this seems like it’s true (difference in call_pow1 and call_pow2: Compiler Explorer)
But the rules change with argument dependent lookup, and we are leaning on a lot of use-before-defining behavior (a function in prim can call something in rev even though rev is declared after).
Like, when you call a function with a class argument, then the namespace attached to that class is searched (Argument-dependent lookup - cppreference.com). At least, I got this working with a templated function. Class argument to non-template function didn’t work.
This is a use-before-declaring situation: Compiler Explorer
And if you pull the var definition out of that namespace it breaks.
But I guess it’s still funky cause ADL doesn’t call the right pow there (it’ll call the C pow for the double).
This non-template version breaks: Compiler Explorer .
I think it’s because ADL rules change for templates (this still works): Compiler Explorer , but I don’t know.
So I agree it seems like something complicated is going on here.
From the Google Style guide:
or using-declarations (which we ban in header files except when the imported names are part of the interface exposed by the header file in question)
std::pow as the arithmetic implementations of stan::math::pow is what we want to expose, so technically seems fine, so we can squeeze through that with an exception lol.
The gnu standard libraries depend on this behavior. Search for ‘::pow’ in here (the cmath from my laptop): cmath.hpp (47.3 KB) . Bob and I were looking at this yesterday. We think it’s how they avoid ambiguities between the C pow and the C++ pow.
I guess this commentary doesn’t clarify much.
The general resistance makes me feel like, yeah, we probably shouldn’t do this. But I’m not totally convinced we aren’t leaning on similar functionality already lol. stan::math has a lot going on, but maybe that’s an argument to avoid yet-another-trick as well.
I’m kindof into using using std::pow as a stopgap and talking through this in the context of generated code for the next release, cause I feel like our problems stem from thinking about that.
It’s either that or find another stopgap. We’d need to find that stopgap quickly too, or we’ll need to take complex-funs out for the release, and I really don’t want Bob or anyone to have to maintain the complex-funs things separately from stan::math in a way that we can merge it whenever we figure this out. That was a bear for Bob to get in.