Why is the restrict keyword not part of C++?

Question

The title says it all. I am curious why is the restrict keyword not part of C++ ? I don't know much about C++, and I'm still not able to find anything online that would give a reason blocking this. Does anyone know what terrible things would happen, if a C++ standard would use this keyword similarly to the way C does? Is it just not needed at all?

More explanation: It is not about using it, perhaps I will not have any benefit from this keyword in my whole life. This question is only about curiosity, since restrict is part of C since C99, that is 15 years.

Read this as well: I'm interested in technical reasons, not opinions like "They just didn't like, it is not cool enough"

Boorman

Note that at least MSVC, gcc and Intel's compiler support restrict (or variations, like __restrict) for c++, so in practice this is not that big a deal. – Johnettajohnette

This question asks for opinions about something that is not real problem, and therefore it's not an appropriate question for Stack Overflow. – Andrey

My guess: They just didn't like it and thought they had the perfect "sufficiently smart compiler" to figure it all out on its own. – Atheroma

@Andrey This question basically asks for technical reasons. I don't expect answers like "because restrict is stupid", I would like answers like "it conflicts with this and that". Should I modify the question according to this? – Densimeter

Buella, you may be interested in N3635 open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3635.pdf and other results of googling "site:www.open-std.org/jtc1/sc22/wg21/ restrict" – Stancil

@BuellaGábor Could you specify any references, or at least elaborate regarding restrict and c++? I don't get what's your question's all about ... – Globe

@πάνταῥεῖ en.wikipedia.org/wiki/Restrict – Densimeter

The question is probably more appropriate to programmers.stackexchange.com – Combatant

Answer 1

There are several issues in defining "restrict" in C++, some of them are listed in WG paper N3635: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3635.pdf "Towards restrict-like semantics for C++"

Some possible issues with restrict in C++ are:

• Restrict Class members and indirection with “this pointer”
• Passing of restrict qualifiers into functions, functors, lambdas, and templates
• Escaping of restrict pointer values inside functions
• Overlapping array members, strides

Document also list several C++ compilers with limited "restrict" support for C++.

There is also interesting history note in N3635 about non-inclusion of restrict to C++:

At the time of reviewing C99 feature inclusion in C++ during the Mont Tremblant meeting, restrict was considered but was waiting a paper proposal although none came forward....

Restrict is a C99 feature and was never designed to work in class abstractions and it may have to do with that pointers are not common in C++. ... it was designed for fine-grain aliasing for C, but not well-designed for type-based aliasing in C++

Stancil

Thanks, this paper is something I was looking for. I just had no idea I need to google site:www.open-std.org/jtc1/sc22/wg21/ restrict. Next time I will know.. – Densimeter

"Pointers not common in C++"? I wonder they got that notion... :-( – Ferroconcrete

I would be OK with the idea that restrict could only be applied to function argument pointers could only exist on the stack and could only refer to standard layout POD types. The that first ahem restriction is a novel category for C++, and the second category (standard layout POD) has generally not affected the ability to use language keywords. So, maybe my idea is a bad one. – Nelan

@Omnifarious: For C++, I think it might be better to have a "memory window" object type whose constructor would take a pointer,, and which would be used like a pointer, but with semantics that during the lifetime of the memory window, accesses made via the window or pointers that are definitely linearly derived therefrom would be unsequenced relative to accesses made via pointers that are definitely not linearly derived therefrom. Such an object could also allow a practical and convenient means of type punning if a pointer of one type could be used to form a window of another. – Frijol

@Omnifarious: A compiler would have to ensure that any pending operations on the original type that occurred before the constructor was run would be sequenced before any operations using the window, and any operations using the window would be sequenced before any operations on the original memory type that follow its destruction, but a compiler could be agnostic to the possibility of cross-type aliasing within the lifetime of the window provided those conditions were met. – Frijol

Answer 2

Not to detract from osgx's answer, but - there is a somewhat more up-to-date paper, N3998 by Finkel, Tong, Carrouth, Nelson Vandevoode and Wong, from May 2014:

Towards restrict-like aliasing semantics for C++

And an ever newer one from 2018:

[[assert: std::disjoint(A,nA, B,nB)]]: Contract assertions as an alternate spelling of ‘restrict’

(Thanks @MCCCS for pointing the last one out.)

Ferroconcrete

Answer 3

In addition to the discussions of the recent years listed in others' answers, the following is from The Design and Evolution of C++ by Bjarne Stroustrup that states the reason why restrict was rejected during standardization in the 1990s:

The C++ committee was naturally sympathetic to any proposal that improves efficiency and discussed the proposal at some length, but finally decided to reject it with hardly a dissenting voice. The key reasons for the rejection were:

1. The extension is not safe. Declaring a pointer restricted allows the compiler to assume that the pointer has no aliases. However, a user wouldn't necessarily be aware of this, and the compiler can't ensure it. Because of the extensive use of pointers and references in C++, more errors are likely to arise from this source than Fortran experience might suggest.

2. Alternatives to the extension have not been sufficiently explored. In many cases, alternatives such as an initial check for overlap combined with special code for non-overlapping arrays is an option. In other cases, direct calls to specialized math libraries, such as BLAS, can be used to tune vector operations for efficiency. Promising alternatives for optimization have yet to be explored. For example, global optimization of relatively small and stylized vector and matrix operations appears feasible and worthwhile for C++ compilers for high-performance machines.

3. The extension is architecture-specific. High-performance numerical computation is a specialized field using specialized techniques and often specialized hardware. Because of this, it may be more appropriate to introduce a non-standard architecture specific extension or pragma. Should the need for the utility of this kind of optimization prove useful beyond a narrow community using specialized machine architectures, the extension must be reevaluated.

One way of looking at this decision is as a reconfirmation of the idea that C++ supports abstraction through general mechanisms rather than specialized application areas through special-purpose mechanisms. ......

Inspector