So Don, I agree with you completely that C++ is a rather poor intro language (it can be a bear of a development language as well unless you can justify the performance gains). If you were king, which language(s) would you choose and why?

Lua is the best introductory programming language. Fact.

Well, any programming language that I know of has its quirks, and it's possible to write bad code in all of them. The issue you highlight should yield a compiler warning however, so I'm not entirely sure that this qualifies as a case in point for C++ being a bad language for beginners.

I agree this is painful, and like you I would not recommend C++ to students as a first programming language. However, as I work with C++ and run into things like these, I find looking at what the standard says to be somewhat helpful in cases like these. Often more so than library files. For example, for this particular issue, it looks like X::size_type itself is baked into the specification of C++, just like size_t. The fact that size_type for std::string resolves to size_t seems to be an implementation detail in itself. I could be wrong, but it looks like size_type for all types (std::string included) is defined as a part of allocator_traits, and they specify: "X::size_type: unsigned integer type a type that can represent the size of the largest object in the allocation model." Of course, having to look and half-understand the standard for someone new to C++ is unreasonable, and it is possible it doesn't match what the compiler does. But looking at standard library implementation files could be misleading as well (besides painful).

C and C++ are rather low level, so they definitely need a little bit more experience, but bad code can be written in any language. I would rather choose Python, Ruby or Lua as an introductory language.

"[...] the negative number is silently converted into a very large positive number. No warnings, no errors." What are you talking about? "warning: comparison between signed and unsigned integer expressions [-Wsign-compare]". But yes, I do see your point.

When I said "no warnings, no errors", I meant by default. If I compile -Wall (or -Wsign-compare) then yes, it does give a warning; but it gives that warning even if you are writing the correct version of the code! If you count up from zero and make the comparison "while (pennies < names.length())" you get precisely the same warning. So this is not at all helpful from a pedagogy perspective.

The standard is written that this kind of type conversion is normally silent, and the real problem here is that it's not even clear what names.length() returns (signed/unsigned), it's slightly difficult to find that out (and nearly impossible if you don't already have some idea of the potential problem), and at the point in a CS1 course where you might be doing this, the students may not even know the difference between signed and unsigned!

C++ has its place in the world. Intro CS courses are not that place.