Jon Sequeira

@ghord > Could we add something to avoid obvious boiler plate in this situation? It seems very logical to me to just use all arguments/options by default in the order...

@solvingj Thanks for this example. This kind of API can absolutely be built on top of the existing library and we've done experiments along these lines from the outset to...

@solvingj I'd like to problematize something you wrote: > The API says to construct a command in one place, and construct it's handler functions separately, even though they are completely...

@ptr727, the issue might be this change to the default for `Option.AllowMultipleArgumentsPerToken`: https://github.com/dotnet/command-line-api/issues/1552#issuecomment-1004318166

> It was wise and correct from a domain modeling perspective to make these things interfaces: (ICommand, IArgument, and IOption etc). It was narrow-focused to fundamentally compromise the domain model...

Parsing this is fairly straightforward. Setting up your parser like this should work: ```csharp var uriArgument = new Argument(); var myOption = new Option("--myoption"); var myCommand = new Command("mycommand") {...

There isn't one currently because typically the shell will fall back to file completion if the shim doesn't receive any completions from the .NET tool. There's been some discussion of...

I think I see what's happening. At the position where you're asking for completions, the option tokens are valid, so `dotnet-suggest` returning any results at all prevents the shell from...

This can currently be done using a custom validator, although it's a bit awkward. https://github.com/dotnet/command-line-api/blob/master/src/System.CommandLine.Tests/ParsingValidationTests.cs#L104 Suggestions on a nicer API for this feature?

I think it's fine to track it here.