Date: Sun, 29 Sep 2024 19:46:58 -0500
Hi,
I'm drafting a proposal to add std::arguments which would provide an
encoding-friendly and modern interface for accessing program arguments.
This is a follow-up for half of Izzy Muerte's paper P1275 Desert
Sessions: Improving hostile environment interactions. A follow-up to the
other half, std::environment, is being separately worked on.
Draft: https://jeremy-rifkin.github.io/proposals/drafts/cpp/arguments-draft-1.html
Very rough sketch to get a feel for the interface: https://godbolt.org/z/d7zvKc4xj
The two main places I'm still weighing pros and cons on the design are
whether the iterators for std::arguments_view should meet the
requirements of Cpp17RandomAccessIterator, which would require backing
storage for the `std::argument`s being iterated over, and what the
behavior should be if the user modifies argv from main. While I think it
would be desirable to not have changes to argv reflected in
std::arguments, it would require copying arguments on startup which may
be seen as undesirable even if opt-in. The rough implementation sketch I
provided is a zero-overhead view over argv, with no allocation or
caching of things like strlen computations on arguments.
I'd very much appreciate comments, thoughts, and guidance.
Cheers,
Jeremy
I'm drafting a proposal to add std::arguments which would provide an
encoding-friendly and modern interface for accessing program arguments.
This is a follow-up for half of Izzy Muerte's paper P1275 Desert
Sessions: Improving hostile environment interactions. A follow-up to the
other half, std::environment, is being separately worked on.
Draft: https://jeremy-rifkin.github.io/proposals/drafts/cpp/arguments-draft-1.html
Very rough sketch to get a feel for the interface: https://godbolt.org/z/d7zvKc4xj
The two main places I'm still weighing pros and cons on the design are
whether the iterators for std::arguments_view should meet the
requirements of Cpp17RandomAccessIterator, which would require backing
storage for the `std::argument`s being iterated over, and what the
behavior should be if the user modifies argv from main. While I think it
would be desirable to not have changes to argv reflected in
std::arguments, it would require copying arguments on startup which may
be seen as undesirable even if opt-in. The rough implementation sketch I
provided is a zero-overhead view over argv, with no allocation or
caching of things like strlen computations on arguments.
I'd very much appreciate comments, thoughts, and guidance.
Cheers,
Jeremy
Received on 2024-09-30 00:47:04