Properties

[dsimcha]

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)
> Well I'm not so sure about that. In fact I'd go as far as saying you're
> contradicting yourself. The cruft and baggage is exactly left by
> unsuccessful language features that had to stay because, well, they were
> IN the language. For a good while, C++ has been rather liberal in
> adopting new and risky language features (exceptions, multiple
> inheritance, templates...) In contrast, for most of its existence, C++
> has had an extremely thin library. An example of a bad library from the
> old days is iostreams, but hardly anyone considers that a major issue.
> It's not cruft and it's not baggage. It just sucks. :o)
> So your own logic inexorably leads to a conclusion opposite to your
> hypothesis: it's best to keep the language lean and keep one's options
> open, lest cruft and baggage will accumulate.
> Of course that, taken to an extreme, can lead to contortions and can do
> more harm than good. So moderation is likely the best way to go.

I will admit that cruft and baggage were probably poor word choices to describe
what I meant.  I really meant things like odd syntax and weird corner cases caused
by not having the core language know about very basic, frequently used things like
arrays and strings.

> > The flip side is that, the more you rely on libraries (whether your personal
> > snippet library or an "official" library) that use hacks like this, the more
> > you're building a house of cards.
> That's a bit odd. Are you saying that libraries are inherently less
> reliable than language features?

In a way, yes.  When building a feature into a language, you can do literally
*anything* that is computationally feasible, such as define new syntax, make the
compiler "know" about the feature at a high level, display good high-level error
messages, etc.  When you're defining something in a library, you're limited by
existing constructs.  Sometimes those existing constructs are enough to do what
you want cleanly and elegantly.  Sometimes (as in the OP's example) you have to
resort to hacks.  My point is that, when you have a low-level library feature A
that's kind of a hack and does strange things in certain edge/error/unanticipated
cases, and then you build a high-level library feature B on top of A using still
more hacks, what are the odds that if something goes wrong with B, anyone will
have any clue why?  What are the odds that B won't have some frustrating,
arbitrary limitations?

> > When you build hacks on top of other hacks, and
> > build these on top of still more hacks (think STL), you're basically asking ugly
> > syntax, odd corner cases, and the exposure of obscure implementation bugs.  This
> > is why things like arrays, strings and delegates belong in the core language.
> > Since properties are just as universal, I believe the same argument can be made
> > for them.
> When I "think STL" I'm thinking of the best-defined library of general
> containers and algorithms. No other library I know goes to a longer
> length at defining its own behavior. Knowing STL makes me look with a
> rather critical eye at the loosely-defined libraries that accomplish
> (often sloppily) similar tasks usually featured with other languages.
> Andrei

Yes, STL (and Boost, etc.) are very high-quality libraries.  The problem is that,
because the core language doesn't "understand" anything in them, there's no
shortage of things like clumsy syntax, inscrutible error messages for the tiniest
errors, etc.  This is not to say that all, or even most, of STL or Boost belong in
the core C++ language, just the features that are both heavily used and would
benefit greatly from the core language "understanding" them.