On Mon, Feb 12, 2024 at 07:34:36PM +0000, bachmeier via Digitalmars-d-learn
wrote:
> On Monday, 12 February 2024 at 18:22:46 UTC, H. S. Teoh wrote:
>
> > Honestly, I think this issue is blown completely out of proportion.
>
> Only for people that don't have to deal with the problems it causes.
I've run into size_t vs int issues many times. About half the time it
exposed fallacious assumptions on my part about value types. The other
half of the time a simple cast or std.conv.to invocation solved the
problem.
My guess is that most common use of .length in your typical D code is in
(1) passing it to code that expect a length for various reasons, and (2)
in loop conditions to avoid overrunning a buffer or overshooting some
range. (1) is a non-problem, 90% of (2) is solved by using constructs
like foreach() and/or ranges instead of overly-clever arithmetic
involving length, which is almost always wrong or unnecessary. If you
need to do subtraction with lengths, that's a big red flag that you're
approaching your problem from the wrong POV. About the only time you
need to do arithmetic with lengths is in low-level code like allocators
or array copying, for which you really should be using higher-level
constructs instead.
> > D decided on an unsigned type. You just learn that and adapt your
> > code accordingly, end of story. Issues like these can always be
> > argued both ways, and the amount of energy spent in these debates
> > far outweigh the trivial workarounds in code, of which there are
> > many (use std.conv.to for bounds checks, just outright cast it if
> > you know what you're doing (or just foolhardy), use CheckedInt,
> > etc.).
>
> A terrible language is one that makes you expend your energy thinking
> about workarounds rather than solving your problems. The default
> should be code that works. The workarounds should be for cases where
> you want to do something extremely unusual like subtracting from an
> unsigned type and having it wrap around.
Yes, if I had my way, implicit conversions to/from unsigned types should
be a compile error. As should comparisons between signed/unsigned
values.
But regardless, IMNSHO any programmer worth his wages ought to learn
what an unsigned type is and how it works. A person should not be
writing code if he can't even be bothered to learn how the machine
that's he's programming actually works. To quote Knuth:
People who are more than casually interested in computers should
have at least some idea of what the underlying hardware is like.
Otherwise the programs they write will be pretty weird. -- D.
Knuth
One of the reasons Walter settled on size_t being unsigned is that this
reflects how the hardware actually works. Computer arithmetic is NOT
highschool arithmetic; you do not have infinite width nor infinite
precision, and you're working with binary, not decimal. This has
consequences, and having the language pretend the distinction doesn't
exist does not solve any problems.
If an architectural astronaut works at such a high level of abstraction
that he doesn't even understand how basic things about the hardware,
like how uint or ulong work and how to use them correctly, maybe he
should be promoted to a managerial role instead of writing code.
T
--
You are only young once, but you can stay immature indefinitely. -- azephrahel
