Why can't we derive struct's?

H. S. Teoh hsteoh at quickfur.ath.cx
Tue Dec 25 00:40:13 UTC 2018


On Tue, Dec 25, 2018 at 12:15:58AM +0000, Rubn via Digitalmars-d wrote:
> On Monday, 24 December 2018 at 19:57:50 UTC, Walter Bright wrote:
[...]
> > Or like operator overloading. C++ has much more expansive rules for
> > operator overloading. They lead to clever programs, and some people
> > swear by them, but are they *better* programs? For example,
> > 
> > * iostreams
> > 
> > * regex DSL https://pdfs.semanticscholar.org/e630/5f84bca36251fd5a4ffa5f00e0effc8aaa7d.pdf
> > 
> > ? I don't buy it. I've never seen an elegant use of the more
> > expansive power (even though many insist those two examples are
> > elegant).
> 
> I feel like D's operator overloading can be equally abused as C++'s
> operator overloading. There just aren't people doing that with D
> (yet).

Many things *can* be abused, but aren't because there's little reason
to.

D forces you to use opEquals / opCmp for overloading the comparison
operators, so at least the behaviour will be (somewhat) consistent no
matter how you abuse it.  There's also no comma operator for you to
abuse.  The arithmetic operators can still be abused, but there are also
better and easier ways of achieving equivalent results by other means in
D, so there's not much incentive to do something like that.

For example, compile-time regexes can be achieved by using string
mixins, retaining normal regex syntax, so there's not much reason to
abuse arithmetic operators with unnatural syntax, just so you can
implement compile-time regexes.

While << and >> can theoretically still be overloaded iostream-style, D
already removed one of the main motivations for ditching C's stdio.h,
namely, that the various printf functions are variadic in a non-typesafe
way. D actually has 3 different ways of achieving variadic functions,
the most common of which is based on variadic templates and completely
type-safe.  Although some people are not a fan of std.format, it does
serve its purpose, and has also been extended in powerful new ways in D
(cf., the %(...%) array formatter). There's also the built-in ~
concatenation operator, which can be used for concatenating output
strings, and std.conv.text, which formats a list of stuff, so there's
less reasons for iostream-style << and >>.  Not to mention UFCS, which
could be used for chaining output function calls without needing to
overload any operators, plus, combined with range-based code, gives you
powerful new ways of writing I/O code that essentially marginalizes the
utility of iostream-style code.

So yeah, it's still *possible* to abuse operator overloading in D, but
the incentives for doing that are pretty low, and there are many other
nicer features with higher incentives that people are more liable to use
instead.  It's reminiscient of Walter's Boeing thing, about designing
interfaces such that the way people are most likely to use it also
happens to be the correct way, whereas the wrong way of doing things
requires more effort and/or sticks out like a sore thumb, so people are
less likely to attempt it.


T

-- 
They pretend to pay us, and we pretend to work. -- Russian saying


More information about the Digitalmars-d mailing list