Why can't we derive struct's?

Rubn where at is.this
Tue Dec 25 02:43:14 UTC 2018

On Tuesday, 25 December 2018 at 00:40:13 UTC, H. S. Teoh wrote:
> 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

Being able to and not having a reason to do it are two different 
things. Someone is going to find a reason to use it and abuse it. 
Sure you can't overload equality and comma operators, but you can 
overload just about every other operator.

You can easily make the "+" operator do something entirely 
different than addition. Same with any of the other operators. 
They can be used with any other type and can output any unrelated 
type they wish. That's not going to stick out like a sore thumb, 
and it isn't that much more difficult to do. I wouldn't exactly 
call this designing an "interface" as it isn't really an 
interface so much as a feature. I wouldn't say "correct" and 
"wrong". There's a lot of things in D that are the "correct" way 
to do something but are incredibly difficult to do and results in 
messy code. As an example, until very recently you had to write a 
hack if you wanted to deprecate a single enum value. More 
accurate words to use would be something a long the lines of 
"intended design". I mean I could bring up auto-decoding as well, 
would you say that's the "correct" way or merely the "intended 
design" falling flat on its' face ending up being incorrect.

More information about the Digitalmars-d mailing list