Steven Schveighoffer Wrote:

> On Tue, 15 Feb 2011 09:26:21 -0500, spir <denis.spir@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.

foobar wrote:
> 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. 

It's a C convention.

> 2. the proposed change is backwards compatible - the OP asked for an *additional* alias.

I do not believe that value is added by adding more and more aliases for the same thing. It makes the library large and complex but with no depth.

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

Funny thing is the most important argument against size_t got the least attention.
I will leave it as an exercise for the reader.

On 02/15/2011 08:05 PM, Walter Bright wrote:
> foobar wrote:
>> 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.
>
> It's a C convention.
>
>> 2. the proposed change is backwards compatible - the OP asked for an
>> *additional* alias.
>
> I do not believe that value is added by adding more and more aliases for the
> same thing. It makes the library large and complex but with no depth.

If we asked for various aliases for numerous builtin terms of the language, your point would be fully valid. But here is only asked for a single standard alias for what may well be the most used type in the language; which presently has a obscure alias name.
Cost: one line of code in object.d:
    alias typeof(int.sizeof)                    size_t;
    alias typeof(int.sizeof)                    Abcdef; // add this

As an aside, the opportunity may be taken to use machine-word-size signed values as a standard for indices/positions and sizes/counts/lengths (and offsets?), everywhere in the language, for the coming 64-bit version. Don, IIRC, and Bearophile, referred to issues due to unsigned values.
This would also give an obvious name for the alias, "Integer", that probably few would contest (hope so).

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

"so" <so@so.so> wrote in message news:op.vqyk3emumpw3zg@so-pc...
>> 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.
>
> Funny thing is the most important argument against size_t got the least
> attention.
> I will leave it as an exercise for the reader.

That variables of type "size_t" are frequently used to store indicies rather than the actual *size* of anything?

That it does nothing to help with 32/64-bit portability until you actually compile your code both ways?

That Nick doesn't like it? ;)

Am 15.02.2011 23:00, schrieb Nick Sabalausky:
> "so" <so@so.so> wrote in message news:op.vqyk3emumpw3zg@so-pc...
>>> 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.
>>
>> Funny thing is the most important argument against size_t got the least
>> attention.
>> I will leave it as an exercise for the reader.
> 
> That variables of type "size_t" are frequently used to store indicies rather than the actual *size* of anything?
> 
> That it does nothing to help with 32/64-bit portability until you actually compile your code both ways?

I don't understand that point.

> 
> That Nick doesn't like it? ;)
> 

On Tuesday, February 15, 2011 14:00:12 Nick Sabalausky wrote:
> "so" <so@so.so> wrote in message news:op.vqyk3emumpw3zg@so-pc...
> 
> >> 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.
> > 
> > Funny thing is the most important argument against size_t got the least
> > attention.
> > I will leave it as an exercise for the reader.
> 
> That variables of type "size_t" are frequently used to store indicies rather than the actual *size* of anything?
> 
> That it does nothing to help with 32/64-bit portability until you actually compile your code both ways?

What _does_ have to do with 32/64-bit portability until you compile both ways? Regardless of what the name is, it's still going to be the word size of the machine and vary between 32-bit and 64-bit anyway.

- Jonathan M Davis

"Daniel Gibson" <metalcaedes@gmail.com> wrote in message news:ijett7$1ie$5@digitalmars.com...
> Am 15.02.2011 23:00, schrieb Nick Sabalausky:
>> "so" <so@so.so> wrote in message news:op.vqyk3emumpw3zg@so-pc...
>>>
>>> Funny thing is the most important argument against size_t got the least
>>> attention.
>>> I will leave it as an exercise for the reader.
>>
>> That variables of type "size_t" are frequently used to store indicies
>> rather
>> than the actual *size* of anything?
>>
>> That it does nothing to help with 32/64-bit portability until you
>> actually
>> compile your code both ways?
>
> I don't understand that point.
>

If you're writing something in 32-bit and you use size_t, it may compile perfectly fine for 32-bit, but the compiler won't tell you about any problems that will appear when you compile the same code for 64-bit (such as "can't implicitly convert"). Presumably the same would apply to writing something on 64-bit and then suddenly compiling for 32-bit.

I'm not actually asserting that this is a big issue. Maybe it is, maybe it isn't, I don't know. Just making guesses at what "so" sees as "the most important argument against size_t [that] got the least attention".

Am 15.02.2011 23:29, schrieb Nick Sabalausky:
> "Daniel Gibson" <metalcaedes@gmail.com> wrote in message news:ijett7$1ie$5@digitalmars.com...
>> Am 15.02.2011 23:00, schrieb Nick Sabalausky:
>>> "so" <so@so.so> wrote in message news:op.vqyk3emumpw3zg@so-pc...
>>>>
>>>> Funny thing is the most important argument against size_t got the least
>>>> attention.
>>>> I will leave it as an exercise for the reader.
>>>
>>> That variables of type "size_t" are frequently used to store indicies
>>> rather
>>> than the actual *size* of anything?
>>>
>>> That it does nothing to help with 32/64-bit portability until you
>>> actually
>>> compile your code both ways?
>>
>> I don't understand that point.
>>
> 
> If you're writing something in 32-bit and you use size_t, it may compile perfectly fine for 32-bit, but the compiler won't tell you about any problems that will appear when you compile the same code for 64-bit (such as "can't implicitly convert"). Presumably the same would apply to writing something on 64-bit and then suddenly compiling for 32-bit.
> 
> I'm not actually asserting that this is a big issue. Maybe it is, maybe it isn't, I don't know. Just making guesses at what "so" sees as "the most important argument against size_t [that] got the least attention".
> 

Ok, that is right.
Probably it would be helpful if size_t was a proper type that can't be mixed
with other types in dangerous ways without explicit casting.

Cheers,
- Daniel

Daniel Gibson wrote:
> Probably it would be helpful if size_t was a proper type that can't be mixed with other types in dangerous ways without explicit casting.

Bad idea: once you insert an explicit cast, you now have a *hidden* bug on the new platform instead of a compile error.