restrict sucks

[Janice Caron]

In the world of C99, a new monster has started to rear its ugly head - the
keyword "restrict".

The idea is that in a conventional function, declared

 void f(int *p, int *q);

the data pointed to by p /might/ overlap the data pointed to by q, wheras,
if the function were declared as one of:

 void f(int * restrict p, int *q);
 void f(int *p, int * restrict q);
 void f(int * restrict p, int * restrict q);

then the data pointed to by p and q may /not/ overlap. The idea behind this
is that the compiler can make better optimizations if it knows that. The
problem is that now, in addition to const-correctness and
volatile-correctness, you've now also got restrict-correctness to worry
about. All your library function prototypes now need to change - strcpy(),
strcat(), memcpy() (but not memmove()) just for starters!

The thing is, the /intent/ is well-meaning. It's the implementation that's
attrocious.

One day, someone's going to suggest this for D. So, now that we've got the
const debate going in another thread, let's get this over with now, while
the const debate is still fermenting.

Here's what I suggest. First, restrict shall be assumed by default!

 void f(int p[], int q[])
 {
     /* compiler may assume that no pointers passed as function parameters
overlap */
 }

If you want overlapping pointers, you must instead do this:

 void overlap f(int p[], int q[])
 {
     /* compiler must assume that all pointers passed as function parameters
may overlap */
 }

Yes, you lose some granularity. And yes, some existing code will develop
undefined behavior until their prototypes are fixed. But /most/ functions
won't need "norestrict", and so fixing those that do is likely to be the
least-work option.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20070911/38cbc346/attachment.html>