"Walter Bright" <newshound2@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.

Am 15.02.2011 22:20, schrieb Nick Sabalausky:
> "Walter Bright" <newshound2@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.
> 

They've got to learn some name for it anyway, so why not size_t? This also makes using C functions that use size_t easier/more clear.

> 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.
> 

Am 15.02.2011 19:10, schrieb bearophile:
> Daniel Gibson:
> 
>> void main() {
>>    size_t x;
>>    writefln(typeof(x).stringof);
>> }
>> try this, too ;-)
>>
>> Because it's an alias the information about size_t gone at runtime and the "real" type is shown. uint in your case. (Here - gdc on amd64 - it's ulong).
> 
> I think both typeof() and stringof are compile-time things.
> 
> And regarding lost alias information I suggest to do as Clang does: http://d.puremagic.com/issues/show_bug.cgi?id=5004
> 
> Bye,
> bearophile

Hmm yeah, you're probably right. After sending my reply I thought about that myself. However: At the time typeof() is handled by the compiler the aliases are already resolved.

I agree that "aka" for alias information in error-messages would be helpful in general, but this wouldn't help here.

Nick Sabalausky wrote:
> "Walter Bright" <newshound2@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.

Am 15.02.2011 20:15, schrieb Rainer Schuetze:
> 
> I think David has raised a good point here that seems to have been lost in the discussion about naming.
> 
> Please note that the C name of the machine word integer was usually called "int". The C standard only specifies a minimum bit-size for the different types (see for example http://www.ericgiguere.com/articles/ansi-c-summary.html). Most of current C++ implementations have identical "int" sizes, but now "long" is different. This approach has failed and has caused many headaches when porting software from one platform to another. D has recognized this and has explicitely defined the bit-size of the various integer types. That's good!
> 
> Now, with size_t the distinction between platforms creeps back into the language. It is everywhere across phobos, be it as length of ranges or size of containers. This can get viral, as everything that gets in touch with these values might have to stick to size_t. Is this really desired?
> 
> Consider saving an array to disk, trying to read it on another platform. How many bits should be written for the size of that array?
> 

This can indeed be a problem which actually is existent in Phobos: std.streams Outputstream has a write(char[]) method - and similar methods for wchar and dchar - that do exactly this: write a size_t first and then the data.. in many places they used uint instead of size_t, but at the one method where this is a bad idea they used size_t ;-) (see also http://d.puremagic.com/issues/show_bug.cgi?id=5001 )

In general I think that you just have to define how you serialize data to disk/net/whatever (what endianess, what exact types) and you won't have problems. Just dumping the data to disk isn't portable anyway.

> Consider a range that maps the contents of a file. The file can be larger than 4GB, though a lot of the ranges that wrap the file mapping range will truncate the length to 32 bit on 32-bit platforms.
> 
> I don't have a perfect solution, but maybe builtin arrays could be limited to 2^^32-1 elements (or maybe 2^^31-1 to get rid of endless signed/unsigned conversions), so the normal type to be used is still "int". Ranges should adopt the type sizes of the underlying objects.
> 
> Agreed, a type for the machine word integer must exist, and I don't care how it is called, but I would like to see its usage restricted to rare cases.
> 
> Rainer
> 

Cheers,
- Daniel

"Adam Ruppe" <destructionator@gmail.com> wrote in message news:ije0gi$18vo$1@digitalmars.com...
> Sometimes I think we should troll the users a little and make a release with names like so:
>
> alias size_t TypeUsedForArraySizes_Indexes_AndOtherRelatedTasksThatNeedAnUnsignedMachineSizeWord;
>
> alias ptrdiff_t TypeUsedForDifferencesBetweenPointers_ThatIs_ASignedMachineSizeWordAlsoUsableForOffsets;
>
> alias iota lazyRangeThatGoesFromStartToFinishByTheGivenStepAmount;
>
>
> Cash money says everyone would be demanding an emergency release with shorter names. We'd argue for months about it... and probably settle back where we started.

A small software company I once worked for, Main Sequence Technologies, had their heads so far up their asses it was trivial for me to get posted on TheDailyWTF's Code Snippet of the Day (This company had a rather...interesting...way of creating their "else" clauses).

One of the many "Programming 101, Chapter 1" things they had a habit of screwing up was "Use meaningful variable names!". Throughout the codebase (VB6 - yea, that tells you a lot about their level of competence), there were variables like "aaa", "staaa", "bbb", "stbbb", "ccc", etc. Those are actual names they used. (I even found a file-loading function named "save".)

Needless to say, trying to understand the twisted codebase enough to actually do anything with it was...well, you can imagine. So I would try to clean things up when I could, in large part just so I could actually keep it all straight in my own mind.

Anyway, to bring this all back around to what you said above, there were times when I understood enough about a variable to know it wasn't relevant to whatever my main task was, and therefore didn't strictly need to go wasting even *more* time trying to figure out what the hell the variable actually did. So I ended up in the habit of just renaming those variables to things like:

bbb
->
thisVariableNeedsAMuchMoreMeaningfulNameThan_bbb

That was satisfying ;)

Call it "self-documenting code".

"Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message news:op.vqx78nkceav7ka@steve-laptop...
>
> size_t works,  it has a precedent, it's already *there*, just use it, or alias it if you  don't like it.
>

One could make much the same argument about the whole of C++. It works, it has a precedent, it's already *there*, just use it.

Am 15.02.2011 22:48, schrieb Nick Sabalausky:
> "Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message news:op.vqx78nkceav7ka@steve-laptop...
>>
>> size_t works,  it has a precedent, it's already *there*, just use it, or alias it if you  don't like it.
>>
> 
> One could make much the same argument about the whole of C++. It works, it has a precedent, it's already *there*, just use it.
> 

If your only problem with C++ is related to names.. you should probably do that.

"Nick Sabalausky" <a@a.a> wrote in message news:ijesem$brd$1@digitalmars.com...
> "Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message news:op.vqx78nkceav7ka@steve-laptop...
>>
>> size_t works,  it has a precedent, it's already *there*, just use it, or alias it if you  don't like it.
>>
>
> One could make much the same argument about the whole of C++. It works, it has a precedent, it's already *there*, just use it.
>

The whole reason I came to D was because, at the time, D was more interested in fixing C++'s idiocy than just merely aping C++ as the theme seems to be now.

On 2011-02-15 16:33:33 -0500, Walter Bright <newshound2@digitalmars.com> said:

> Nick Sabalausky wrote:
>> "Walter Bright" <newshound2@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?

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/