Date: Tue, 1 Oct 2019 13:05:44 -0400
Hi Mark, here's some mostly minor review comments.
I think your Section 6.1 should express a preferred direction, and a
rationale for why it's the best. You have implemented exactly one of these
directions in your branch, right? Which one, and why?
Your Section 2 says that the second draft revision "removed
string_view_type from basic_regex and regex_traits." This is true, but it
distracted me when I discovered that string_view_type was still mentioned
in the proposed wording, as a member of sub_match and match_results. I
would like to see you mention in Section 2: "Removed string_view_type from
basic_regex and regex_traits (but it is still present in sub_match and
match_results)."
Your wording for [re.regex.assign] still depends
on`basic_regex::string_view_type`. I think it should say
`basic_string_view<charT>` instead of `string_view_type`.
TeX nit: At the top of page 13, in [re.submatch.op]'s "Returns" element,
you have the wrong kind of `<<`.
TeX nit: [re.alg.replace]/3 on page 17 seems to lose teletype font in the
middle of an underscore.
In [re.alg.replace]/1.2, could you just define the effects for all three
overloads in terms of `m.format(out, string_view_type(fmt), flags)`?
–Arthur
On Tue, Sep 17, 2019 at 1:44 PM Mark de Wever via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> Hi,
>
> I've posted before about this proposal and based on the feedback here
> and on Reddit I've improved my proposal. I've also updated the wording
> to the latest draft N4830.
>
> The proposal adds string_view support to various parts of regex. Its
> main goal was to make the following code valid:
>
> void foo(std::string_view input) {
> std::regex re{"foo.*bar"};
> std::svmatch match;
> if (regex_match(input, match, re)) {
> std::cout << "Found " << match[0] << "\n";
> std::string_view sv = match[0].view();
>
> // Do stuff with sv
> }
> }
>
> Attached the latest draft. Any more suggestions how to improve this
> paper?
>
> (Note haven't asked Arthur to update the Compiler Explorer branch to the
> lastest version yet.)
>
> Kind regards,
> Mark de Wever
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
I think your Section 6.1 should express a preferred direction, and a
rationale for why it's the best. You have implemented exactly one of these
directions in your branch, right? Which one, and why?
Your Section 2 says that the second draft revision "removed
string_view_type from basic_regex and regex_traits." This is true, but it
distracted me when I discovered that string_view_type was still mentioned
in the proposed wording, as a member of sub_match and match_results. I
would like to see you mention in Section 2: "Removed string_view_type from
basic_regex and regex_traits (but it is still present in sub_match and
match_results)."
Your wording for [re.regex.assign] still depends
on`basic_regex::string_view_type`. I think it should say
`basic_string_view<charT>` instead of `string_view_type`.
TeX nit: At the top of page 13, in [re.submatch.op]'s "Returns" element,
you have the wrong kind of `<<`.
TeX nit: [re.alg.replace]/3 on page 17 seems to lose teletype font in the
middle of an underscore.
In [re.alg.replace]/1.2, could you just define the effects for all three
overloads in terms of `m.format(out, string_view_type(fmt), flags)`?
–Arthur
On Tue, Sep 17, 2019 at 1:44 PM Mark de Wever via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> Hi,
>
> I've posted before about this proposal and based on the feedback here
> and on Reddit I've improved my proposal. I've also updated the wording
> to the latest draft N4830.
>
> The proposal adds string_view support to various parts of regex. Its
> main goal was to make the following code valid:
>
> void foo(std::string_view input) {
> std::regex re{"foo.*bar"};
> std::svmatch match;
> if (regex_match(input, match, re)) {
> std::cout << "Found " << match[0] << "\n";
> std::string_view sv = match[0].view();
>
> // Do stuff with sv
> }
> }
>
> Attached the latest draft. Any more suggestions how to improve this
> paper?
>
> (Note haven't asked Arthur to update the Compiler Explorer branch to the
> lastest version yet.)
>
> Kind regards,
> Mark de Wever
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2019-10-01 12:08:06