Integer conversions too pedantic in 64-bit

[foobar]

Steven Schveighoffer Wrote:

> On Tue, 15 Feb 2011 09:26:21 -0500, spir <denis.spir at gmail.com> wrote:
> 
> > On 02/15/2011 02:36 PM, Steven Schveighoffer wrote:
> 
> >>
> >> Hey, bikeshedders, I found this cool easter-egg feature in D! It's  
> >> called
> >> alias! Don't like the name of something? Well you can change it!
> >>
> >> alias size_t wordsize;
> >>
> >> Now, you can use wordsize instead of size_t in your code, and the  
> >> compiler
> >> doesn't care! (in fact, that's all size_t is anyways *hint hint*)
> >
> > Sure, but it's not the point of this one bikeshedding thread. If you do  
> > that, then you're the only one who knows what "wordsize" means. Good,  
> > maybe, for app-specific semantic notions (alias Employee[] Staff;);  
> > certainly not for types at the highest degree of general purpose like  
> > size_t. We need a standard alias.
> 
> The standard alias is size_t.  If you don't like it, alias it to something  
> else.  Why should I have to use something that's unfamiliar to me because  
> you don't like size_t?
> 
> I guarantee whatever you came up with would not be liked by some people,  
> so they would have to alias it, you can't please everyone.  size_t works,  
> it has a precedent, it's already *there*, just use it, or alias it if you  
> don't like it.
> 
> No offense, but this discussion is among the most pointless I've seen.
> 
> -Steve

I disagree that the discussion is pointless. 
On the contrary, the OP pointed out some valid points:

1.  that size_t is inconsistent with D's style guide. the "_t" suffix is a C++ convention and not a D one. While it makes sense for [former?] C++ programmers it will confuse newcomers to D from other languages that would expect the language to follow its own style guide. 
2. the proposed change is backwards compatible - the OP asked for an *additional* alias.
3. generic concepts should belong to the standard library and not user code which is also where size_t is already defined. 

IMO, we already have a byte type, it's plain common sense to extend this with a "native word" type.