System.CommandLine is split into too many namespaces

[jkotas]

I end up writing the following battery of namespaces into every project:

using System.CommandLine;
using System.CommandLine.Builder;
using System.CommandLine.Invocation;
using System.CommandLine.Parsing;

Should these namespaces be all folded into one?

This design is in conflict with .NET Framework design guidelines:

AVOID having too many namespaces.

Users of a framework should not have to import many namespaces in the most common scenarios.

[Marusyk]

Can I take this one and remove System.CommandLine.Builder, CommandLine.Invocation, CommandLine.Parsing? what about backward compatibility?

[jonsequitur]

I think some discussion is needed.

There was concern in our previous API review that the root namespace would be too cluttered for people to immediately find the most important "entry point" types in the library, which is why more namespaces were created. It would be good to simplify, though, and now before we remove the preview tag is the time to make breaking changes.

[jonsequitur]

Here's a list of proposed changes, intended to move some of the most common types into the root System.CommandLine namespace while leaving other less commonly-used types in their more specific namespaces so as not to introduce clutter.

• [x] Remove the System.CommandLine.Builder namespace and move its two types to System.CommandLine.
• [x] Move System.CommandLine.Parsing.ParseResult to System.CommandLine.
• [x] Move System.CommandLine.Invocation.ICommandHandler to System.CommandLine.