Am 15.02.2011 22:49, schrieb Michel Fortin:
On 2011-02-15 16:33:33 -0500, Walter Bright <newshou...@digitalmars.com>
said:
Nick Sabalausky wrote:
"Walter Bright" <newshou...@digitalmars.com> wrote in message
news:ijeil4$2aso$3...@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
