Way back in the MPI-2.2 timeframe, a proposal was introduced the add the C keyword “const” to all relevant MPI API parameters. The proposal was discussed at great length. The main idea was twofold:
- Provide a stronger semantic statement about which parameter contents MPI could change, and which it should not. This mainly applies to user choice buffers (e.g., the choice buffer argument in MPI_SEND).
- Be more friendly to languages that use const(-like constructs) more than C. The original proposal was actually from Microsoft, whose goal was to provide higher quality C# MPI bindings.
Additionally, the (not deprecated at the time) official MPI C++ bindings have had const since the mid-1990s — so why not include them in the C bindings?
The topic was… er… let’s say “vigorously”… debated. Many Forum members, including me, felt that changing tens of API functions to include const in their signatures — even though it was a relatively minor change that wouldn’t have broken an implementations ABI — was “too big” of a change for a point release (i.e., MPI-2.2). The proposal was eventually shot down with the strong guidance, “Let’s do this in MPI-3.”
The Forum recently passed an amended version of the const proposal in to MPI-3 with far less controversy than there was in MPI-2.2 (e.g., I voted against it in MPI-2.2, but voted for it in MPI-3).
An interesting point that came out in all the discussion was that many underlying network APIs do not mark writing/sending buffers as const in their signatures. As such, an MPI implementation will almost certainly have to cast away the const at some point. A high quality MPI implementation will preserve the const-ness of a buffer until it absolutely has to cast it away (i.e., when it hands the buffer off to the underlying network API). But a low quality MPI implementation can simply cast away the const right at the top-level MPI API function (e.g., MPI_SEND).
So if an MPI implementation can cast const away immediately, what’s the point?
The point is not about what the implementation does (in this case). It’s about the semantic promise that the MPI API is giving.
Regardless of what the implementation does, const provides a stronger statement about how the buffer is treated that is evident in the API, not buried deep in some standards text.