H. S. Teoh 
Posted in reply to Brother Bill
| 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.
|
Permalink
Reply
