Heh, when I first heard that C++ vectors were bitvectors I was like "that can't be right? You can't get sensible references to members that way!" But it turns out that C++ is fine with breaking parametricity so references to bitvector elements just don't compile.

I wouldn't say C++ is fine with it. vector<bool> is widely viewed as a mistake. I would actually say it's one of the few inconsistencies in a standard library that tends to be very consistent.

The problem is that (quite rightly) the C++ standard committee tries very hard to not break existing code. There isn't really an easy way to deprecate a specialization of this container without causing 32x more memory use if someone was relying on it, and even worse it would be a silent breaking change.

I mean, this isn't the only case of broken parametricity I've come across in C++ codebases. Though it's the only one in the stdlib.

I know vector<bool> is controversial (and I understand it can't be "fixed" now), I was just surprised that something breaking parametricity so blatantly was ever agreed upon in the first place -- in more functional languages parametricity is kinda much more jealously guarded. Bit of a culture shock there, is all :)

You mean 8x more memory, right?

works great on vector<int> though, it turns out vector<bool> is a special case!

http://stackoverflow.com/questions/30376032/error-invalid-in...

Does const auto& work though?

I normally use for(auto&& x : ...) which works with those rare containers that have proxy references, while still allowing mutation.