Blog post: What D got wrong

[Jonathan M Davis]

On Tuesday, December 18, 2018 7:02:43 PM MST H. S. Teoh via Digitalmars-d-
announce wrote:
> On Tue, Dec 18, 2018 at 06:53:02PM -0700, Jonathan M Davis via
> Digitalmars-d-announce wrote: [...]
>
> > I confess that I do tend to think about things from the standpoint of
> > a library designer though, in part because I work on stuff like
> > Phobos, but also because I tend to break up my programs into libraries
> > as much as reasonably possible. In general, the more that's in a
> > reusable, easily testable library the better. And with that approach,
> > a lot less of the code for your programs is actually in the program
> > itself, and the attributes tend to matter that much more.
>
> [...]
>
> My recent programming style has also become very library-like, often
> with standalone library-style pieces of code budding off a messier,
> experimental code in main() (and ultimately, if the project is
> long-lasting, main() itself becomes stripped down to the bare
> essentials, just a bunch of library components put together).  But I've
> not felt a strong urge to deal with attributes in any detailed way;
> mostly I just templatize everything and let the compiler do attribute
> inference on my behalf. For the few cases where explicit attributes
> matter, I still only use the bare minimum I can get away with, and
> mostly just enforce template attributes using the unittest idiom rather
> than bother with writing explicit attributes everywhere in the actual
> code.

That works when you're in control of everything and not making libraries
public, but it tends to be worse when you're making stuff publicly
available, because then there's a much higher risk of accidentally screwing
up someone else's code by breaking an attribute. It's also much worse from a
documentation standpoint, because users of the library can't look at the
documentation to know which attributes are in effect. That's pretty much
unavoidable with heavily templated code, but there are generally going to be
fewer maintainence problems with a publicly available library if attributes
are explicit. And the more heavily used the library is, the more likely it
is that there are going to be problems.

It's like how if you want your library to be stable with regards to CTFE,
you pretty much have to test that CTFE works in your unit tests. It's easy
to forget, and ideally, you wouldn't have to worry about it, but if someone
else uses your library and uses one of its functions with CTFE, and you then
make a change that doesn't work with CTFE and don't realize it, you'll break
their code. Ideally, you wouldn't have to worry about ensuring that stuff
works with CTFE (after all, D specifically doesn't require that stuff be
marked to work with it), but with regards to publicly available libraries,
if it's not tested for, it can become a problem. So, arguably, it's best
practice to test that stuff works with CTFE (at least in publicly available
libraries), but I doubt that all that many libraries actually do it. And
attributes are in the same boat in many respects (especially if attribute
inference is used heavily).

But again, if you're not making stuff publicly available, it's usually easy
to just not worry about attributes (or CTFE-ability) except in those cases
where you have to or decide that you need to in order to ensure that a
particular attribute and its benefits are in effect. It's when you make
stuff publicly available that it becomes more of an issue - especially if
the library is heavily used.

- Jonathan M Davis