Preventing .init for Archive struct, Programming in D, page 295

[Brother Bill]

On Friday, 12 September 2025 at 15:38:15 UTC, Monkyyy wrote:
> On Friday, 12 September 2025 at 15:31:37 UTC, Brother Bill 
> wrote:
>> On Friday, 12 September 2025 at 15:24:46 UTC, Monkyyy wrote:
>>> On Friday, 12 September 2025 at 15:20:38 UTC, Brother Bill 
>>> wrote:
>>>> Is is possible to 'disable' .init for a struct?
>>>
>>> No (and honestly it's bad style to break the constructors)
>>
>> Please expound on why its 'bad style' to disable constructors.
>> Would you accept that disabling postblit may be the exception?
>
> Minor exceptions in type api creates hell inside nested 
> metaprogramming and your clever scheme isnt going to be worth 
> the trade off of making users learn your system for modifying 
> the data.
>
> Plain old data forever

As a newbie to D, really trying to understand it, I am merely 
trying to uncover how to effectively use D.  When Programming in 
D book, page 292, section 52.4 talks about 'postblit', it states: 
"If the postblit is defined for a type, the copy constructor is 
disabled."  I can imagine that a D developer who forgot this 
'legacy feature' might be frustrated when the expected copy 
constructor is disabled.

Is there a 'style' guide for D, such as: Do this, Don't do that, 
avoid this, etc.?
I recall Bertrand Meyer criticizing C++ by saying (paraphrased): 
"There are these features in the language, but you should avoid 
them, unless absolutely necessary", and then saying how many 
developers use language features when unnecessary?

I am trying to understand the clean way of using D.  I would not 
expect that every D developer be expected to have read and 
understood every line of the D specification.
This seems to be something that a D developer should know about.

What do you recommend as the way for a newbie D developer to 
master the power of D, while avoiding going down the rabbit hole, 
and wondering why things don't work.

Most computer languages, such as Eiffel, don't even consider 
adding this feature of preventing construction.
Clearly, D has them for 'good' reasons.

Perhaps I am looking at D 'through the looking glass', rather 
through a better approach.