[PROPOSE] Refactor args_t to use ranges instead of vector

[filipsajdak]

In the current cppfront implementation (65fcd0f), we are using std::vector<std::string_view> to store args in main(). This change proposes to use std::ranges that can use lazy evaluation of ranges.

Thanks to this change we can avoid one allocation that is unnecessary.

[JohelEGP]

Definitely an improvement.

You could try either of these to not make args_t a template: https://compiler-explorer.com/z/E9r7xcoMo.

[filipsajdak]

I have been thinking about your approach - I did not like the lambda living somewhere outside. If Herb will be open to making it dependent on ranges we can choose one solution that will fit the best.

Thanks for feedback!

[JohelEGP]

Only its type lives outside. The view holds its instance.

[filipsajdak]

@JohelEGP I have slept over it and decided to follow the path you propose but move the lambda directly to the type definition - like here: https://godbolt.org/z/Mvv6a4rs6 (I think the code looks simpler).

Thanks for the excellent feedback!

[JohelEGP]

Yeah, that's much better. Thank you.

[hsutter]

Thanks! I thought about using ranges. Because Ranges is not yet widely supported I'm reluctant to introduce a dependency on it without a strong justification. (Note that cppfront should support ranges -- they should work fine if you're using a Cpp1 compiler that supports them. But it doesn't require ranges including by injecting a ranges dependency into the user's program, that's what I'm getting at. If we did this PR, then a user program that didn't use ranges at all would not work on a Cpp1 compiler that is otherwise fine but doesn't yet support ranges.)

The cppreference C++20 conformance chart shows Ranges as only "partial" in upstream Clang, until version 15 which was released last month(? and still has an asterisk), and as you mentioned in this comment on #262 that links this PR:

my apple-clang-14 has just provided support for ranges

So I'm inclined to reject this PR on the grounds that Ranges is not yet supported widely/robustly enough (particularly in Clang/libc++) to be safe to take a dependency on without having a compelling reason. A compelling reason would be something like that a major feature of cppfront doesn't work or is so slow that it inhibits adoption. Saving one allocation doesn't meet that bar (sorry!). But please reopen this if you think I'm making a mistake.

Thanks, and thanks for understanding!

[filipsajdak]

That is fine. The implementation is ready when there will be time to introduce it.