The previous message does not address a couple of orthogonal issues. The first one seems simple, but I am unsure of the consequences of a change.
Currently, the 'stride' arguments are all size_t, and therefore unsigned. This seems odd, since it precludes the possibility of traversing vectors in reverse. Could all the strides be changed to signed quantities? As an aside, I will say that I really loathe unsigned types. They are almost useless. The common arguments for their use are spurious. I learned this many years ago, from painful experience, and from Lakos' book "Large-Scale C++ Software Design", where he advocates eliminating unsigned types from all interfaces. The second issue is big and painful. What do we do about the 'restrict' keyword? There is no doubt that 'restrict' helps in some situations. Sometimes it helps a lot. The 'restrict' keyword is technically a modifier of the same class as 'const'. So it multiplies the number of implied types in your head. Very nasty for interface explosion. One possibility is to bake-in the 'restrict' keyword to the container types. It could be turned off with a compile-time option. Of course, this requires that all GSL implementations be truly restrict-correct. But I am willing to guess that they are. When used in C++ code, the headers can test for an appropriate platform-dependent substitute, like '__restrict__' or '__restrict'. It would become part of the contract that clients should insure that their data segments do not overlap, just like when they choose to use memcpy(). Is this too much to ask? Be careful how you answer. For example, if you are using a drop-in replacement for matrix operations or linear algebra (any library other than libgslcblas), then you might already be subject to such a contract. The underlying implementation may well be written in Fortran. To understand aliasing problems and the motivation for 'restrict', I recommend reading Ulrich Drepper's series of articles, starting with part 5 if you are in a hurry: https://lwn.net/Articles/255364/ -- G. Jungman
