By numerous reports the world is ditching 32 bit for good:

https://www.androidauthority.com/arm-32-vs-64-bit-explained-1232065/

There's significant effort needed in the dmd source code to accommodate 32 bit builds, which nobody should use.

Ditch?

On Wednesday, 16 June 2021 at 17:59:06 UTC, Andrei Alexandrescu wrote:
> By numerous reports the world is ditching 32 bit for good:
>
> https://www.androidauthority.com/arm-32-vs-64-bit-explained-1232065/
>
> There's significant effort needed in the dmd source code to accommodate 32 bit builds, which nobody should use.
>
> Ditch?

A good time to do this would be when the minimally supported Windows version is bumped to a version which does not have a 32-bit edition.

Until then, probably not.

On Wednesday, 16 June 2021 at 17:59:06 UTC, Andrei Alexandrescu wrote:
> By numerous reports the world is ditching 32 bit for good:
>
> https://www.androidauthority.com/arm-32-vs-64-bit-explained-1232065/
>
> There's significant effort needed in the dmd source code to accommodate 32 bit builds, which nobody should use.
>
> Ditch?

Ditch dmd completely.

On Wednesday, 16 June 2021 at 18:52:52 UTC, IGotD- wrote:
> On Wednesday, 16 June 2021 at 17:59:06 UTC, Andrei Alexandrescu wrote:
>> By numerous reports the world is ditching 32 bit for good:
>>
>> https://www.androidauthority.com/arm-32-vs-64-bit-explained-1232065/
>>
>> There's significant effort needed in the dmd source code to accommodate 32 bit builds, which nobody should use.
>>
>> Ditch?
>
> Ditch dmd completely.

+100500

On Wednesday, 16 June 2021 at 17:59:06 UTC, Andrei Alexandrescu wrote:
> By numerous reports the world is ditching 32 bit for good:
>
> https://www.androidauthority.com/arm-32-vs-64-bit-explained-1232065/
>
> There's significant effort needed in the dmd source code to accommodate 32 bit builds, which nobody should use.
>
> Ditch?

Perhaps we can start by ditching the schedulers for Pentium chips from the 90s - even charitably (i.e. The P6 architecture did live for a while) it's obsolete (and more importantly not needed for supporting those targets). That way we gain experience pressing delete rather than making the code dead and leaving it, and we reduce the surface area of old/dead code which could be silently broken if other things change around it.

Andrei, you may recall this was discussed in a meeting gone by, and Walter seemed to agree in principle to some changes (this one wasn't discussed) to the older parts of the compiler.

On Wednesday, 16 June 2021 at 17:59:06 UTC, Andrei Alexandrescu wrote:
> By numerous reports the world is ditching 32 bit for good:
>
> https://www.androidauthority.com/arm-32-vs-64-bit-explained-1232065/
>
> There's significant effort needed in the dmd source code to accommodate 32 bit builds, which nobody should use.
>
> Ditch?

No, I don't think that's a good idea.

Ditching x86-32 as a host platform should not benefit much. The compiler is written in D after all, it's not like it's hard to keep a program compiling for different architectures.

Ditching x86-32 as a target platform would be ditching a platform that's still in wide use for a long time. From the article you linked to: "For other CPU architectures and other OS’s, like Windows and Linux, then 32-bit support will survive much longer. Since Linux wants to be everyone’s friend, then 32-bit support is likely to stay for decades to come". 32-bit might not be very relevant for desktop computers or phones anymore, but there is also IoT, and D is supposed to be a general-purpose language after all.

On 6/16/2021 10:59 AM, Andrei Alexandrescu wrote:
> There's significant effort needed in the dmd source code to accommodate 32 bit builds,

Not sure I agree with that. Besides, it's just good practice to not fall into the trap of assuming size_t is 8.

On 6/16/2021 2:38 PM, max haughton wrote:
> Perhaps we can start by ditching the schedulers for Pentium chips from the 90s - even charitably (i.e. The P6 architecture did live for a while) it's obsolete (and more importantly not needed for supporting those targets). That way we gain experience pressing delete rather than making the code dead and leaving it, and we reduce the surface area of old/dead code which could be silently broken if other things change around it.

At one point, Intel did release a low power 32 bit chip for embedded systems that benefited quite a bit from the Pentium scheduler, as that chip had sacrificed its own internal scheduler.

Besides, the bugs have been sorted out from that scheduler long ago. It's not impairing anyone.