Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Const correctness #38

Open
encukou opened this issue May 22, 2023 · 5 comments
Open

Const correctness #38

encukou opened this issue May 22, 2023 · 5 comments
Labels
theme: the C language issues related to the way we use the C language

Comments

@encukou
Copy link
Contributor

encukou commented May 22, 2023

The C API almost never uses const, so it's usually simply unused in user code too.
Future/alternative implementations might need to modify refcounts (or similar) in arguments that are now const, and removing const from a signature is an API break.

Is it worth it to use const in new API?

See also: python/cpython#91768

@vstinner
Copy link
Contributor

vstinner commented Jun 8, 2023

Is it worth it to use const in new API?

I really tried to use const PyObject* on PyObject methods like Py_TYPE(), but I got multiple issues.

The const keyword is a good hint for developers about how the API should behave. But it doesn't provide better performance: https://theartofmachinery.com/2019/08/12/c_const_isnt_for_performance.html

I also wanted to use const PyConfig in PEP 587. It's appealing to have a C++-like "const" API to prevent users to mess up with data. Problem: I misunderstood what "const" means on a structure. For example, if a structure has a string PyConfig.prefix, you cannot override PyConfig.prefix = new_prefix, but you can modify the string PyConfig.prefix[0] = L'x';. The immutability is not "inherited" in types of structure members by writing const PyConfig. So I just gave up on that.

So far, in C, I was only convinced by const char*. This type is commonly used and has clear API advantages.

C++ has a way better API regarding to "const".

@gpshead
Copy link

gpshead commented Oct 26, 2023

Historical note: One of the largest pain points in making a huge codebase supporting Python 3.6 compatible with 3.7 prior to upgrading was that const was added to a variety of Python C API calls formerly accepting a char * that now demanded const char *. It made it impossible to write code that would compile correctly in C++ against both Python 3.6 and 3.7 without resorting to ugly C pre-processor checks of the Python version as to whether to declare something const or not... Propagating throughout potentially unrelated code as a const qualifier can be considered polluting.... add it somewhere and you need it everywhere else that data goes in the call stack.

So I'm not in favor of adding const to any existing C API. It's great when you get it right up front, but it is disruptive to add in the face of an existing codebase. I agree that I do not think most people actually understand what const actually does in C or in C++ (and those two are not the same IIRC... but our C API and .h files are included in C++...).

@vstinner
Copy link
Contributor

Is it worth it to use const in new API?

As I explained previously, I suggest to abandon this idea and close the issue.

@encukou
Copy link
Contributor Author

encukou commented Jun 11, 2024

So the decision for new API is to use const char* but no other const types?

@vstinner
Copy link
Contributor

So the decision for new API is to use const char* but no other const types?

In short yes, const char* is the only type in C where using const makes sense and is useful. Sadly, for other types, it's not convenient or doesn't really provide the expected benefits :-(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
theme: the C language issues related to the way we use the C language
Projects
None yet
Development

No branches or pull requests

4 participants