Integer conversions too pedantic in 64-bit

[Mafi]

Am 15.02.2011 22:49, schrieb Michel Fortin:
> On 2011-02-15 16:33:33 -0500, Walter Bright <newshound2 at digitalmars.com>
> said:
>
>> Nick Sabalausky wrote:
>>> "Walter Bright" <newshound2 at digitalmars.com> wrote in message
>>> news:ijeil4$2aso$3 at digitalmars.com...
>>>> spir wrote:
>>>>> Having to constantly explain that "_t" means type, that "size" does
>>>>> not mean size, what this type is supposed to mean instead, what it
>>>>> is used for in core and stdlib functionality, and what programmers
>>>>> are supposed to use it for... isn't this a waste of our time? This,
>>>>> only because the name is mindless?
>>>> No, because there is a vast body of work that uses size_t and a vast
>>>> body of programmers who know what it is and are totally used to it.
>>>
>>> And there's a vast body who don't.
>>>
>>> And there's a vast body who are used to C++, so let's just abandon D
>>> and make it an implementation of C++ instead.
>>
>> I would agree that D is a complete waste of time if all it consisted
>> of was renaming things.
>
> I'm just wondering whether 'size_t', because it is named after its C
> counterpart, doesn't feel too alien in D, causing people to prefer
> 'uint' or 'ulong' instead even when they should not. We're seeing a lot
> of code failing on 64-bit because authors used the fixed-size types
> which are more D-like in naming. Wouldn't more D-like names that don't
> look like relics from C -- something like 'word' and 'uword' -- have
> helped prevent those bugs by making the word-sized type look worth
> consideration?
>
I am also for renaming it. It should begin with u to ensure everybody 
knows it's unsigned even if there's no signed counterpart.

But what we definitely should avoid is to have two names for the same 
thing. It's the same mistake C++ did with inheriting everything from C 
and _adding_ it's own way.

Mafi