• Andrej Mitrovic (7/7) May 09 2011 I've noticed this thread a while ago:
• KennyTM~ (8/15) May 09 2011 -sizediff_t.max
• Andrej Mitrovic (4/4) May 09 2011 ssize_t is even worse when comparing visually against size_t. It's the
• KennyTM~ (10/14) May 09 2011 At least you can tell there's a difference in number of letters.
• Francisco Almeida (6/23) May 10 2011 I think adopting ssize_t, thus improving parity with C would be more

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

I've noticed this thread a while ago:
http://thread.gmane.org/gmane.comp.lang.d.phobos/3881/focus=3885

Maybe it's way too late for any changes, but I think sizediff_t is a
mouthful. Doesn't size_s look nicer? It would be size_t's evil twin
brother, look:

size_s  imSoNegative;
size_t  neverADowner;

KennyTM~ <kennytm gmail.com> writes:

On May 10, 11 11:57, Andrej Mitrovic wrote:
 I've noticed this thread a while ago:
 http://thread.gmane.org/gmane.comp.lang.d.phobos/3881/focus=3885

 Maybe it's way too late for any changes, but I think sizediff_t is a
 mouthful. Doesn't size_s look nicer? It would be size_t's evil twin
 brother, look:

 size_s  imSoNegative;
 size_t  neverADowner;

-sizediff_t.max

The meaning of _t and _s suffix on types in C mean "type" and "struct" 
respectively, the latter never mean "signed". Using a C convention for a 
totally different meaning is going to confuse people. Further more, the 
difference between 'size_t' and 'size_s' is too small visually.

BTW, the signed version of size_t in C (POSIX) is called 'ssize_t'.

</bikeshed>

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

ssize_t is even worse when comparing visually against size_t. It's the
same crap as "if" vs "iff", which I've only recently discovered are
two different things. Heh!

Well, size_s looks nice in my code. sizediff_t steals too much space.

KennyTM~ <kennytm gmail.com> writes:

On May 10, 11 13:48, Andrej Mitrovic wrote:
 ssize_t is even worse when comparing visually against size_t. It's the
 same crap as "if" vs "iff", which I've only recently discovered are
 two different things. Heh!

At least you can tell there's a difference in number of letters.

     ssize_t x;
     size_t y;

Besides, ssize_t is a widely accepted standard type, while size_s (well, 
and sizediff_t too) is something imagined from nowhere.

You think "iff" is crap only because you don't know the word. Without 
knowing what the meaning of 'size_s' is, it is as crappy as 'ssize_t'.

 Well, size_s looks nice in my code. sizediff_t steals too much space.

Yeah, keep that alias to yourself. I only oppose pushing it to object.d 
to make it a de jure standard.

Francisco Almeida <francisco.m.almeida gmail.com> writes:

I think adopting ssize_t, thus improving parity with C would be more 
reasonable than a size_s that can be easily mistaken for size_t when 
reviewing long code.

Either way, sizediff_t isn't used that often anyway, so I don't know if 
this minor issue should take too much priority.

On 10-05-2011 07:28, KennyTM~ wrote:
 On May 10, 11 11:57, Andrej Mitrovic wrote:
 I've noticed this thread a while ago:
 http://thread.gmane.org/gmane.comp.lang.d.phobos/3881/focus=3885

 Maybe it's way too late for any changes, but I think sizediff_t is a
 mouthful. Doesn't size_s look nicer? It would be size_t's evil twin
 brother, look:

 size_s imSoNegative;
 size_t neverADowner;

 -sizediff_t.max

 The meaning of _t and _s suffix on types in C mean "type" and "struct"
 respectively, the latter never mean "signed". Using a C convention for a
 totally different meaning is going to confuse people. Further more, the
 difference between 'size_t' and 'size_s' is too small visually.

 BTW, the signed version of size_t in C (POSIX) is called 'ssize_t'.

 </bikeshed>