Hi Magnus,
Thanks for your comments.

> What I am trying to say here is that just beeing able to see the arguments
doesn't allow a library to correctly parse them so the whole idea is
starting
from the wrong direction and that argument parsing can get arbitrarily
complex.

A library looking at arguments is really a negligible part of the
motivation for this proposal. The core motivation is handling encoding
properly and providing a modern interface for arguments (new signatures for
main are out of the question).

That being said, for an example of a library successfully parsing its own
arguments, please see gtest. Gtest does modify argc and argv, but, this is
avoidable; e.g. if a library prefixes its arguments.

Cheers,
Jeremy


On Sat, Oct 12, 2024 at 16:46 Magnus Fromreide via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Sun, Sep 29, 2024 at 07:46:58PM -0500, Jeremy Rifkin via Std-Proposals
> wrote:
> > 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.
>
> How does a third party library that uses this facility discern various
> cases?
>
> Presume that the program sees an argument spelled "/bin" - is this an
> argument to a previous flag or a flag in it's own right using windows
> style arguments?
>
> Presume that the program sees an argument spelled -x - is this a sub
> argument dependant on position or a global argument and how should the
> third party library know what was meant?
> A prime example of a program where this style is used is sox.
>
> Presume that the program sees an argument spelled -- - is this a posix
> end of arguments marker or not (sure, having it not beeing that is bad
> style but it is still permissible today)
>
> Presume that the program sees an argument spelled +x - is this an
> independent argument that negates a -x or is it something else?
>
> Presume that the program sees an argument spelled -log - is this a
> short form of -l -o -g or is it intended as a log flag?
> A prime example of this is ls which have covered almost the whole alphabet
> with argument flags.
>
>
> What I am trying to say here is that just beeing able to see the arguments
> doesn't allow a library to correctly parse them so the whole idea is
> starting
> from the wrong direction and that argument parsing can get arbitrarily
> complex.
>
> /MF
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>