This is a minor issue, but still:
I was browsing through some of those other threads where size_t and and ptrdiff_t was talked about, and then I thought, should we be using the C-legacy "_t" name idiom in these D types? Is it not ugly and unconsistent with the rest of the language (types)?
It seems to me so, at first glance, so maybe we should change the name then. To what exactly I'm not sure, maybe (memsize, ptrdiff), (msize, ptrdiff) or (umsize, msize), but these are just some initial suggestions.


-- 
Bruno Medeiros
Computer Science/Engineering student

In article <dhb4jr$m2r$1@digitaldaemon.com>, Bruno Medeiros says...
>
>This is a minor issue, but still:
>I was browsing through some of those other threads where size_t and and
>ptrdiff_t was talked about, and then I thought, should we be using the
>C-legacy "_t" name idiom in these D types? Is it not ugly and
>unconsistent with the rest of the language (types)?
>It seems to me so, at first glance, so maybe we should change the name
>then. To what exactly I'm not sure, maybe (memsize, ptrdiff), (msize,
>ptrdiff) or (umsize, msize), but these are just some initial suggestions.

I concur.
--AJG.

AJG wrote:
> In article <dhb4jr$m2r$1@digitaldaemon.com>, Bruno Medeiros says...
> 
>>This is a minor issue, but still:
>>I was browsing through some of those other threads where size_t and and ptrdiff_t was talked about, and then I thought, should we be using the C-legacy "_t" name idiom in these D types? Is it not ugly and unconsistent with the rest of the language (types)?
>>It seems to me so, at first glance, so maybe we should change the name then. To what exactly I'm not sure, maybe (memsize, ptrdiff), (msize, ptrdiff) or (umsize, msize), but these are just some initial suggestions.
> 
> 
> I concur.
> --AJG.

NO. There's nothing to be gained. And it would be a lot of work to again go through the libraries. And, those two names are Established in the Community. They have a very specific meaning to all professionals.

Their semantic meaning implicitly implies architecture dependence, which int or long don't.

Georg Wrede wrote:
> AJG wrote:
> 
>> In article <dhb4jr$m2r$1@digitaldaemon.com>, Bruno Medeiros says...
>>
>>> This is a minor issue, but still:
>>> I was browsing through some of those other threads where size_t and and ptrdiff_t was talked about, and then I thought, should we be using the C-legacy "_t" name idiom in these D types? Is it not ugly and unconsistent with the rest of the language (types)?
>>> It seems to me so, at first glance, so maybe we should change the name then. To what exactly I'm not sure, maybe (memsize, ptrdiff), (msize, ptrdiff) or (umsize, msize), but these are just some initial suggestions.
>>
>>
>>
>> I concur.
>> --AJG.
> 
> 
> NO. There's nothing to be gained. And it would be a lot of work to again go through the libraries. And, those two names are Established in the Community. They have a very specific meaning to all professionals.

The same is true of wchar_t, which C++ would love to change to wchar,
and which D has sucessfully changed. I think the Established Practice Argument is strong, but not overwhelming so. If there were a change, it would have to be to a clearly superior name. When you consider that the name should not conflict with a popular variable or function name, most of the good choices are already taken. I bet that if you do a search for 'memsize' or 'ptrdiff' in C/C++/Java code, you'll get a lot of hits.
Personally, I doubt that satisfactory names exist, so ptrdiff_t and size_t are probably here to stay. But I'd be happy to be found wrong -- I agree that they are ugly.

With a bit of imagination, there may be other possibilities, though.

You can already do
typeof(x.size) a = x.size;

So you could imagine a property .sizetype as syntactic sugar for typeof(x.size), and similarly .difftype  for typeof(&x - &x). This type would be defined for all types.

Then you could have
typedef idouble any; // doesn't matter what type you use
alias any.sizetype size_t;
alias any.difftype ptrdiff_t;

for backwards compatibility with C.

I'm not proposing this, I don't really think it's a good idea.

> Their semantic meaning implicitly implies architecture dependence, which int or long don't.

Agreed. But something like 'ptrdifftype' might.

Don Clugston wrote:
> Georg Wrede wrote:
> 
>> AJG wrote:
>>
>>> In article <dhb4jr$m2r$1@digitaldaemon.com>, Bruno Medeiros says...
>>>
>>>> This is a minor issue, but still:
>>>> I was browsing through some of those other threads where size_t and and ptrdiff_t was talked about, and then I thought, should we be using the C-legacy "_t" name idiom in these D types? Is it not ugly and unconsistent with the rest of the language (types)?
>>>> It seems to me so, at first glance, so maybe we should change the name then. To what exactly I'm not sure, maybe (memsize, ptrdiff), (msize, ptrdiff) or (umsize, msize), but these are just some initial suggestions.
>>>
>>>
>>>
>>>
>>> I concur.
>>> --AJG.
>>
>>
>>
>> NO. There's nothing to be gained. And it would be a lot of work to again go through the libraries. And, those two names are Established in the Community. They have a very specific meaning to all professionals.
> 
> 
> The same is true of wchar_t, which C++ would love to change to wchar,
> and which D has sucessfully changed. I think the Established Practice Argument is strong, but not overwhelming so. If there were a change, it would have to be to a clearly superior name. When you consider that the name should not conflict with a popular variable or function name, most of the good choices are already taken. I bet that if you do a search for 'memsize' or 'ptrdiff' in C/C++/Java code, you'll get a lot of hits.
> Personally, I doubt that satisfactory names exist, so ptrdiff_t and size_t are probably here to stay. But I'd be happy to be found wrong -- I agree that they are ugly.
> 
> With a bit of imagination, there may be other possibilities, though.
> 
> You can already do
> typeof(x.size) a = x.size;
> 

That has no meaning!  x.size is an integer property that returns the number of bytes that element x takes in memory.  Taking the typeof() that is completely worthless.  Without a test to back me up here, I would say it would always be of type int - a result from the internals of the compiler's implementation (and I've looked into the DMD front end code on more than one occasion).  If this is allowed by the reference compiler, then it is surely a side-effect.

> So you could imagine a property .sizetype as syntactic sugar for typeof(x.size), and similarly .difftype  for typeof(&x - &x). This type would be defined for all types.
> 
> Then you could have
> typedef idouble any; // doesn't matter what type you use
> alias any.sizetype size_t;
> alias any.difftype ptrdiff_t;
> 
> for backwards compatibility with C.
> 
> I'm not proposing this, I don't really think it's a good idea.
> 
>> Their semantic meaning implicitly implies architecture dependence, which int or long don't.
> 
> 
> Agreed. But something like 'ptrdifftype' might.
> 
> 

James Dunne wrote:
> Don Clugston wrote:
> 
>> Georg Wrede wrote:
>>
>>> AJG wrote:
>>>
>>>> In article <dhb4jr$m2r$1@digitaldaemon.com>, Bruno Medeiros says...
>>>>
>>>>> This is a minor issue, but still:
>>>>> I was browsing through some of those other threads where size_t and and ptrdiff_t was talked about, and then I thought, should we be using the C-legacy "_t" name idiom in these D types? Is it not ugly and unconsistent with the rest of the language (types)?
>>>>> It seems to me so, at first glance, so maybe we should change the name then. To what exactly I'm not sure, maybe (memsize, ptrdiff), (msize, ptrdiff) or (umsize, msize), but these are just some initial suggestions.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I concur.
>>>> --AJG.
>>>
>>>
>>>
>>>
>>> NO. There's nothing to be gained. And it would be a lot of work to again go through the libraries. And, those two names are Established in the Community. They have a very specific meaning to all professionals.
>>
>>
>>
>> The same is true of wchar_t, which C++ would love to change to wchar,
>> and which D has sucessfully changed. I think the Established Practice Argument is strong, but not overwhelming so. If there were a change, it would have to be to a clearly superior name. When you consider that the name should not conflict with a popular variable or function name, most of the good choices are already taken. I bet that if you do a search for 'memsize' or 'ptrdiff' in C/C++/Java code, you'll get a lot of hits.
>> Personally, I doubt that satisfactory names exist, so ptrdiff_t and size_t are probably here to stay. But I'd be happy to be found wrong -- I agree that they are ugly.
>>
>> With a bit of imagination, there may be other possibilities, though.
>>
>> You can already do
>> typeof(x.size) a = x.size;
>>
> 
> That has no meaning!  x.size is an integer property that returns the number of bytes that element x takes in memory.  Taking the typeof() that is completely worthless.  Without a test to back me up here, I would say it would always be of type int - a result from the internals of the compiler's implementation (and I've looked into the DMD front end code on more than one occasion).  If this is allowed by the reference compiler, then it is surely a side-effect.

Sorry, should have been sizeof. The code below works correctly in DMD 0.133.
----------------------
import std.stdio;

int main()
{
   typeof(int.sizeof) a = double.sizeof;
   writefln(a);
   return 0;
}
------------------
x.sizeof has to be a size_t rather than an integer property. Even if there's an implicit conversion from size_t to int.
Remember that on a 64-bit system, the number of bytes x takes in memory might be greater that 2^32 and hence the result of .sizeof might not fit into an int. (It's possible that the existing front end might not yet deal with this correctly).

>> So you could imagine a property .sizetype as syntactic sugar for typeof(x.size), and similarly .difftype  for typeof(&x - &x). This type would be defined for all types.
>>
>> Then you could have
>> typedef idouble any; // doesn't matter what type you use
>> alias any.sizetype size_t;
>> alias any.difftype ptrdiff_t;
>>
>> for backwards compatibility with C.
>>
>> I'm not proposing this, I don't really think it's a good idea.
>>
>>> Their semantic meaning implicitly implies architecture dependence, which int or long don't.
>>
>> Agreed. But something like 'ptrdifftype' might.

In article <43393881.3080108@nospam.org>, Georg Wrede says...
>
>AJG wrote:
>> In article <dhb4jr$m2r$1@digitaldaemon.com>, Bruno Medeiros says...
>> 
>>>This is a minor issue, but still:
>>>I was browsing through some of those other threads where size_t and and
>>>ptrdiff_t was talked about, and then I thought, should we be using the
>>>C-legacy "_t" name idiom in these D types? Is it not ugly and
>>>unconsistent with the rest of the language (types)?
>>>It seems to me so, at first glance, so maybe we should change the name
>>>then. To what exactly I'm not sure, maybe (memsize, ptrdiff), (msize,
>>>ptrdiff) or (umsize, msize), but these are just some initial suggestions.
>> 
>> 
>> I concur.
>> --AJG.
>
>NO. There's nothing to be gained.

Yes, there is something to be gained. Cleaner, shorter, simpler names.

> And it would be a lot of work to again
>go through the libraries.

They could simply be deprecated, just like functions are every once in a while.

>And, those two names are Established in the Community. They have a very specific meaning to all professionals.

Perhaps in the C community. But this is D, so we can be a little progressive.

>Their semantic meaning implicitly implies architecture dependence, which int or long don't.

Really? That's funny. Ever heard of endianness?

Cheers,
--AJG.

Don Clugston wrote:
> James Dunne wrote:
> 
>> Don Clugston wrote:
>>
>>> Georg Wrede wrote:
>>>
>>>> AJG wrote:
>>>>
>>>>> In article <dhb4jr$m2r$1@digitaldaemon.com>, Bruno Medeiros says...
>>>>>
>>>>>> This is a minor issue, but still:
>>>>>> I was browsing through some of those other threads where size_t and and ptrdiff_t was talked about, and then I thought, should we be using the C-legacy "_t" name idiom in these D types? Is it not ugly and unconsistent with the rest of the language (types)?
>>>>>> It seems to me so, at first glance, so maybe we should change the name then. To what exactly I'm not sure, maybe (memsize, ptrdiff), (msize, ptrdiff) or (umsize, msize), but these are just some initial suggestions.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I concur.
>>>>> --AJG.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> NO. There's nothing to be gained. And it would be a lot of work to again go through the libraries. And, those two names are Established in the Community. They have a very specific meaning to all professionals.
>>>
>>>
>>>
>>>
>>> The same is true of wchar_t, which C++ would love to change to wchar,
>>> and which D has sucessfully changed. I think the Established Practice Argument is strong, but not overwhelming so. If there were a change, it would have to be to a clearly superior name. When you consider that the name should not conflict with a popular variable or function name, most of the good choices are already taken. I bet that if you do a search for 'memsize' or 'ptrdiff' in C/C++/Java code, you'll get a lot of hits.
>>> Personally, I doubt that satisfactory names exist, so ptrdiff_t and size_t are probably here to stay. But I'd be happy to be found wrong -- I agree that they are ugly.
>>>
>>> With a bit of imagination, there may be other possibilities, though.
>>>
>>> You can already do
>>> typeof(x.size) a = x.size;
>>>
>>
>> That has no meaning!  x.size is an integer property that returns the number of bytes that element x takes in memory.  Taking the typeof() that is completely worthless.  Without a test to back me up here, I would say it would always be of type int - a result from the internals of the compiler's implementation (and I've looked into the DMD front end code on more than one occasion).  If this is allowed by the reference compiler, then it is surely a side-effect.
> 
> 
> Sorry, should have been sizeof. The code below works correctly in DMD 0.133.
> ----------------------
> import std.stdio;
> 
> int main()
> {
>    typeof(int.sizeof) a = double.sizeof;
>    writefln(a);
>    return 0;
> }
> ------------------
> x.sizeof has to be a size_t rather than an integer property. Even if there's an implicit conversion from size_t to int.
> Remember that on a 64-bit system, the number of bytes x takes in memory might be greater that 2^32 and hence the result of .sizeof might not fit into an int. (It's possible that the existing front end might not yet deal with this correctly).
> 
>>> So you could imagine a property .sizetype as syntactic sugar for typeof(x.size), and similarly .difftype  for typeof(&x - &x). This type would be defined for all types.
>>>
>>> Then you could have
>>> typedef idouble any; // doesn't matter what type you use
>>> alias any.sizetype size_t;
>>> alias any.difftype ptrdiff_t;
>>>
>>> for backwards compatibility with C.
>>>
>>> I'm not proposing this, I don't really think it's a good idea.
>>>
>>>> Their semantic meaning implicitly implies architecture dependence, which int or long don't.
>>>
>>>
>>> Agreed. But something like 'ptrdifftype' might.

I think you are confusing int.max with int.sizeof.  int.sizeof returns the number of bytes that the integer type takes up in memory, similar for long.sizeof.

int is _always_ 32 bits as specified by the D language spec.  int.sizeof will _always_ return 4.  long is _always_ 64 bits, again as in the spec.  long.sizeof will _always_ return 8.  The typeof() that number returned by int.sizeof and long.sizeof is compiler-implementation-specific and essentially has no meaning.

Now, with other types, aside from basic types, sizeof does not have to be represented as a size_t because there are no types that are going to exceed a 32-bit representable size, aside from an extremely large static array.  But that is what we have the length property for.  And if you'll agree, length must be a size_t.  Besides, last I recall, the size of static arrays is limited to something on the order of 16MB, so this case is effectively stamped out by that limit.

James Dunne wrote:
> Don Clugston wrote:
> 
>> James Dunne wrote:
>>
>>> Don Clugston wrote:
>>>
>>>> Georg Wrede wrote:
>>>>
>>>>> AJG wrote:
>>>>>
>>>>>> In article <dhb4jr$m2r$1@digitaldaemon.com>, Bruno Medeiros says...
>>>>>>
>>>>>>> This is a minor issue, but still:
>>>>>>> I was browsing through some of those other threads where size_t and and ptrdiff_t was talked about, and then I thought, should we be using the C-legacy "_t" name idiom in these D types? Is it not ugly and unconsistent with the rest of the language (types)?
>>>>>>> It seems to me so, at first glance, so maybe we should change the name then. To what exactly I'm not sure, maybe (memsize, ptrdiff), (msize, ptrdiff) or (umsize, msize), but these are just some initial suggestions.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I concur.
>>>>>> --AJG.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> NO. There's nothing to be gained. And it would be a lot of work to again go through the libraries. And, those two names are Established in the Community. They have a very specific meaning to all professionals.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> The same is true of wchar_t, which C++ would love to change to wchar,
>>>> and which D has sucessfully changed. I think the Established Practice Argument is strong, but not overwhelming so. If there were a change, it would have to be to a clearly superior name. When you consider that the name should not conflict with a popular variable or function name, most of the good choices are already taken. I bet that if you do a search for 'memsize' or 'ptrdiff' in C/C++/Java code, you'll get a lot of hits.
>>>> Personally, I doubt that satisfactory names exist, so ptrdiff_t and size_t are probably here to stay. But I'd be happy to be found wrong -- I agree that they are ugly.
>>>>
>>>> With a bit of imagination, there may be other possibilities, though.
>>>>
>>>> You can already do
>>>> typeof(x.size) a = x.size;
>>>>
>>>
>>> That has no meaning!  x.size is an integer property that returns the number of bytes that element x takes in memory.  Taking the typeof() that is completely worthless.  Without a test to back me up here, I would say it would always be of type int - a result from the internals of the compiler's implementation (and I've looked into the DMD front end code on more than one occasion).  If this is allowed by the reference compiler, then it is surely a side-effect.
>>
>>
>>
>> Sorry, should have been sizeof. The code below works correctly in DMD 0.133.
>> ----------------------
>> import std.stdio;
>>
>> int main()
>> {
>>    typeof(int.sizeof) a = double.sizeof;
>>    writefln(a);
>>    return 0;
>> }
>> ------------------
>> x.sizeof has to be a size_t rather than an integer property. Even if there's an implicit conversion from size_t to int.
>> Remember that on a 64-bit system, the number of bytes x takes in memory might be greater that 2^32 and hence the result of .sizeof might not fit into an int. (It's possible that the existing front end might not yet deal with this correctly).
>>
>>>> So you could imagine a property .sizetype as syntactic sugar for typeof(x.size), and similarly .difftype  for typeof(&x - &x). This type would be defined for all types.
>>>>
>>>> Then you could have
>>>> typedef idouble any; // doesn't matter what type you use
>>>> alias any.sizetype size_t;
>>>> alias any.difftype ptrdiff_t;
>>>>
>>>> for backwards compatibility with C.
>>>>
>>>> I'm not proposing this, I don't really think it's a good idea.
>>>>
>>>>> Their semantic meaning implicitly implies architecture dependence, which int or long don't.
>>>>
>>>>
>>>>
>>>> Agreed. But something like 'ptrdifftype' might.
> 
> 
> I think you are confusing int.max with int.sizeof.  int.sizeof returns the number of bytes that the integer type takes up in memory, similar for long.sizeof.

Yes, I'm well aware of the difference.

> int is _always_ 32 bits as specified by the D language spec.  int.sizeof will _always_ return 4.  long is _always_ 64 bits, again as in the spec.  long.sizeof will _always_ return 8.

Yes.

  The typeof() that number returned
> by int.sizeof and long.sizeof is compiler-implementation-specific and essentially has no meaning.

Not so. It's in the spec. To quote portability.html:
* The .length, .size, .sizeof, and .alignof properties will be of type size_t.

> Now, with other types, aside from basic types, sizeof does not have to be represented as a size_t because there are no types that are going to exceed a 32-bit representable size, aside from an extremely large static array.  But that is what we have the length property for.  And if you'll
> agree, length must be a size_t.  Besides, last I recall, the size of static arrays is limited to something on the order of 16MB, so this case is effectively stamped out by that limit.

Don Clugston wrote:
> Georg Wrede wrote:
> 
>> AJG wrote:
>>
>>> In article <dhb4jr$m2r$1@digitaldaemon.com>, Bruno Medeiros says...
>>>
>>>> This is a minor issue, but still:
>>>> I was browsing through some of those other threads where size_t and and ptrdiff_t was talked about, and then I thought, should we be using the C-legacy "_t" name idiom in these D types? Is it not ugly and unconsistent with the rest of the language (types)?
>>>> It seems to me so, at first glance, so maybe we should change the name then. To what exactly I'm not sure, maybe (memsize, ptrdiff), (msize, ptrdiff) or (umsize, msize), but these are just some initial suggestions.
>>>
>>>
>>>
>>>
>>> I concur.
>>> --AJG.
>>
>>
>>
>> NO. There's nothing to be gained. And it would be a lot of work to again go through the libraries. And, those two names are Established in the Community. They have a very specific meaning to all professionals.
> 
> 
> The same is true of wchar_t, which C++ would love to change to wchar,
> and which D has sucessfully changed. I think the Established Practice Argument is strong, but not overwhelming so. If there were a change, it would have to be to a clearly superior name. When you consider that the name should not conflict with a popular variable or function name, most of the good choices are already taken. I bet that if you do a search for 'memsize' or 'ptrdiff' in C/C++/Java code, you'll get a lot of hits.
> Personally, I doubt that satisfactory names exist, so ptrdiff_t and size_t are probably here to stay. But I'd be happy to be found wrong -- I agree that they are ugly.
> 
Yes, despite the current situation not being ideal, finding a good alternative may not be easy. I recognize the problem that a type name without "_t" might conflict with a common var name (either with existing or future made code). That is why I hereby make the call here for people to start working their technical creativity to see if we can come up with a good name :) . It may take a while, but if we take this issue in regard and keep it in mind we'll get there.

"msize" is probably not good, it is too common, the "m" could be a lot of things.
"memsize" is better, but still may not be the ideal.
"sizetype" or "ptrdifftype" I don't like them either, the "type" redundancy is still there.

I'm trying to get my inspiration from the type's description, since it is it's semantic meaning that matters:

	alias size_t
	An unsigned integral type large enough to span the memory space. Use for array indices and pointer offsets for maximal portability to architectures that have different memory address ranges. This is analogous to C's size_t.

	alias ptrdiff_t
	A signed integral type large enough to span the memory space. Use for pointer differences and for size_t differences for maximal portability to architectures that have different memory address ranges. This is analogous to C's ptrdiff_t.

So here's some more ideias:

"memspan"
"ptrsize"
"ptrspan" -> hum... this last one may be quite good, and it fits well with it's complement "ptrdiff" .

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."