May 21

On Wednesday, 21 May 2025 at 18:19:19 UTC, Walter Bright wrote:

>

An unsigned type is of less utility in a language like Java that is not a systems programming language (trying to make a memory allocator with no unsigned types is going to wind up pretty ugly).

Doubtful. Previously this prejudice reached the point where cryptography was declared impossible in java due to absence of unsigned integers.

May 21
On Wednesday, 21 May 2025 at 04:44:35 UTC, Walter Bright wrote:
> 1. use `size_t` for all indices and pointer offsets
>
> 2. use `ptrdiff_t` for all deltas of the form `size_t - size_t`

Thanks for that advice!

> [...]
> You could also do this:
> ```d
> foreach_reverse(ptrdiff_t i, v; messages) // messages is a string array
> {
>     float vpos = 600 - 30 * i;
>     DrawText(messages.ptr, 100, vpos.to!int, 20, Colors.WHITE);
> }
> ```
> but one could argue it's a bit too clever.

Looks okay. Or is the `reverse` part of the cleverness? I mean the
ordinary (forward) foreach also seem to work.
May 21
In my not-so-humble opinion, every cast is a bug, as it breaks the type system.

I posted an example that showed how this particular problem can be dealt with without casting.
May 21
On 5/21/2025 12:24 PM, Derek Fawcus wrote:
> "After much discussion, the Committee decided in favor of value preserving rules, despite the fact that the UNIX C compilers had evolved in the direction of unsigned preserving."

At that time, 90% of C programming was done on DOS, not Unix. And there were a lot of value preserving compilers.
May 21
On Wednesday, 21 May 2025 at 20:53:13 UTC, Walter Bright wrote:
> every cast is a bug,

How do you make fast inverse sqrt, sumtypes, allocators?


May 21
On 5/21/2025 12:43 PM, kdevel wrote:
> On Wednesday, 21 May 2025 at 04:44:35 UTC, Walter Bright wrote:
>> but one could argue it's a bit too clever.
> 
> Looks okay. Or is the `reverse` part of the cleverness? I mean the
> ordinary (forward) foreach also seem to work.

It's "clever" because it isn't clear why it is structured this way.
May 21
On 5/21/2025 3:00 PM, monkyyy wrote:
> On Wednesday, 21 May 2025 at 20:53:13 UTC, Walter Bright wrote:
>> every cast is a bug,
> 
> How do you make fast inverse sqrt, sumtypes, allocators?

You call it @system code!

May 22

On Wednesday, 21 May 2025 at 23:07:20 UTC, Walter Bright wrote:

>

On 5/21/2025 12:43 PM, kdevel wrote:

>

On Wednesday, 21 May 2025 at 04:44:35 UTC, Walter Bright wrote:

>

but one could argue it's a bit too clever.

Looks okay. Or is the reverse part of the cleverness? I mean the
ordinary (forward) foreach also seem to work.

It's "clever" because it isn't clear why it is structured this way.

It's so clever, in fact, that it doesn't work. I'll let you discover why.

-Steve

May 22

On Wednesday, 21 May 2025 at 20:53:13 UTC, Walter Bright wrote:

>

In my not-so-humble opinion, every cast is a bug, as it breaks the type system.

The problem isn't the cast, the problem is that is the tool D gives you to use for this kind of thing.

I somewhat agree -- I do not like pulling out cast for things like this. But the alternative is horrible (type constructor + bitwise and).

I think std.conv probably should have a truncate function that does the right thing.

-Steve

May 23
On 5/21/2025 6:27 PM, Steven Schveighoffer wrote:
> It's so clever, in fact, that it doesn't work. I'll let you discover why.

LOL, you're right. While the types are correct, the wrap around still makes it wrong.

BTW, if you typed everything but the float as `int`, you still have the same problem. It's not the unsigned conversion that is wrong.