This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.

### 3341. `basic_regex` range constructor: Missing requirements for iterator types

Section: 32.7.2 [re.regex.construct] Status: New Submitter: Денис Захаров Opened: 2019-11-17 Last modified: 2022-04-22

Priority: 3

View other active issues in [re.regex.construct].

View all other issues in [re.regex.construct].

View all issues with New status.

Discussion:

This is description of a `basic_regex` range constructor from N4835, 32.7.2 [re.regex.construct]:

>     template<class ForwardIterator>
>       basic_regex(ForwardIterator first, ForwardIterator last,
>                   flag_type f = regex_constants::ECMAScript);

> > -17- Throws: `regex_error` if the sequence `[first, last)` is not a valid regular expression.

> > -18- Effects: Constructs an object of class `basic_regex`; the object's internal finite state machine is constructed from the regular expression contained in the sequence of characters `[first, last)`, and interpreted according to the flags specified in `f`.

> > -19- Ensures: `flags()` returns `f. mark_count()` returns the number of marked sub-expressions within the expression.

It seems that there are no requirements about dereferenced iterator's element type, that, apparently, must be implicitly convertible to the `basic_regex::value_type`. For example, containers having range constructor satisfy a SequenceContainer requirements, where implicit converting to its elements is specified.

[2019-11-30 Issue Prioritization]

Priority to 3 after reflector discussion.

[2021-10-04; Jonathan adds a comment]

There isn't even a requirement that the arguments are iterators. And `assign(InputIterator, InputIterator, flag_type)` is not constrained to only accept iterators either, meaning you can call it with two integers and call the `basic_string(size_type, char_type)` constructor.

[2022-04-22; Jonathan adds a comment]

As well as requiring the reference type to be convertible to `charT`, we might want to consider constraining these with `forward_iterator` as per P2408.

Proposed resolution: