C++0X Concepts are gone. Which other features should go too?

Question

As you may have heard, the last meeting of the C++ standards committee voted to remove concepts from the next C++ standard. Of course, this will affect other features and would seem to throw the standard wide open again. If that is the case, which other features do you think should be stripped away (or added), and why?

Links:

Removal of Concepts -- Danny Kalev (on the decision to remove concepts)

Simplifying the use of Concepts -- Bjarne Stroustrup (on the problems with concepts as they look now)

The Long Pole Gets Longer -- Martin Tasker (on the impact to the schedule for C++0x if concepts have to be fixed)

The C++0x "Remove Concepts" Decision - Stroustrup on the issue on Dr. Dobbs

Trip Report: Exit Concepts, Final ISO C++ Draft in ~18 Months - Herb Sutter

Concepts Get Voted Off The C++0x Island - Jeremy Siek defending the current Concepts spec

What Happened in Frankfurt? - Doug Gregor on C++Next (on the history and removal of Concepts).

Answer 1

None, I think the rest of the draft was great - a large number of very small pieces that can be correctly implemented independently, allowing vendors to evolve toward complete support and allowing users to take a "shopping list" approach.

Quite a different situation with contracts, as they were like a whole new parallel type system and would have been very likely to have led to different compilers ending up with their own backward compatibility problems, very similar to CSS in web browsers.

Answer 2

The un-named function / lambda function stuff makes me nervous. Function objects are perfectly good and are explicit, thus easier to read and find.

On the other hand I kinda liked concepts, though I certainly would not have used them every day.

Answer 3

Personally, I want C++ to finally break away from C. No more pre-processor, no more header files. I basically want D, but without all the stuff that D tacks on, using the STL.

Answer 4

To me the problem is not what other features should be stripped away, but how complex will other features be after concepts have been removed. That and how much longer will it take for the rest of the features to be rephrased without concepts.

A lot of features assumed that concepts would be accepted into the language and the wording is expressed in terms of concepts. (I wonder if any proposed feature depends on concepts).

I also wonder how other libraries will evolve (think boost::type_traits) to take the niche left by concepts. Part of what concepts provided can be implemented (even if in a more cumbersome way) in terms of traits applied to the type arguments.

To me, the most important thing that concepts added to the language was an expressive formulation of compilation errors, which is nowadays one of the places where C++ is most criticized.

R.I.P. concepts.

Answer 5

Strip away the pages of error messages on template code!

IIRC concepts should solve a big C++ coder problem: Human readable error messages for the STL. Its bad news that this issue isn't addressed.

Answer 6

There are two things I think should be added to C++0x, I've thought of both these myself and then found that others have suggested them before but it doesn't seem like they're going to happen.

1. Defaulting Move Constructors and Move Assignment Operators

Writing a move constructor is a manual and error prone activity, if a member is added it must be added to the move constructor and assignment operators and std::move must be used religiously. That's why I think these functions should be defaultable.

movable(movable&&) = default;
movable& operator=(movable&&) = default;

Edit (2009-10-01): Looks like this is going to happen after all.

2. Override Type Deduction for Expression Templates

Expression templates often define types that should not be used directly, a case in point is the return value of std::vector<bool> operator[](size_type n), if auto or decltype are used on this kind of object unexpected behaviour may ensue. Therefore a type should be able to say what type it should be deduced to be (or prevent deduction using = delete syntax).

Example for vector addition.

// lazy evaluation of vector addition
template<typename T, class V1, class V2>
class vector_add {
     V1& lhs_;
     V2& rhs_;
public:
     T operator[](size_t n) const
     { return lhs_[n] + rhs_[n]; }
     // If used by auto or decltype perform eager creation of vector 
     std::vector<T> operator auto() const 
     {
         if (lhs_.size() != rhs_.size()) 
             throw std::exception("Vectors aren't same size");
         std::vector<T> vec;
         vec.reserve(lhs_.size());
         for (int i = 0; i < lhs_.size(); ++i)
            vec.push_back(lhs_[i] + rhs_[i]);
         return vec;
     }

Answer 7

Of course, this will affect other features and would seem to throw the standard wide open again.

Hardly. They still want to wrap up the standard soon, which is one of the main reasons for removing concepts. Making it "wide open" to unrelated changes would just throw away everything they gained by ditching concepts.

Anyway.... Of the remaining C++0x additions, I can't think of anything else I'd want to remove. I agree with their decision regarding concepts though. Stroustrup's paper really outlined some serious problems, The current specification for concepts would admittedly simplify template error messages, but it would do so by dramatically reducing the usefulness of generic programming -- a price I'm not willing to pay.

When I first read that paper, it scared me, because I assumed it was too late in the process for making serious changes to the spec. Turns out it wasn't, and the committee was willing to take dramatic action.

But apart from this, I think C++0x is in good shape. The remaining new features all look worthwhile.

Of course, there are plenty of existing features I'd love to remove. Primarily the vector<bool> specialization. There are other popular examples of features that didn't work out (the export keyword, exception specifications), but the vector specialization is the only one of them that can't be ignored. As long as we don't try to export templates, it doesn't matter that the keyword exists (and isn't implemented by compilers), and we can just refrain from using exception specs, but every time we need a vector of bools, we're bitten by the stupid premature optimization that slipped into the current standard.

Unfortunately, it seems like they've given up on removing it. (Last I checked, it wasn't even deprecated).

Of course, plenty of old C cruft could be ditched too, but recently, I've discovered that the one change I'd really love to see is...... ditching the Iostreams library. Toss it out, and build a new STL-style I/O library based on generic programming.

The current OOP-styled Iostreams library is ugly, slow, overcomplicated and inflexible. There's too much voodoo involved in defining new streams, too few standard stream types involved, too little flexibility (the problem that made me realize how limited the library is, was that I needed to extract a float from a string. Easy to do with stringstream, but if you need to do it often, you don't want to have to copy the input string every time (as the stringstream does) -- where's the stream that works on an existing iterator range? Or a raw array, even?)

Throw IOstreams out, develop a modern replacement, and C++ will be vastly improved.

And perhaps do something about the string class as well. It works sort of ok'ish as it is now, but really, what's with the huge number of member functions? Most of them would work better, and be more general, as free functions. Too much of the standard library relies specifically on the string class, when it could in principle work with any container, or even an iterator (std::getline, I'm looking at you)

Answer 8

Do whatever you want with concepts, but for god's sake keep threads and atomics, we absolutely need them. Perhaps add thread groups and support for cooperative threads a.k.a. fibers. IMO these are far more important than concepts, because everyone uses/will soon be using threads.

Answer 9

I'd like to remove =delete.

There's already a common and accepted idiom for acheiving the same effect (declare the function in question as private). I think this feature will just generate lots of 'I used =delete to remove a base class function from my derived class, but it can still be called using a base class pointer' questions.

Not to mention confusing people between the (now) two meanings of the delete keyword.