Proposed resolution:

This wording is relative to N3691.

1. Change the class template match_results header synopsis, [re.results] p4 as indicated:

   typedef const value_type& const_reference;
   typedef const_referencevalue_type& reference;
   

[ Issaquah 2014-02-11: Move to Immediate ]

[ 2013-10-17: Daniel comments ]

The std::initializer_list synopsis, [support.initlist] shows a similar problem:

template<class E> class initializer_list {
public:
  typedef E value_type;
  typedef const E& reference;
  typedef const E& const_reference;
  […]
}

Given the fact that std::initializer_list doesn't meet the container requirements anyway (and is such a core-language related type) I recommend to stick with the current state.

The match_results class synopsis has

typedef const value_type& const_reference;
typedef const_reference reference;

We're getting too enthusiastic about types here by insisting that reference is a const reference, even though match_results is a read-only container. In the container requirements table (Table 96, in section [container.requirements.general] we say that Container::reference is "lvalue of T" and Container::const_reference is "const lvalue of T".

That phrasing in the container requirements table is admittedly a little fuzzy and ought to be clarified (as discussed in lwg issue 2182), but in context it's clear that Container::reference ought to be a T& even for constant containers. In the rest of Clause 23 we see that Container::reference is T&, not const T&, even for const-qualified containers and that it's T&, not const T&, even for containers like set and unordered_set that provide const iterators only.

The way we handle const containers is just that in the case of a const-qualified container (including match_results) there are no operations that return Container::reference. That's already the case, so this issue is complaining about an unused typedef.