Why can't we derive struct's?

[Walter Bright]

On 12/24/2018 1:31 PM, H. S. Teoh wrote:

There are technical problems with iostreams as well, such as formatting options, 
and not being multi-threadable.


> And the regex DSL is just ... wow. It takes operator overloading abuse
> to whole new levels never before imagined.

I've talked to David Abrahams about it. It is a nice piece of engineering, and 
he's very proud of it. But I was right in my assessment of the abuse of operator 
overloading, as this sort of thing has just never caught on in the C++ community.

Another in the "too much power" category is you can throw any type in C++. Such 
as an `int`. I've never, ever seen any credible use of that. I'm not in the 
least surprised that the C++ standard library has an Exception class you're 
supposed to derive from and throw that.


> This kind of every-man-for-himself operator overloading leads to
> unmaintainable code where any piece of syntax can mean absolutely
> *anything*, because you can overload anything and everything, and you
> cannot even remotely begin to guess what a piece of code actually does
> just by looking at it.  You might have had a fighting chance if you
> could only trace the calls to their call targets, but thanks to the
> lovely C++ blend of overload resolution rules, Koenig lookup, SFINAE,
> and implicit conversions, you need to be a language lawyer just to
> figure that out.

Yeah, that about sums up my argument to David about it.


> But I suppose we should count our blessings, that the iostream authors
> didn't choose to overload < and > for I/O instead of << and >> (which
> you absolutely could, if you're bent on writing bad code), so there
> remains something to be appreciated here, I guess.</sarcasm>

I hated iostreams since the 1980s, but it took about 15 years for the C++ 
community to gradually come around to the idea that it was a mistake.

A feature shouldn't be merely "cool" or "great", especially considering all the 
features D already has. It needs to enable significantly better code to be 
written. Better as in more efficient, more understandable, safer, less brittle, 
less tendency for errors, etc. Note that I didn't say "less typing" (!).