The lapack_lite files are generated, you should leave them alone if possible, otherwise generate a patch to apply the differences.

I don't know if this will cause problems or not, the complex types were late to arrive in C and there might be some compatibility problems.

The lapack_lite files are generated, you should leave them alone if possible, otherwise generate a patch to apply the differences.

Thanks a lot for the pointers! Unfortunately, the generated files will need to change, since complex is a reserved keyword now by importing complex.h. I figured I'd need to change the patch files, but I still opened this, mostly for the CI to run. As soon as I've got everything working, I'll revert the changes to the f2c'd files and patch them instead.

I don't know if this will cause problems or not, the complex types were late to arrive in C and there might be some compatibility problems.

Yeah, this has been mostly about checking whether everything would work fine. I guess there's no better way than to do the work.

I wish we could swap in std::complex, unless MSVC thwarts that

You hit the nail on the head. MSVC made this PR so much harder than it should have been.

Yeah, but unlike C99 support, I think the C++ std::complex class exists? Although maybe it is newer. But making the C++ code nicer probably requires getting rid of those tags (i.e. using C++17 features that were avoided when it was written).

Yeah, but unlike C99 support, I think the C++ std::complex class exists?

It does exist, but it makes using these types more complicated, since std::complex is a template and we need to mix C++/C linkage.

CI failures appear to be unrelated, so, someone, please restart the two failing jobs. 🙏

Failures were down to one, and I restarted that last one now. If it fails again, please simply ignore it.

Thanks @lysnikolaou

A few follow-ups we might want to look into:

• This still needs a release note pointing to the compat header, or nobody will find it :). (i.e. to say what changed and what new API exists)
• The Cython definitions are still based on the struct. I am not quite sure if we want to change it. The definitions are easy to avoid and losing .real and .imag might be annoying, while npymath isn't even easily available.

Is there anything else to think about?

This still needs a release note pointing to the compat header, or nobody will find it :). (i.e. to say what changed and what new API exists)

I can do this in a new PR, if that's okay. It'll be my first time writing anything more than a one-liner for a release note though, so it's okay if someone else wants to take this.

The Cython definitions are still based on the struct. I am not quite sure if we want to change it. The definitions are easy to avoid and losing .real and .imag might be annoying, while npymath isn't even easily available.

Agreed that it's okay to leave as-is for now. Cython's handling of complex's is a bit complicated as well because of the MSVC issues, so it might make things harder to reason about.

Is there anything else to think about?

We could write a few words in the NumPy core math library section of the docs about complex handling as well, although I guess that wouldn't be a priority. Also, I'm already working on removing as much of the complex compat layer in npy_math as possible. We'll have to see how much we can strip it down.

I can do this in a new PR, if that's okay. It'll be my first time writing anything more than a one-liner for a release note though, so it's okay if someone else wants to take this.

Sounds like a good exercise to me:) Describing the reason for the change and how to adapt to it is the main thing, which I think is easiest for you to do. We can help tweak so it fits with the other release notes if needed. Given that this is causing a fair amount of breakage (at least SciPy, pandas, and h5py I've seen), it'd be nice to get this drafted.

Sounds good! I'll get started on this tomorrow.