Why can't we derive struct's?

[H. S. Teoh]

On Mon, Dec 24, 2018 at 02:30:57PM -0800, Walter Bright via Digitalmars-d wrote:
> On 12/24/2018 1:31 PM, H. S. Teoh wrote:
[...]
> > 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.

Ah well, just because something is a nice piece of engineering, doesn't
necessarily mean it was a good idea in the first place!


> 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.

I used to have a code library that standardized on throwing char* to
string literals. It was a lazy man's way of having error messages that
masqueraded as error codes / exceptions.  Not my proudest moment of
software design. :-D

Though I'll say that the primary motivation for that was my C
background, where everything is an int error code, and my being utterly
fed up with code that just returned a non-descript -1 on every kind of
failure, or worse, returning the return value of another function that
returns an *incompatible* range of int error codes, in a totally
inconsistent way (e.g., sometimes the function would return -1, or
ERR_XYZ where ERR_* is a series of error codes defined in module A, and
sometimes returning errno, which is incompatible with module A's error
codes, all jammed into a single int return that the caller could not
possibly hope to unambiguously decipher).  Worst of all, when a problem
occurred I'd get a message like "error -123" with zero hint as to what
-123 even means.  Having char* as an error code instead ensured (1)
there's always a human-readable message you can get out of it, even if
you couldn't otherwise interpret it; (2) since char* is unique in the
space of string literals, you can freely mix error code returns and not
have to worry about ambiguities (the dynamic linker will even "remap
error codes" for you so errors from multiple libraries will never be
confused for one another); (3) no memory allocation is needed -- at
least if you stick to my scheme of returning only string literals.

Of course, there are other issues with such a design, but it seemed like
a good idea at the time.


[...]
> > 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.

I haven't been keeping up with C++ in any serious way ever since I found
D; what's the replacement for iostreams these days?  Or is it yet
another one of those Irreversible Historical Accidents that's here to
stay, in spite of acknowledged flaws, to be patched over by Yet More
Language Complications that will make the language require a PhD
specializing in C++ just so you can write correct code, since the
"obvious" way to write C++ is wrong in more ways than you even knew
existed?


> 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" (!).

Unfortunately, all of those points conflict with each other at some
level, and it's not immediately obvious which blend of them represents
the best balance.


T

-- 
VI = Visual Irritation