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

[H. S. Teoh]

On Fri, Sep 12, 2025 at 06:19:46PM +0000, Brother Bill via Digitalmars-d-learn wrote:
[...]
> 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.?

The best way to learn D for a beginner is really just to start using
it.  D was designed to be "correct by default", and IMO it succeeds in
this for the most part.  This means that the most straightforward way to
write something is almost always the correct way.


[...]
> 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.

Exactly.  And that is why you should just start writing D.  You will
pick up the rest as you go along.


[...]
> 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.

For the most part, straightforward D code will Just Work(tm).
Generally, the simpler it looks, the more likely it's correct.  If your
code is starting to gather all sorts of paraphrenalia and it's starting
to sprout hairs, it probably means you're not using D the way it was
intended.


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

If you want to know my honest opinion: don't use @disable at all.  It
was added because some big D users clamored for it and possibly
threatened to leave D otherwise, and Walter yielded.  IMNSHO it's a
misfeature that goes against the grain of D.  This is why it has all
sorts of troublesome and strange corner-case behaviours.  In the early
days when it caused all sorts of problems with Phobos because just about
every other function assumed .init exists and is a valid instance of a
generic type T.  Generic code used .init everywhere to get an instance
of any type the user may throw at it, and used this for temporary
storage, introspection, adaptation, etc..  Life was good.  Everything
worked in every combination, and everyone was happy.  (Well, *almost*
everyone. :-P  Obviously, those who clamored for @disable had "very
good" reasons for it.)  Then @disable showed up, and everybody's soup
was ruined.  We spent years cleaning up the ensuing mess, and I doubt if
even today we have finished cleaning everything up yet.  I'm certain
almost you will find any number of (b0rken) interactions between
@disable and other long-time language features if you looked hard
enough.  If it were up to me, I'd avoid it like the plague.

(Unless the situation absolutely, indubitably, undeniably. and
unavoidably calls for it, and there are no other workarounds at your
disposal.)

Remember, D was designed to make D code look concise and pretty.  The
most obvious way to write something is most likely the correct way to do
it.  If a piece of D code looks like it fell in boilerplate mud and came
out growing attribute hairs where there shouldn't be any, it's almost
certain that it's either wrong, badly written, going against the way D
was intended to be used, or all of the above.  (This applies to Phobos
code as well, BTW.  Most of it is to work around misfeatures that got
shoehorned into the language without being aware of the unintended
interactions with other features.  In the early days, Phobos code was
legendary for being a standard library that didn't make your head hurt
when you read it. (If you've ever tried reading the source code for
Glibc, or the standard library for almost any other language, really,
you'll know what I mean.)  It was exemplary of how D code ought to be
written.  It probably still is today to some extent, though sadly over
the years it has fallen into the mud and come out hairy on multiple
occasions, so it ain't as pretty as it used to be anymore.)


T

-- 
"640K ought to be enough" -- Bill G. (allegedly), 1984. "The Internet is not a primary goal for PC usage" -- Bill G., 1995. "Linux has no impact on Microsoft's strategy" -- Bill G., 1999.