Is there a way to tell D to rearrange struct members or to not rearrange class members?

[Lance Bachmeier]

On Saturday, 28 June 2025 at 15:20:44 UTC, WraithGlade wrote:

> There are very few imposed structural "best practices" that are 
> genuinely universal in my experience. Good naming of variables 
> would be a rare example of a universally good practice, in my 
> opinion, but in contrast even pervasive and nearly universally 
> advocated systems (such as OOP for many years in the past few 
> decades) have turned out (from a deeper language design 
> perspective) to ultimately be riddled with false assumptions 
> and thus the structure imposed by such systems when reified and 
> scaled up to real software systems has often caused more harm 
> than good.

I tend to agree. John Hughes wrote in his famous [Why Functional 
Programming 
Matters](https://www.cse.chalmers.se/~rjmh/Papers/whyfp.pdf)

> If omitting assignment statements brought such enormous 
> benefits then Fortran programmers would have been doing it for 
> twenty years. It is a logical impossibility to make a language 
> more powerful by omitting features, no matter how bad they may 
> be.

> Even a functional programmer should be dissatisfied with these 
> so-called advantages, because they give no help in exploiting 
> the power of functional languages.

> It’s helpful to draw an analogy between functional and 
> structured programming. In the past, the characteristics and 
> advantages of structured programming have been summed up more 
> or less as follows. Structured programs contain no goto 
> statements. Blocks in a structured program do not have multiple 
> entries or exits. Structured programs are more tractable 
> mathematically than their unstructured counterparts. These 
> “advantages” of structured programming are very similar in 
> spirit to the “advantages” of functional programming we 
> discussed earlier. They are essentially negative statements, 
> and have led to much fruitless argument about “essential gotos” 
> and so on.

> With the benefit of hindsight, it’s clear that these properties 
> of structured programs, although helpful, do not go to the 
> heart of the matter. The most important difference between 
> structured and unstructured programs is that structured 
> programs are designed in a modular way. Modular design brings 
> with it great productivity improvements.

> The absence of gotos, and so on, has very little to do with 
> this.

If the only thing you can say is "that's bad practice" then you 
don't have a sensible argument. It's no better than proof by 
example. "It holds in these six examples, QED." The designer of a 
language doesn't have the knowledge required to universally 
declare something a bad practice that should be avoided. The 
language spec is not a linter and it shouldn't be a substitute 
for code review and sensible programming practice.