size_t, size_t, wherefore art thou aliased?

[Gregor Richards]

(For the early-modern-English-impaired, "wherefore art thou aliased" 
means "why are you aliased")

In the process of porting GDC to x86_64 (which has actually been 
somewhat successful, but more on that later), I've discovered what I 
consider to be a fairly significant problem.

Because size_t is aliased (and also partially because DDoc follows 
aliases apparently), there is a tendency to use uint instead of size_t, 
and no error or even feedback if you do!

For example, std.socketstream overrides:

size_t readBlock(void* _buffer, size_t size)

with

uint readBlock(void* _buffer, uint size)

Ouch!  Works fine on 32-bit systems, but totally fails on 64-bit 
systems, and the writer has no way of knowing there's a bug until he 
tries to compile it on a 64-bit system!  The biggest problem here is 
with overriding (as in the above example), where it'll override properly 
on 32-bit but improperly on 64-bit systems.

The folks on #d and I have created several possible solutions.

Our original thought was to make size_t (and ptrdiff_t) typedefs instead 
of aliases - this would at least require no change to the language 
proper.  Unfortunately, this makes assigning values to size_t and 
ptrdiff_t obnoxious, since it only implicitly casts one way (not the way 
that's helpful here).

Secondly, size_t and ptrdiff_t could be compiler-defined types, rather 
than aliased types.  This would make the implicit casting come out 
right, but is sort of ugly.

Finally, the preferred option seems to be a sort of weak typedef. 
Basically, this would be a typedef, but with implicit casting both ways. 
  So, [u]ints, [u]longs, size_ts and ptrdiff_ts would all play nicely 
together, but overrides would not be happy if improperly defined.

The most unfortunate thing about this is that there's virtually no way 
for a programmer on a 32-bit system to know when they've ran into a bug 
like this.  Yuck.

  - Gregor Richards