Andrej Mitrovic wrote:
> The question is then do you want to be more consistent with the
> language (abolish size_t and make something nicer), or be consistent
> with the known standards (C99 ISO, et all.).
> 
> I'd vote for a change, but I know it will never happen (even though it
> just might not be too late if we're not coding for 64 bits yet). It's
> hardcoded in the skin of C++ programmers, and Walter is at least one
> of them.

We also don't go around renaming should to shud, or use dvorak keyboards.

Having to constantly explain that "use 'ourfancyname' instead of size_t, it works exactly the same as size_t" is a waste of our time and potential users' time.

On 2011-02-15 01:08, Walter Bright wrote:
> dsimcha wrote:
>> Now that DMD has a 64-bit beta available, I'm working on getting a
>> whole bunch
>> of code to compile in 64 mode. Frankly, the compiler is way too freakin'
>> pedantic when it comes to implicit conversions (or lack thereof) of
>> array.length. 99.999% of the time it's safe to assume an array is not
>> going
>> to be over 4 billion elements long. I'd rather have a bug the 0.001%
>> of the
>> time than deal with the pedantic errors the rest of the time, because
>> I think
>> it would be less total time and effort invested. To force me to either
>> put
>> casts in my code everywhere or change my entire codebase to use wider
>> integers
>> (with ripple effects just about everywhere) strikes me as purity
>> winning out
>> over practicality.
>
> We dealt with that in updating Phobos/Druntime to 64 bits. The end
> result was worth it (and yes, there would have been undiscovered bugs
> without those pedantic checks).
>
> Most of the issues are solved if you use auto and foreach where
> possible, and size_t for the rest of the cases.

Yes, exactly, what's the reason not to use size_t. I've used size_t for length and index in arrays for as long as I've been using D.

-- 
/Jacob Carlborg

On 02/15/2011 02:28 AM, Jonathan M Davis wrote:
> On Monday, February 14, 2011 17:06:43 spir wrote:
>> On 02/15/2011 01:56 AM, Jonathan M Davis wrote:
>>> On Monday, February 14, 2011 16:30:09 Andrej Mitrovic wrote:
>>>> Here's something I've noticed (x86 code):
>>>>
>>>> void main()
>>>> {
>>>>
>>>>       ulong size = 2;
>>>>       int[] arr = new int[](size);
>>>>
>>>> }
>>>>
>>>> This will error with:
>>>> sizetTest.d(8): Error: cannot implicitly convert expression (size) of
>>>> type ulong to uint
>>>>
>>>> size_t is aliased to uint since I'm running 32bit.
>>>>
>>>> I'm really not experienced at all with 64bit, so I don't know if it's
>>>> good to use uint explicitly (my hunch is that it's not good). uint as
>>>> the array size wouldn't even compile in 64bit, right?
>>>>
>>>> If I'm correct, wouldn't it be better if the error showed that it
>>>> expects size_t which might be aliased to whatever type for a
>>>> particular machine?
>>>
>>> Use size_t. It's the type which is used. It's aliased to whichever type
>>> is appropriate for the architecture. On 32 bits, that would be a 32 bit
>>> integer, so it's uint. On 64 bits, that would be a 64 bit integer, so
>>> it's ulong.
>>
>> Rename size-t, or rather introduce a meaningful standard alias? (would vote
>> for Natural)
>
> Why? size_t is what's used in C++. It's well known and what lots of programmers
> would expect What would you gain by renaming it?

Then state on D's front page:
   "D is a language for C++ programmers..."

"size"_t is wrong, wrong, wrong:
* Nothing says it's a type alias (should be "Size").
* The name's "morphology" is weird.
* It does not even tell about semantics & usage: a majority of use cases is probably as indices! (ordinal, not cardinal as suggested by the name). ("sizediff_t" also exists, but seems unused in D)

"Natural" would be good according to all those points: the name tells it's unsigned, a natural number is either an ordinal or a cardinal, and it fits D style guidelines. Better proposals welcome :-)

Aliasing does /not/ mean removing size_t, just proposing a correct, sensible, and meaningful alternative. If people like it, and if using the correct name is encouraged, then after a few years the legacy garbage can endly be recycled ;-)
In any case, this alternative must be *standard*, for the whole community to know it. I have used Ordinal & Cardinal for a while, but stopped because of that: people reading my code had to guess a bit (not that hard, but still), or jump to declarations.

Again: size_t is /wrong/. The fact that for you it means what it means, due to your experience as C++ programmer, does not change a iota (lol!) to its wrongness. If we never improve languages just because of mindless conservatism, then in 3 generations programmers will still be stuck with junk from the 1970's.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On 02/15/2011 02:55 AM, Nick Sabalausky wrote:
> "Nick Sabalausky"<a@a.a>  wrote in message
> news:ijcm8d$1lf5$1@digitalmars.com...
>> "spir"<denis.spir@gmail.com>  wrote in message
>> news:mailman.1648.1297732015.4748.digitalmars-d@puremagic.com...
>>>
>>> Rename size-t, or rather introduce a meaningful standard alias? (would
>>> vote for Natural)
>>>
>>
>> My bikeshed is painted "native" and "word" :)
>>
>
> ...With some "wordsize" around the trim.

Not bad, but how does "wordsize" tell about usage (ordinal=index/position, cardinal=count/length) and semantics (unsigned)?
"uint" is rather good; actually means about the same as "natural" for me. But it's a bit cryptic and does not adapt to platform native word size, unfortunately. I use uint for now to avoid custom, but correct & meaningful, alias(es) for size_t. (I must have a blockage with using mindless terms like "size_t" ;-)


denis
-- 
_________________
vita es estrany
spir.wikidot.com

On 02/15/2011 02:28 AM, Jonathan M Davis wrote:
> On Monday, February 14, 2011 17:06:43 spir wrote:
>> On 02/15/2011 01:56 AM, Jonathan M Davis wrote:
>>> On Monday, February 14, 2011 16:30:09 Andrej Mitrovic wrote:
>>>> Here's something I've noticed (x86 code):
>>>>
>>>> void main()
>>>> {
>>>>
>>>>       ulong size = 2;
>>>>       int[] arr = new int[](size);
>>>>
>>>> }
>>>>
>>>> This will error with:
>>>> sizetTest.d(8): Error: cannot implicitly convert expression (size) of
>>>> type ulong to uint
>>>>
>>>> size_t is aliased to uint since I'm running 32bit.
>>>>
>>>> I'm really not experienced at all with 64bit, so I don't know if it's
>>>> good to use uint explicitly (my hunch is that it's not good). uint as
>>>> the array size wouldn't even compile in 64bit, right?
>>>>
>>>> If I'm correct, wouldn't it be better if the error showed that it
>>>> expects size_t which might be aliased to whatever type for a
>>>> particular machine?
>>>
>>> Use size_t. It's the type which is used. It's aliased to whichever type
>>> is appropriate for the architecture. On 32 bits, that would be a 32 bit
>>> integer, so it's uint. On 64 bits, that would be a 64 bit integer, so
>>> it's ulong.
>>
>> Rename size-t, or rather introduce a meaningful standard alias? (would vote
>> for Natural)
>
> Why? size_t is what's used in C++. It's well known and what lots of programmers
> would expect What would you gain by renaming it?

Then state on D's front page:
   "D is a language for C++ programmers..."

"size"_t is wrong, wrong, wrong:
* Nothing says it's a type alias (should be "Size").
* The name's "morphology" is weird.
* It does not even tell about semantics & usage: a majority of use cases is probably as indices! (ordinal, not cardinal as suggested by the name). ("sizediff_t" also exists, but seems unused in D)

"Natural" would be good according to all those points: the name tells it's unsigned, a natural number is either an ordinal or a cardinal, and it fits D style guidelines. Better proposals welcome :-)

Aliasing does /not/ mean removing size_t, just proposing a correct, sensible, and meaningful alternative. If people like it, and if using the correct name is encouraged, then after a few years the legacy garbage can endly be recycled ;-)
In any case, this alternative must be *standard*, for the whole community to know it. I have used Ordinal & Cardinal for a while, but stopped because of that: people reading my code had to guess a bit (not that hard, but still), or jump to declarations.

Again: size_t is /wrong/. The fact that for you it means what it means, due to your experience as C++ programmer, does not change a iota (lol!) to its wrongness. If we never improve languages just because of mindless conservatism, then in 3 generations programmers will still be stuck with junk from the 1970's.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On 02/15/2011 02:58 AM, Nick Sabalausky wrote:
> "Jonathan M Davis"<jmdavisProg@gmx.com>  wrote in message
> news:mailman.1650.1297733226.4748.digitalmars-d@puremagic.com...
>> On Monday, February 14, 2011 17:06:43 spir wrote:
>>>
>>> Rename size-t, or rather introduce a meaningful standard alias? (would
>>> vote
>>> for Natural)
>>
>> Why? size_t is what's used in C++. It's well known and what lots of
>> programmers
>> would expect What would you gain by renaming it?
>>
>
> Although I fully realize how much this sounds like making a big deal out of
> nothing, to me, using "size_t" has always felt really clumsy and awkward. I
> think it's partly because of using an underscore in such an otherwise short
> identifier, and partly because I've been aware of size_t for years and still
> don't have the slightest clue WTF that "t" means. Something like "wordsize"
> would make a lot more sense and frankly feel much nicer.
>
> And, of course, there's a lot of well-known things in C++ that D
> deliberately destroys. D is a different language, it may as well do things
> better.

Agreed. While making something different...
About the suffix "-_t", I bet it means type, what do you think? (may well be wrong, just because I have here and there seen custom types like name_t or point_t or such) Anyone has a history of C/++ at hand?

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On 02/15/2011 03:11 AM, Don wrote:
> Nick Sabalausky wrote:
>> "Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message
>> news:mailman.1650.1297733226.4748.digitalmars-d@puremagic.com...
>>> On Monday, February 14, 2011 17:06:43 spir wrote:
>>>> Rename size-t, or rather introduce a meaningful standard alias? (would vote
>>>> for Natural)
>>> Why? size_t is what's used in C++. It's well known and what lots of programmers
>>> would expect What would you gain by renaming it?
>>>
>>
>> Although I fully realize how much this sounds like making a big deal out of
>> nothing, to me, using "size_t" has always felt really clumsy and awkward. I
>> think it's partly because of using an underscore in such an otherwise short
>> identifier, and partly because I've been aware of size_t for years and still
>> don't have the slightest clue WTF that "t" means. Something like "wordsize"
>> would make a lot more sense and frankly feel much nicer.
>>
>> And, of course, there's a lot of well-known things in C++ that D deliberately
>> destroys. D is a different language, it may as well do things better.
>
> To my mind, a bigger problem is that size_t is WRONG. It should be an integer.
> NOT unsigned.

That would /also/ solve dark corner issue & bugs. Let us define a standard alias to be used for indices, length, and such, and take the opportunity to give it a meaningful name. Then let core and lib functions to expect & return integer's. But this is a hard path, don't you think?

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On 02/15/2011 03:26 AM, Jonathan M Davis wrote:
> On Monday, February 14, 2011 18:19:35 Nick Sabalausky wrote:
>> "Jonathan M Davis"<jmdavisProg@gmx.com>  wrote in message
>> news:mailman.1655.1297736016.4748.digitalmars-d@puremagic.com...
>>
>>> I believe that t is for type. The same goes for types such as time_t. The
>>> size
>>> part of the name is probably meant to be short for either word size or
>>> pointer
>>> size.
>>>
>>> Personally, I see nothing wrong with size_t and see no reason to change
>>> it. If
>>> it were a particularly bad name and there was a good suggestion for a
>>> replacement, then perhaps I'd support changing it. But I see nothing
>>> wrong with
>>> size_t at all.
>>
>> So it's (modified) hungarian notation? Didn't that go out with boy bands,
>> Matrix spoofs and dancing CG babies?
>
> How is it hungarian notation? Hungarian notation puts the type of the variable
> in the name. size_t _is_ the type. I don't see any relation to hungarian
> notation. And I'm pretty sure that size_t predates the invention of hungarian
> notation by a fair margin anyway.

size_t is not the type of size_t ;-)
For sure it is Hungarian notation. What is the type of size_t? Type (at least conceptually, even if D does not have live type elements). Just what the name says.

denis
-- 
_________________
vita es estrany
spir.wikidot.com

On 02/15/2011 05:50 AM, Andrej Mitrovic wrote:
> The question is then do you want to be more consistent with the
> language (abolish size_t and make something nicer), or be consistent
> with the known standards (C99 ISO, et all.).
>
> I'd vote for a change, but I know it will never happen (even though it
> just might not be too late if we're not coding for 64 bits yet). It's
> hardcoded in the skin of C++ programmers, and Walter is at least one
> of them.

We don't need to change in the sense of replace. We just need a /standard/ correct and meaningful alternative. It must be standard to be "shared wealth" of the community, thus defined in the core stdlib or whereever (as opposed to people using their own terms, all different, as I did for a while).

    alias size_t GoodTypeName; // always available

Possibly in a while there would be a consensus to get rid of such historic junk as size_t, but it's a different step, and probably a later phase of the language's evolution imo. All we nedd now, is to be able to use a good name for an unsigned type sized to machine word and usable for indices, length, etc. Maybe the #1 type in real code, by the way, or is it string?
As long as such a name is not defined as standard, it may be counter-productive for the community, and annoying for others reading our code, to use our own preferred terms.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On 02/15/2011 06:51 AM, Walter Bright wrote:
> Andrej Mitrovic wrote:
>> The question is then do you want to be more consistent with the
>> language (abolish size_t and make something nicer), or be consistent
>> with the known standards (C99 ISO, et all.).
>>
>> I'd vote for a change, but I know it will never happen (even though it
>> just might not be too late if we're not coding for 64 bits yet). It's
>> hardcoded in the skin of C++ programmers, and Walter is at least one
>> of them.
>
> We also don't go around renaming should to shud, or use dvorak keyboards.
>
> Having to constantly explain that "use 'ourfancyname' instead of size_t, it
> works exactly the same as size_t" is a waste of our time and potential users'
> time.

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?

Please, just allow others having a correct, meaningful (and hopefully styleguide compliant) alternative --defined as a standard just like size_t. And go on using size_t as you like it.

denis
-- 
_________________
vita es estrany
spir.wikidot.com