On Thu, 20 Feb 2025, 21:41 Chris Ryan via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> I would argue against complexity and pro singular responsibility.
> Streams should only be used streaming (read/write)
> regex should only be used for parsing/pattern matching.
> Keep them separate.
>
> In the first place, I am not a fan of regex but your example
> implementation only parsed a single argument.
>

Right, it's just an operator>> overload for extracting a string. But we
already have that.

Where does the regex get defined? Do you have a different operator>>
overload for each pattern you want to match?

It seems like your want a higher level API that could potentially be built
in terms of regex and operator>>, but I don't see the point of putting the
regex_match inside operator>>.

This seems badly thought out.

regex's utility comes from complex multi-argument parsing. Are you going
> to make an operator>>() that takes a runtime regular expression and an out
> param returning a collection of matches.
>
> Or might you set a regex stream mode where the next N args would be the
> matching expressions and how would you get the count of matches before
> trying to read the matches.
>
> in >> regex(".....") >> arg1 >> arg2>> ... >> argN; //NOT
> recommending anything like this.
>
> Ridiculous suggestion to show the lunacy of mixing streaming with parsing:
> If you are going to do a regex streaming, why not a streaming scanf() type
> streaming parsing mode. That would almost make more sense since
> most operator>>() have a symmetrical operator<<() functionality (vis-à-vis
> streaming formatted print(...) ).
>
>
> On Thu, Feb 20, 2025 at 5:48 AM Phil Bouchard via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> Greetings,
>>
>> Seems to me regex over istreams would be quite useful. Here's an
>> inefficient implementation:
>>
>>
>> inline std::istream& operator >> (std::istream& in, std::string & v)
>> {
>> static const std::regex string_regex(R"(^\"(.*?)\"$)");
>>
>> std::smatch match;
>>
>> std::string x;
>>
>> for (x += in.get(); in; x += in.get())
>> if (std::regex_match(x, match, string_regex))
>> {
>> v = match[1].str();
>>
>> return in;
>> }
>>
>> throw std::invalid_argument("Parse error.");
>> }
>>
>> Is there any interests in such implementation?
>>
>>
>> Regards,
>> --
>> [image: Fornux Logo] <https://www.fornux.com/>
>> *Phil Bouchard* [image: LinkedIn Icon]
>> <https://www.linkedin.com/in/phil-bouchard-5723a910/>
>> Founder & CEO
>> T: (819) 328-4743
>> E: phil_at_[hidden] | www.fornux.com
>> 320-345 de la Gauchetière
>> <https://www.google.com/maps/search/345+de+la%0D%0A++++++++++++++++++++++++Gaucheti%C3%A8re?entry=gmail&source=g>
>> Ouest | Montréal (Qc), H2Z 0A2 Canada
>> [image: The Best Predictable C++ Memory Manager]
>> <https://static.fornux.com/c-superset/> Le message ci-dessus, ainsi que
>> les documents l'accompagnant, sont destinés uniquement aux personnes
>> identifiées et peuvent contenir des informations privilégiées,
>> confidentielles ou ne pouvant être divulguées. Si vous avez reçu ce message
>> par erreur, veuillez le détruire.
>> This communication (and/or the attachments) is intended for named
>> recipients only and may contain privileged or confidential information
>> which is not to be disclosed. If you received this communication by mistake
>> please destroy all copies.
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>