Why aren't the input parameters const?

[iboB]

All inputs in the interface are pointers to non-const buffers. Why is that? Can the values be touched?

This makes it somewhat unpleasant to integrate in system where the buffers come from the outside world as const.

[DiamonDinoia]

Because of some legacy decisions in the early stages of development. We are moving to more standard compliant codebase, c++ friendly. PR #647 fixes it but we did not have time to review and integrate it yet. It will happen soon. Version 2.5 will have this. Minor versions before 2.5 (if any) might not.

[ahbarnett]

#647 is in master. Stay tuned for it to appear in 2.5.0 release.

[iboB]

It still doesn't affect plans. But yeah, it's hard with a C interface.

Here's what I've been using:

https://gist.github.com/iboB/787fd2154ef6f932df43401e087bf9f4

@DiamonDinoia would you be interested in a PR with an extension like this?

[DiamonDinoia]

In principle yes.
Having a nice c++ interface is something I am thinking about for a while.
I would suggest have a look at the discussion here: #623 and this commit: c813e3d

My idea is to provide a modern API (not just a patchwork to avoid const cast in c++). With a C++ API that resembles the python API.

I suggest. Why don't we write a mock API below and iterate a bit until we get something that we all (and the rest of the users) like?

I would like for example figure out the dim from the number of arguments. We can provide a span API that requires c++20 but this library is c++17 so we need to support pointer and size.

The alternative is to instead provide a c++20 API only that is only available if the users have a recent enough compiler or std::span available.

I cannot make such a decision by myself and quickly. The team has to agree because a public interface it hard to change once offered.

Cheers,
Marco

[DiamonDinoia]

Speculating, my idea is to have a nice C++ API, and a c API that wraps the c++ API.

[iboB]

A dynamic_extent span is trivial to implement. There's a bunch of C++11 compatible implementations out there including one of my own.

But I guess a question that you can pass to the team would be: It's 2025. Why not make this a C++20 library? The reality of having a huge cohort of C++ software enforcing ancient C++ standards is mostly gone. I myself have adopted a "next to latest" standard policy for my software and most professional teams have too.

Actually judging by the latest dev survey, "next to next to latest" would give you 94.5%, so it's not unreasonable to have 2026 as the year in which you switch to C++20 :)

[DiamonDinoia]

A dynamic_extent span is trivial to implement. There's a bunch of C++11 compatible implementations out there including one of my own.

Yes, but I do not think is finufft job to provide one. And pulling a dependency means forcing it to the users. I am against both.

But I guess a question that you can pass to the team would be: It's 2025. Why not make this a C++20 library? The reality of having a huge cohort of C++ software enforcing ancient C++ standards is mostly gone. I myself have adopted a "next to latest" standard policy for my software and most professional teams have too.
Actually judging by the latest dev survey, "next to next to latest" would give you 94.5%, so it's not unreasonable to have 2026 as the year in which you switch to C++20 :)

I would say that finufft is a mathematical software used by sucpercomputing centers that might not have access to newer compilers. We still have a significant portion of users that use the FORTRAN interface. I am not sure how applicable these dev stats are within our userbase. We upgraded from 11 to 17 last year and we have not seen backlash. But, what would be the point of upgrading to 20? Yes, there are a couple of features that might make the library a bit better but personally I do not feel we need c++20 features yet inside the codebase. We might internally use span/mdpsan via c++17 backports but I do not want to push c++20 to the users now.

We might so propose a c++20 interface that is optional but I still want plain c and FORTRAN users not to need c++20.

In any case, I will bring this up in our meetings. But I'm afraid that the c++ interface needs to wait for next year before any of us has time to work on it. Since it is public API, I'd like to err on the caution side instead of having to maintain a mess for years to come.