www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - problem with size_t and an easy solution

reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
Hello.

i don't like `size_t`. for many month i avoied using it wherever that
was possible, 'cause i feel something wrong with it. and today i found
the soultion!

let's see how other D types are named: `int`, `uint`, `byte` (oh, well,
this name sux), `ulong`. see the pattern? so i decided to rename
`size_t` to `usize`. and you know what? it immidiately started to be
familiar. like a thing that was always here, simply dressed in patches.

let's face it: that ugly '_t' is alien to D. this is an ugly leftover
from C, and this leftover is nonsence. it will not really help anyone,
but it immideately turns D code to badly-looking crap. see for yourself:

  size_t countSomeElements();

and

  usize countSomeElements();

`size_t` looking like an alien here, ruining all the style.

i propose to introduce `usize` and `sptrdiff` along with those '_t'
uglyness, and then slowly migrate all the code to the new names.

yes, this is another "cosmetic issue", but let me tell you that such
"purely cosmetic things" are really important for those who just
starting to learn the language.

it's impossible to write nice D code with `size_t`: we have either
alias it each time or use `uint`/`ulong` to make our code looks good.

really, i've seen people who using `uint` instead of `size_t`, 'cause
"with size_t my code looks ugly, and i tired of aliasing that shit
every time". ah, yep, their code sux for 64 bits, but: "i know that
64-bit size_t is... 64-bit. i'll fix that later, maybe."

uglyness leads to bad code. let's kill `size_t` for good!


p.s. some of you may think that i'm trolling. i can assure you that
this post is not trolling, this is just another try to talk about
"purely cosmetic issues" and how they hurts the language, especially
for beginners. when beginner see such "pure cosmetic issue", he
starting to think that the whole language is a mess: "hey, this is such
easy to fix, but they never bother to... i bet the other parts of the
language are even worse." and you know what? it's enough to make such
mistake two or three times to make people believe that D is a "dirty
and hackish language without clear style". "this is uuuugly" is *the*
*argument*.
Dec 07 2014
next sibling parent reply "Freddy" <Hexagonalstar64 gmail.com> writes:
On Monday, 8 December 2014 at 01:30:35 UTC, ketmar via
Digitalmars-d wrote:

 Hello.

 i don't like `size_t`. for many month i avoied using it 
 wherever that
 was possible, 'cause i feel something wrong with it. and today 
 i found
 the soultion!

 let's see how other D types are named: `int`, `uint`, `byte` 
 (oh, well,
 this name sux), `ulong`. see the pattern? so i decided to rename
 `size_t` to `usize`. and you know what? it immidiately started 
 to be
 familiar. like a thing that was always here, simply dressed in 
 patches.

 let's face it: that ugly '_t' is alien to D. this is an ugly 
 leftover
 from C, and this leftover is nonsence. it will not really help 
 anyone,
 but it immideately turns D code to badly-looking crap. see for 
 yourself:

   size_t countSomeElements();

 and

   usize countSomeElements();

 `size_t` looking like an alien here, ruining all the style.

 i propose to introduce `usize` and `sptrdiff` along with those 
 '_t'
 uglyness, and then slowly migrate all the code to the new names.

 yes, this is another "cosmetic issue", but let me tell you that 
 such
 "purely cosmetic things" are really important for those who just
 starting to learn the language.

 it's impossible to write nice D code with `size_t`: we have 
 either
 alias it each time or use `uint`/`ulong` to make our code looks 
 good.

 really, i've seen people who using `uint` instead of `size_t`, 
 'cause
 "with size_t my code looks ugly, and i tired of aliasing that 
 shit
 every time". ah, yep, their code sux for 64 bits, but: "i know 
 that
 64-bit size_t is... 64-bit. i'll fix that later, maybe."

 uglyness leads to bad code. let's kill `size_t` for good!


 p.s. some of you may think that i'm trolling. i can assure you 
 that
 this post is not trolling, this is just another try to talk 
 about
 "purely cosmetic issues" and how they hurts the language, 
 especially
 for beginners. when beginner see such "pure cosmetic issue", he
 starting to think that the whole language is a mess: "hey, this 
 is such
 easy to fix, but they never bother to... i bet the other parts 
 of the
 language are even worse." and you know what? it's enough to 
 make such
 mistake two or three times to make people believe that D is a 
 "dirty
 and hackish language without clear style". "this is uuuugly" is 
 *the*
 *argument*.


I would like if usize wasn't implictly convertable to uint or
ulong
Dec 07 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 08 Dec 2014 01:50:44 +0000
Freddy via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 I would like if usize wasn't implictly convertable to uint or
 ulong


me too, but this change is too radical. it will not break any of my
own code ('cause i used to write casts for that stupid 64-bit systems to
shut up), but i doubt that other people will agree with such change.
Dec 07 2014
parent reply "Freddy" <Hexagonalstar64 gmail.com> writes:
On Monday, 8 December 2014 at 02:04:58 UTC, ketmar via
Digitalmars-d wrote:

 On Mon, 08 Dec 2014 01:50:44 +0000
 Freddy via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 I would like if usize wasn't implictly convertable to uint or
 ulong


 me too, but this change is too radical. it will not break any 
 of my
 own code ('cause i used to write casts for that stupid 64-bit 
 systems to
 shut up), but i doubt that other people will agree with such 
 change.


Why not keep size_t implictly convertable but disallow it for
usize.
Dec 07 2014
next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 08 Dec 2014 02:29:49 +0000
Freddy via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Monday, 8 December 2014 at 02:04:58 UTC, ketmar via
 Digitalmars-d wrote:

 On Mon, 08 Dec 2014 01:50:44 +0000
 Freddy via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 I would like if usize wasn't implictly convertable to uint or
 ulong


 me too, but this change is too radical. it will not break any=20
 of my
 own code ('cause i used to write casts for that stupid 64-bit=20
 systems to
 shut up), but i doubt that other people will agree with such=20
 change.


=20
 Why not keep size_t implictly convertable but disallow it for
 usize.


'cause there is no such type as `size_t` (and `usize` for that matter).
`size_t` is defined as the alias for the corresponding unsigned
integral type, and so i did with `usize`.

so both `size_t` and `usize` are actually `uint`/`ulong`. so they not
just "convertible", they are the same type.
Dec 07 2014
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Freddy:


 Why not keep size_t implictly convertable but disallow it for
 usize.


This is an interesting idea. (But the name "uword" seems better).

Bye,
bearophile
Dec 08 2014
next sibling parent reply "Dominikus Dittes Scherkl" writes:
On Monday, 8 December 2014 at 08:46:49 UTC, bearophile wrote:

 Freddy:


 Why not keep size_t implictly convertable but disallow it for
 usize.


 This is an interesting idea. (But the name "uword" seems 
 better).


YES.
And I want a signed variant of this (instead of the ugly 
ptrdiff_t):
I want to wield my sword!
Dec 08 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 08 Dec 2014 11:37:00 +0000
Dominikus Dittes Scherkl via Digitalmars-d
<digitalmars-d puremagic.com> wrote:


 On Monday, 8 December 2014 at 08:46:49 UTC, bearophile wrote:

 Freddy:


 Why not keep size_t implictly convertable but disallow it for
 usize.


 This is an interesting idea. (But the name "uword" seems=20
 better).


 YES.
 And I want a signed variant of this (instead of the ugly=20
 ptrdiff_t):
 I want to wield my sword!


"uword" is meaningless, and "usize" is meaningfull. but i like
"sword"... yet i used to 16-bit words.
Dec 08 2014
parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
On Monday, 8 December 2014 at 11:49:47 UTC, ketmar via 
Digitalmars-d wrote:

 On Mon, 08 Dec 2014 11:37:00 +0000
 Dominikus Dittes Scherkl via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:


 On Monday, 8 December 2014 at 08:46:49 UTC, bearophile wrote:

 Freddy:


 Why not keep size_t implictly convertable but disallow it 
 for
 usize.


 This is an interesting idea. (But the name "uword" seems 
 better).


 YES.
 And I want a signed variant of this (instead of the ugly 
 ptrdiff_t):
 I want to wield my sword!


 "uword" is meaningless, and "usize" is meaningfull. but i like
 "sword"... yet i used to 16-bit words.


This is just my opinion and I could be persuaded otherwise but 
word/uword seem nicer.  It seems more descriptive, the size of a 
word on the system. Also I see less potential for name conflicts. 
  The type "size" will probably conflict with alot of symbol names 
(function names/variables/etc).  I would be willing to bet this 
is why C/C++ initially used "size_t" instead of "size" in the 
first place.
Dec 08 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 08 Dec 2014 14:00:25 +0000
Jonathan Marler via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Monday, 8 December 2014 at 11:49:47 UTC, ketmar via=20
 Digitalmars-d wrote:

 On Mon, 08 Dec 2014 11:37:00 +0000
 Dominikus Dittes Scherkl via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:


 On Monday, 8 December 2014 at 08:46:49 UTC, bearophile wrote:

 Freddy:


 Why not keep size_t implictly convertable but disallow it=20
 for
 usize.


 This is an interesting idea. (But the name "uword" seems=20
 better).


 YES.
 And I want a signed variant of this (instead of the ugly=20
 ptrdiff_t):
 I want to wield my sword!


 "uword" is meaningless, and "usize" is meaningfull. but i like
 "sword"... yet i used to 16-bit words.


=20
 This is just my opinion and I could be persuaded otherwise but=20
 word/uword seem nicer.  It seems more descriptive, the size of a=20
 word on the system. Also I see less potential for name conflicts.=20
   The type "size" will probably conflict with alot of symbol names=20
 (function names/variables/etc).  I would be willing to bet this=20
 is why C/C++ initially used "size_t" instead of "size" in the=20
 first place.


ah, there can't be "size" type, only "usize". we can't have list or
array with -3 items. ;-) and even if we want signed size, this will be
"ssize". we already have "byte" instead of "sbyte", it's PITA.
Dec 08 2014
parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
On Monday, 8 December 2014 at 14:29:09 UTC, ketmar via 
Digitalmars-d wrote:

 On Mon, 08 Dec 2014 14:00:25 +0000
 Jonathan Marler via Digitalmars-d <digitalmars-d puremagic.com> 
 wrote:


 On Monday, 8 December 2014 at 11:49:47 UTC, ketmar via 
 Digitalmars-d wrote:

 On Mon, 08 Dec 2014 11:37:00 +0000
 Dominikus Dittes Scherkl via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:


 On Monday, 8 December 2014 at 08:46:49 UTC, bearophile 
 wrote:

 Freddy:


 Why not keep size_t implictly convertable but disallow 
 it for
 usize.


 This is an interesting idea. (But the name "uword" seems 
 better).


 YES.
 And I want a signed variant of this (instead of the ugly 
 ptrdiff_t):
 I want to wield my sword!


 "uword" is meaningless, and "usize" is meaningfull. but i 
 like
 "sword"... yet i used to 16-bit words.


 
 This is just my opinion and I could be persuaded otherwise but 
 word/uword seem nicer.  It seems more descriptive, the size of 
 a word on the system. Also I see less potential for name 
 conflicts.
   The type "size" will probably conflict with alot of symbol 
 names (function names/variables/etc).  I would be willing to 
 bet this is why C/C++ initially used "size_t" instead of 
 "size" in the first place.


 ah, there can't be "size" type, only "usize". we can't have 
 list or
 array with -3 items. ;-) and even if we want signed size, this 
 will be
 "ssize". we already have "byte" instead of "sbyte", it's PITA.


What about 'usize' and 'ptrdiff' ?  'ssize' seems a little ugly 
to me, but I realize this is just a matter of opinion.  
Personally I think this is a good idea, but I would be ok with 
multiple solutions.  'uword'/'usize' both seem ok to me.  I could 
even live with 'ssize'.

I have gotten use to using '_t' but you make a good point that 
since 'size_t' looks alien to D it encourages users to use the 
wrong type since it may look more consistent to the rest of their 
D code.  In my opinion, size_t needs to be treated more like a 
first class citizen, listed with all the other native types 
instead of being a footnote.  Maybe changing the name will help 
developers use it.
Dec 08 2014
next sibling parent reply "bitwise" <bitwise.pvt gmail.com> writes:
FWIW, I picked hp D ~2 months ago, and my first project was a
reflection library, so I've had a chance to deal with most of the
language features at least once so far. The naming and presence
of legacy C++ was a little strange, but I would leave it at that.
What was by FAR the most confusing/frustrating thing was the
vague, and many times, completely wrong or misleading compiler
error messages. If time was to be spent anywhere, I think that
would be most helpful.

I would quote a few of these error messages, but I wouldn't be
able to reproduce them, as I have no idea why they occurred in
the first place..
Dec 08 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
bitwise:


 I would quote a few of these error messages, but I wouldn't be
 able to reproduce them, as I have no idea why they occurred in
 the first place..


You don't need to know what caused them, you have to copy your 
code, minimize it progressively keeping the error message 
unchanged, and submit it to bugzilla. D devs are quite willing to 
improve error messages, they have improved many of them.

Bye,
bearophile
Dec 08 2014
parent "Jonathan Marler" <johnnymarler gmail.com> writes:
On Monday, 8 December 2014 at 17:38:42 UTC, bearophile wrote:

 bitwise:


 I would quote a few of these error messages, but I wouldn't be
 able to reproduce them, as I have no idea why they occurred in
 the first place..


 You don't need to know what caused them, you have to copy your 
 code, minimize it progressively keeping the error message 
 unchanged, and submit it to bugzilla. D devs are quite willing 
 to improve error messages, they have improved many of them.

 Bye,
 bearophile


Don't forget to mention DustMite.  A simple yet elegent solution 
to assist in minimizing the code.  It comes packaged with the DMD 
compiler so you probably already have it installed:)
Dec 08 2014
prev sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 08 Dec 2014 15:52:07 +0000
bitwise via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 FWIW, I picked hp D ~2 months ago, and my first project was a
 reflection library, so I've had a chance to deal with most of the
 language features at least once so far. The naming and presence
 of legacy C++ was a little strange, but I would leave it at that.
 What was by FAR the most confusing/frustrating thing was the
 vague, and many times, completely wrong or misleading compiler
 error messages. If time was to be spent anywhere, I think that
 would be most helpful.
=20
 I would quote a few of these error messages, but I wouldn't be
 able to reproduce them, as I have no idea why they occurred in
 the first place..


ah, the thing that now got the official commit: "stop after N errors".
just make the compiler stop after exactly one error, and most "strange"
error messages will go away.

somehow Walter can't accept that after emiting the first error compiler
is in undefined state, and trying to pretend that it is in well-defined
state or guess what well-defined state must be is a nonsense.

D compiler is fast enough to stop that horrible "now you have
100500 errors reported, enjoy" practice.

the second thing that i want to have is compiler explaining why it
rejected some templates. i.e. what constrains failed. those messages
about "can't instantiate" are among the most noisy and cryptic ones.
Dec 08 2014
parent reply "Ivan Kazmenko" <gassa mail.ru> writes:
On Tuesday, 9 December 2014 at 03:14:23 UTC, ketmar via 
Digitalmars-d wrote:

 somehow Walter can't accept that after emiting the first error 
 compiler
 is in undefined state, and trying to pretend that it is in 
 well-defined
 state or guess what well-defined state must be is a nonsense.


A well-designed language allows to recover from errors with good 
probability and thus give simultaneous useful error reports for 
multiple parts of the program.  Sure, you always need the first 
error message, but having other useful error messages is a 
benefit as long as the probability of recovery is high enough.
Dec 09 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 09 Dec 2014 17:28:15 +0000
Ivan Kazmenko via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 A well-designed language allows to recover from errors with good=20
 probability


if compiler can recover from error, it should not report the error at
all -- 'cause it can fix the code for me.

that is absolutely nonsense, you *CAN'T* "recover" from invalid code.
that is the fact. fact: Earth is not a sphere. fact: you can't
automatically recover from invalid code.

that habit of "try to compile as much as we can" originates in the
times when running a compiler was very costly process, so it's better
to have some invalid error messages than runing the compiler again
after each error found and fixed.

hey, it's time to stop doing that! the epoch of punch cards and
teletypes are over! it's time to stop trying to "recover" from
irrecoverable states. there is *nothing* valuable in a stupid list of
compilation errors most of which are invalid and others will become
invalid after you fix the first one.

build faster compiler. cache AST's. but stop vomiting alphanumeric noise
"just because... well... we doing this from 70ths!"
Dec 09 2014
parent reply "Ivan Kazmenko" <gassa mail.ru> writes:
On Wednesday, 10 December 2014 at 02:15:04 UTC, ketmar via 
Digitalmars-d wrote:

 On Tue, 09 Dec 2014 17:28:15 +0000
 Ivan Kazmenko via Digitalmars-d <digitalmars-d puremagic.com> 
 wrote:


 A well-designed language allows to recover from errors with 
 good probability


 if compiler can recover from error, it should not report the 
 error at
 all -- 'cause it can fix the code for me.

 that is absolutely nonsense, you *CAN'T* "recover" from invalid 
 code.
 that is the fact. fact: Earth is not a sphere. fact: you can't
 automatically recover from invalid code.


That sounds much like an opinion, a lot less like a fact.  If you 
are willing to convince people, please provide some evidence, 
aside from another unrelated fact.  If you guess the right 
recovery in, say, 99% of cases, few would care that it's 
theoretically impossible in the general case.

In my experience, I find multiple reported compile errors useful 
in a number of programming languages and compilers including D.  
It allows for somewhat faster error fixing than the 
first-error-only reporting strategy - seen that, too, back in the 
Borland Pascal MS-DOS IDE and few other compilers.  I won't trade 
the extra benefit just for philosophical notions.
Dec 10 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 10 Dec 2014 10:36:22 +0000
Ivan Kazmenko via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Wednesday, 10 December 2014 at 02:15:04 UTC, ketmar via=20
 Digitalmars-d wrote:

 On Tue, 09 Dec 2014 17:28:15 +0000
 Ivan Kazmenko via Digitalmars-d <digitalmars-d puremagic.com>=20
 wrote:


 A well-designed language allows to recover from errors with=20
 good probability


 if compiler can recover from error, it should not report the=20
 error at
 all -- 'cause it can fix the code for me.

 that is absolutely nonsense, you *CAN'T* "recover" from invalid=20
 code.
 that is the fact. fact: Earth is not a sphere. fact: you can't
 automatically recover from invalid code.


=20
 That sounds much like an opinion, a lot less like a fact.  If you=20
 are willing to convince people, please provide some evidence,=20
 aside from another unrelated fact.


the ones who believes that recovery covers most of the cases should
bring proofs, not me. it's obvious that guessing on invalid input is
unreliable.


 In my experience, I find multiple reported compile errors useful=20
 in a number of programming languages and compilers including D. =20
 It allows for somewhat faster error fixing than the=20
 first-error-only reporting strategy - seen that, too, back in the=20
 Borland Pascal MS-DOS IDE and few other compilers.  I won't trade=20
 the extra benefit just for philosophical notions.


most of the bugs compiler reports can be catched by good IDE without
compiling the source at all. what's left is bugs where all hell breaks
loose due to things that can't be "recovered" (like missing brackets,
for example -- and ah, that can be catched by IDE too!), thus producing
a pool of vomit.

and with fast compiler there is no sense in vomiting, as you physically
can't edit two code fragments simultaneously, thus you *will* fix bugs
one by one. and "go to next bug" hotkey can simply invoke fast compiler
to get another error message.

last, but not least: "recovering" attempts increases parser complexity.
Dec 10 2014
parent reply "Ivan Kazmenko" <gassa mail.ru> writes:
On Wednesday, 10 December 2014 at 10:59:17 UTC, ketmar via 
Digitalmars-d wrote:

 that is absolutely nonsense, you *CAN'T* "recover" from 
 invalid code.
 that is the fact. fact: Earth is not a sphere. fact: you 
 can't
 automatically recover from invalid code.


 
 That sounds much like an opinion, a lot less like a fact.  If 
 you are willing to convince people, please provide some 
 evidence, aside from another unrelated fact.


 the ones who believes that recovery covers most of the cases 
 should
 bring proofs, not me. it's obvious that guessing on invalid 
 input is
 unreliable.


Fine, I don't have the hard proof at hand, since my 
compilation-error state programs don't tend to go into version 
control systems.  Perhaps I can track them too if such statistics 
can be shown to have some real value.

On the other hand, I'm fine with the current state, and without 
evidence from your side, it's not going to change.  So the 
inversion of who should bring proofs is also a false claim.
Dec 10 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 11 Dec 2014 05:56:23 +0000
Ivan Kazmenko via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On the other hand, I'm fine with the current state, and without=20
 evidence from your side, it's not going to change.  So the=20
 inversion of who should bring proofs is also a false claim.


it's not going to change even if god himself comes from the skies and
tell to do that. there always be some random reddit user who is far
superior.
Dec 11 2014
prev sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 08 Dec 2014 15:05:18 +0000
Jonathan Marler via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 What about 'usize' and 'ptrdiff' ?


`sptrdiff`, as i did it in my branch. `ssize` was just an example, i
don't like it too. yet `sptrdiff` is still ugly. why 'ptr', what it has
to do with pointers at all? why, for example, `indexOf()` returns
`ptrdiff_t`? btw, this is a bug, 'cause that means that i can't search
more than 2GB in 32-bit and get a sane result on hit, for example.

something like 'ssizediff' is slightly better, i think. we have no
explicit "ptr" type, and using `ptrdiff_t` when subtracting pointers
is wrong anyway (only `uptrdiff_t` can do there, but we already has
`usize` for it).

or, doing it *right* this time: just annihilate `ptrdiff_t`. it's
dangerous and useless.
Dec 08 2014
prev sibling next sibling parent reply "Ivan Kazmenko" <gassa mail.ru> writes:
On Monday, 8 December 2014 at 08:46:49 UTC, bearophile wrote:

 Freddy:


 Why not keep size_t implictly convertable but disallow it for
 usize.


 This is an interesting idea. (But the name "uword" seems 
 better).


The char, wchar (word char) and dchar (double word char) types 
seem to disagree.  The "word=2bytes" historical rule is rooted 
too deeply.  An "uword" will also be very confusing alongside 
lower level code (e.g. assembler).

Personally, when I face the need for a size_t, I usually can (and 
do) use auto instead.  And even if I have to spell it, I don't 
care too much how it's called, only whether it can be easily 
recognized.
Dec 08 2014
next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 08 Dec 2014 13:49:30 +0000
Ivan Kazmenko via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Monday, 8 December 2014 at 08:46:49 UTC, bearophile wrote:

 Freddy:


 Why not keep size_t implictly convertable but disallow it for
 usize.


 This is an interesting idea. (But the name "uword" seems=20
 better).


=20
 The char, wchar (word char) and dchar (double word char) types=20
 seem to disagree.  The "word=3D2bytes" historical rule is rooted=20
 too deeply.  An "uword" will also be very confusing alongside=20
 lower level code (e.g. assembler).
=20
 Personally, when I face the need for a size_t, I usually can (and=20
 do) use auto instead.  And even if I have to spell it, I don't=20
 care too much how it's called, only whether it can be easily=20
 recognized.


i bet that "woobooAAARGH" will be even easier to recognize than
"size_t". as there is no other types in D with "_t" suffix, you have to
remember that anyway, so it doesn't really matter which one to
remember. ;-)
Dec 08 2014
next sibling parent reply "Ivan Kazmenko" <gassa mail.ru> writes:
On Monday, 8 December 2014 at 14:31:50 UTC, ketmar via 
Digitalmars-d wrote:

 On Mon, 08 Dec 2014 13:49:30 +0000
 Ivan Kazmenko via Digitalmars-d <digitalmars-d puremagic.com> 
 wrote:

 Personally, when I face the need for a size_t, I usually can 
 (and do) use auto instead.  And even if I have to spell it, I 
 don't care too much how it's called, only whether it can be 
 easily recognized.


 i bet that "woobooAAARGH" will be even easier to recognize than
 "size_t". as there is no other types in D with "_t" suffix, you 
 have to
 remember that anyway, so it doesn't really matter which one to 
 remember. ;-)


Now that you say it, indeed the code won't be fancy if it goes 
like
     woobooAAARGH len = name.length;
I'll go with an auto here, or yet another type alias.

Perhaps I don't have strong feelings against size_t because I 
like old_c_style_variable_names more than theNewShinyCamelCase.  
It's just a personal preference.
Dec 08 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 08 Dec 2014 15:39:53 +0000
Ivan Kazmenko via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Monday, 8 December 2014 at 14:31:50 UTC, ketmar via=20
 Digitalmars-d wrote:

 On Mon, 08 Dec 2014 13:49:30 +0000
 Ivan Kazmenko via Digitalmars-d <digitalmars-d puremagic.com>=20
 wrote:

 Personally, when I face the need for a size_t, I usually can=20
 (and do) use auto instead.  And even if I have to spell it, I=20
 don't care too much how it's called, only whether it can be=20
 easily recognized.


 i bet that "woobooAAARGH" will be even easier to recognize than
 "size_t". as there is no other types in D with "_t" suffix, you=20
 have to
 remember that anyway, so it doesn't really matter which one to=20
 remember. ;-)


=20
 Now that you say it, indeed the code won't be fancy if it goes=20
 like
      woobooAAARGH len =3D name.length;
 I'll go with an auto here, or yet another type alias.


that is exactly the feeling `size_t` summons. it's unnatural for D.


 Perhaps I don't have strong feelings against size_t because I=20
 like old_c_style_variable_names more than theNewShinyCamelCase. =20
 It's just a personal preference.


i used both styles in C, one with underscores for last years. but here
i'm talking about consistency, the thing which D community tends to
ignore. having `uint`, `ulong` and `size_t` is inconsistent. it should
be either `uint_t`, `ulong_t` (and `usize_t` for that matter), or
`uint`, `ulong` and `usize`.

i really don't care if it will be '_t'-suffixed or not, i simply want
it to be consistent.
Dec 08 2014
prev sibling parent "Messenger" <no u.blarp> writes:
On Monday, 8 December 2014 at 14:31:50 UTC, ketmar via
Digitalmars-d wrote:


 Personally, when I face the need for a size_t, I usually can 
 (and do) use auto instead.  And even if I have to spell it, I 
 don't care too much how it's called, only whether it can be 
 easily recognized.


 i bet that "woobooAAARGH" will be even easier to recognize than
 "size_t". as there is no other types in D with "_t" suffix, you 
 have to
 remember that anyway, so it doesn't really matter which one to
 remember. ;-)


brb aliasing
Dec 09 2014
prev sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 08 Dec 2014 13:49:30 +0000
Ivan Kazmenko via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Monday, 8 December 2014 at 08:46:49 UTC, bearophile wrote:

 Freddy:


 Why not keep size_t implictly convertable but disallow it for
 usize.


 This is an interesting idea. (But the name "uword" seems=20
 better).


=20
 The char, wchar (word char) and dchar (double word char) types=20
 seem to disagree.  The "word=3D2bytes" historical rule is rooted=20
 too deeply.  An "uword" will also be very confusing alongside=20
 lower level code (e.g. assembler).
=20
 Personally, when I face the need for a size_t, I usually can (and=20
 do) use auto instead.  And even if I have to spell it, I don't=20
 care too much how it's called, only whether it can be easily=20
 recognized.


ah, well, there are `ptrdiff_t` and `hash_t`, both of the same
uglyness.
Dec 08 2014
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Monday, 8 December 2014 at 08:46:49 UTC, bearophile wrote:

 Freddy:


 Why not keep size_t implictly convertable but disallow it for
 usize.


 This is an interesting idea. (But the name "uword" seems 
 better).

 Bye,
 bearophile


As a legacy from 16-bit era word is ushort.
I use intp and uintp.
Dec 08 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 08 Dec 2014 16:03:42 +0000
Kagamin via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Monday, 8 December 2014 at 08:46:49 UTC, bearophile wrote:

 Freddy:


 Why not keep size_t implictly convertable but disallow it for
 usize.


 This is an interesting idea. (But the name "uword" seems=20
 better).

 Bye,
 bearophile


=20
 As a legacy from 16-bit era word is ushort.
 I use intp and uintp.


i think that `intp` and `uintp` is very good. a little hard to read
maybe (too similar to `int` and `uint`).
Dec 08 2014
prev sibling parent reply "Gary Willoughby" <dev nomad.so> writes:
On Monday, 8 December 2014 at 01:30:35 UTC, ketmar via 
Digitalmars-d wrote:

 Hello.

 i don't like `size_t`. for many month i avoied using it 
 wherever that
 was possible, 'cause i feel something wrong with it.


size_t is not too bad, it's not as alien as you may think as 
there is also std.stdint.

http://dlang.org/phobos/std_stdint.html

Personally i don't have any issue with the naming as long as i 
know what each type represents.
Dec 08 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 08 Dec 2014 17:33:48 +0000
Gary Willoughby via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Monday, 8 December 2014 at 01:30:35 UTC, ketmar via=20
 Digitalmars-d wrote:

 Hello.

 i don't like `size_t`. for many month i avoied using it=20
 wherever that
 was possible, 'cause i feel something wrong with it.


=20
 size_t is not too bad, it's not as alien as you may think as=20
 there is also std.stdint.
=20
 http://dlang.org/phobos/std_stdint.html


ah, nobody uses that, and it's not even documented. a forgotten
leftover.


 Personally i don't have any issue with the naming as long as i=20
 know what each type represents.


i can remember that too, but i prefer to have the things that i can
logically deduce. i can deduce `usize`: "ah, it's size. and it's
unsigned. D tends to add 'u' for unsigned types and naming 'size' as
'size' is logical. so it must be 'usize'. hit!"

i can't do that for `size_t`, though. the only thing i can do with it
is to remeber it. and i'm very bad in remembering nonsensical things.
Dec 08 2014
next sibling parent reply "Kagamin" <spam here.lot> writes:
On Tuesday, 9 December 2014 at 03:48:17 UTC, ketmar via 
Digitalmars-d wrote:

 i can remember that too, but i prefer to have the things that i 
 can
 logically deduce. i can deduce `usize`: "ah, it's size. and it's
 unsigned. D tends to add 'u' for unsigned types and naming 
 'size' as
 'size' is logical. so it must be 'usize'. hit!"


Size is unsigned for being positive. Why emphasize it again? 'u' 
prefix is for general purpose integers, size_t is a special 
purpose type for specific case of representing sizes, similar 
types are time_t, off_t and hash_t in a sense that representation 
can change, but purpose will remain the same.
Dec 09 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 09 Dec 2014 08:26:18 +0000
Kagamin via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Tuesday, 9 December 2014 at 03:48:17 UTC, ketmar via=20
 Digitalmars-d wrote:

 i can remember that too, but i prefer to have the things that i=20
 can
 logically deduce. i can deduce `usize`: "ah, it's size. and it's
 unsigned. D tends to add 'u' for unsigned types and naming=20
 'size' as
 'size' is logical. so it must be 'usize'. hit!"


=20
 Size is unsigned for being positive. Why emphasize it again?


to stop people think that they can safely subtract one size from
another. that 'u' will remind them.
Dec 09 2014
prev sibling parent reply "Gary Willoughby" <dev nomad.so> writes:
On Tuesday, 9 December 2014 at 03:48:17 UTC, ketmar via 
Digitalmars-d wrote:

 http://dlang.org/phobos/std_stdint.html


 ah, nobody uses that, and it's not even documented. a forgotten
 leftover.


I've just used it. It *is* part of phobos, albeit hidden.
Dec 09 2014
next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 09 Dec 2014 13:34:24 +0000
Gary Willoughby via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Tuesday, 9 December 2014 at 03:48:17 UTC, ketmar via=20
 Digitalmars-d wrote:

 http://dlang.org/phobos/std_stdint.html


 ah, nobody uses that, and it's not even documented. a forgotten
 leftover.


=20
 I've just used it. It *is* part of phobos, albeit hidden.


ok, we have one man using it. ;-)
Dec 09 2014
prev sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 09 Dec 2014 13:34:24 +0000
Gary Willoughby via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Tuesday, 9 December 2014 at 03:48:17 UTC, ketmar via=20
 Digitalmars-d wrote:

 http://dlang.org/phobos/std_stdint.html


 ah, nobody uses that, and it's not even documented. a forgotten
 leftover.


=20
 I've just used it. It *is* part of phobos, albeit hidden.


p.s. just out of curiousity: why do you need it? D int types has
well-defined size, so i can't see any sense in using C leftover.
Dec 09 2014
next sibling parent reply "Gary Willoughby" <dev nomad.so> writes:
On Tuesday, 9 December 2014 at 16:10:10 UTC, ketmar via 
Digitalmars-d wrote:

 p.s. just out of curiousity: why do you need it? D int types has
 well-defined size, so i can't see any sense in using C leftover.


I'm doing lots of pointer arithmetic so i've used uintptr_t in 
various places.
Dec 09 2014
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On 12/10/2014 1:55 AM, Gary Willoughby wrote:

 On Tuesday, 9 December 2014 at 16:10:10 UTC, ketmar via Digitalmars-d
 wrote:

 p.s. just out of curiousity: why do you need it? D int types has
 well-defined size, so i can't see any sense in using C leftover.


 I'm doing lots of pointer arithmetic so i've used uintptr_t in various
 places.


So you should be importing core.stdc.stdint directly. Pretend that 
std.stdint doesn't exist.
Dec 09 2014
parent "Gary Willoughby" <dev nomad.so> writes:
On Wednesday, 10 December 2014 at 01:21:58 UTC, Mike Parker wrote:

 So you should be importing core.stdc.stdint directly. Pretend 
 that std.stdint doesn't exist.


I am.
Dec 10 2014
prev sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 09 Dec 2014 16:55:22 +0000
Gary Willoughby via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Tuesday, 9 December 2014 at 16:10:10 UTC, ketmar via=20
 Digitalmars-d wrote:

 p.s. just out of curiousity: why do you need it? D int types has
 well-defined size, so i can't see any sense in using C leftover.


=20
 I'm doing lots of pointer arithmetic so i've used uintptr_t in=20
 various places.


ah, that one type. i was always wonder why it's missing in object.d[i].
but as `usize` is guaranteed to be big enough to hold the pointer and
`alias` doesn't create any new type, why don't just use
`usize`/`size_t`?
Dec 09 2014
prev sibling parent reply "bitwise" <bitwise.pvt gmail.com> writes:
 D devs are quite willing to improve error messages, they have 
 improved many of them.


I'm not trying to call anyone lazy ;) Sometimes though, the bugs 
I imagine I would submit seem like they would lead to a wild 
goose chase more than a solution.


 Don't forget to mention DustMite.


I'll definitely check this out.


 somehow Walter can't accept that after emiting the first error 
 compiler
 is in undefined state, and trying to pretend that it is in 
 well-defined
 state or guess what well-defined state must be is a nonsense.


I don't think I would call this nonsense. MSVC for example, often 
emits multiple errors correctly. I haven't checked this with 
MSVC, but I imagine an unidentified identifier could be a case 
where this is possible. Also, many intellisense systems are able 
to recover after multiple errors and continue parsing a file.

I suppose the rest of the errors could be generated on a second 
pass though. For example, if the first error was an unidentified 
identifier, the compiler could then re-parse the file and report 
all instances of that identifier's usage.


 D compiler is fast enough to stop that horrible "now you have
 100500 errors reported, enjoy" practice.


On the other hand, this sounds a lot like failed template 
instantiations in old versions of MSVC ;)


 the second thing that i want to have is compiler explaining why 
 it
 rejected some templates. i.e. what constrains failed. those 
 messages
 about "can't instantiate" are among the most noisy and cryptic 
 ones.


Yep.
Dec 09 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 09 Dec 2014 18:08:48 +0000
bitwise via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 somehow Walter can't accept that after emiting the first error=20
 compiler
 is in undefined state, and trying to pretend that it is in=20
 well-defined
 state or guess what well-defined state must be is a nonsense.


=20
 I don't think I would call this nonsense. MSVC for example, often=20
 emits multiple errors correctly. I haven't checked this with=20
 MSVC, but I imagine an unidentified identifier could be a case=20
 where this is possible. Also, many intellisense systems are able=20
 to recover after multiple errors and continue parsing a file.


so let "intellisense-like" systems do the guesswork. i don't trust a
compiler that tries to guess what i mean instead of reporting the error
and stop right there. i.e. i once tried PL/1 compiler which was able to
"guess" what lone `IF` means. and now i don't want the compiler to
do *ANY* guesswork. it's ok for support tools, but compiler should not
claim that it can "recover" from invalid code, 'cause invalid code
is... well... invalid and irrecoverable without manual human fixing.
and if it is "recoverable", why do i have to do any manual fixing at
all? if compiler is so smart, he should fix the code and go on.

see, you *CAN'T* recover from such error. even in D you can catch Error,
but program state is already undefined. in the case of compiler the
state of the compiler itself is defined, but input data is trashed. i
can't see any sense in trying to figure out something sane from trashed
input. let the user fix the input instead of guessing.
Dec 09 2014
parent reply "bitwise" <bitwise.pvt gmail.com> writes:
 so let "intellisense-like" systems do the guesswork. i don't 
 trust a
 compiler that tries to guess what i mean instead of reporting 
 the error
 and stop right there. i.e. i once tried PL/1 compiler which was 
 able to
 "guess" what lone `IF` means. and now i don't want the compiler 
 to
 do *ANY* guesswork.


I probably should have started my own thread ;)

Anyways, this video is a couple of years old, but this is how 
Clang does what I'm talking about, around 16:00 minutes in.

http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Clang-Defending-C-from-Murphy-s-Million-Monkeys
Dec 09 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 10 Dec 2014 03:00:56 +0000
bitwise via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 so let "intellisense-like" systems do the guesswork. i don't=20
 trust a
 compiler that tries to guess what i mean instead of reporting=20
 the error
 and stop right there. i.e. i once tried PL/1 compiler which was=20
 able to
 "guess" what lone `IF` means. and now i don't want the compiler=20
 to
 do *ANY* guesswork.


=20
 I probably should have started my own thread ;)


ah, no, this thread is fine too. ;-) this thread is not strictly about
"size_t", it's about inconsistencies and legacies in D.


 Anyways, this video is a couple of years old, but this is how=20
 Clang does what I'm talking about, around 16:00 minutes in.
=20
 http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Clang-Defend=


ing-C-from-Murphy-s-Million-Monkeys
as i can understand from my limited "english hearing skills" ;-), this
is about guessing identifiers, right? another feature i found useless.
i even patched my DMD to stop suggesting me that BS, it's so annoying.
i want command-line argument to stop DMD doing that!
Dec 09 2014