Plan for 2.0

[henryiii]

• Make more parts of the library optional, at least in multiheader mode (postponed)
• Allow the library to be precompiled to address Improve compile time #194. (still will support header only / single header mode) - postponed to 2.x.
  • New make single header tooling
• Drop deprecated add_set templated methods
• Drop deprecated extra true/false argument for capture default on add_option refactor!: drop defaulted from add_option #597
• Drop add_complex (no longer required)
• Allow compilation with exceptions turned off (might put off till 3.0)
• Change Config file output default to TOML

[sergeyklay]

Can I ask to consider #355 as well as #353.

Thank you

[phlptp]

• remove some backwards compatibility customizations in expected and type_size
• change default settings for integer flags Flag summing #243
• add support for all containers and other wrapper types
• work on help formatters for Feature request: Footer formatting and terminal geometry #355, Question: Options formatting #353 and a few other issues and purposes
• add a force function to force an option/flag callback to be called regardless of whether the option was passed or not.

[henryiii]

So that we can get something out rather than keep waiting for a large change, I'd like to postpone the pre-compile plans (which is mostly not user facing; that is, users don't have to use it) for 2.x. That way I can focus on the exception part (which will be user-facing), and get a release out sooner rather than (much) later. I have a daughter coming soon, so trying to plan out my limited time!

[henryiii]

I might be forced to put off the exception refactoring, since that will further delay 2.0 and as I always tell other people, numbers are cheap - we could do a 3.0 if it requires a backwards incompatible change. And 2.0 would already be useful to get out the door. (plus I accidentally deleted some work I had done on it)

I'll try to get the final removals in (#597 and dropping add_complex) and currently open fixes in, and then if I can't get the error reworking in within a week or so, I'll probably just make a release. @phlptp is this fine with you, or do you have anything else that needs to go in?

// Only part of work that didn't get deleted, pasting here
#ifndef CLI11_EXCEPTIONS
#ifdef __EXCEPTIONS
#define CLI11_EXCEPTIONS 1
// GCC and Clang will define the above define
#elif __GNUC__
#define CLI11_EXCEPTIONS 0
#else
#define CLI11_EXCEPTIONS 1
#endif
#endif

[phlptp]

Nothing major, that can’t wait. If I fix some of the issues in the next week I will make a PR but don’t wait on me for a release. From: Henry Schreiner ***@***.***> Sent: Tuesday, June 15, 2021 9:30 AM To: CLIUtils/CLI11 ***@***.***> Cc: Top, Philip L. ***@***.***>; Mention ***@***.***> Subject: Re: [CLIUtils/CLI11] Plan for 2.0 (#384) I might be forced to put off the exception refactoring, since that will further delay 2.0 and as I always tell other people, numbers are cheap - we could do a 3.0 if it requires a backwards incompatible change. And 2.0 would already be useful to get out the door. (plus I accidentally deleted some work I had done on it) I'll try to get the final removals in (#597<https://urldefense.us/v3/__https:/github.com/CLIUtils/CLI11/pull/597__;!!G2kpM7uM-TzIFchu!gxMiH-ZDEp6QyIMpHJp77gefSAmCg2CyymCb9yKa9pvDkQ1Zm5lNT4rXQUvq0iM$> and dropping add_complex) and currently open fixes in, and then if I can't get the error reworking in within a week or so, I'll probably just make a release. @phlptp<https://urldefense.us/v3/__https:/github.com/phlptp__;!!G2kpM7uM-TzIFchu!gxMiH-ZDEp6QyIMpHJp77gefSAmCg2CyymCb9yKa9pvDkQ1Zm5lNT4rXhJIs7j4$> is this fine with you, or do you have anything else that needs to go in? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://urldefense.us/v3/__https:/github.com/CLIUtils/CLI11/issues/384*issuecomment-861649665__;Iw!!G2kpM7uM-TzIFchu!gxMiH-ZDEp6QyIMpHJp77gefSAmCg2CyymCb9yKa9pvDkQ1Zm5lNT4rXc9Phj04$>, or unsubscribe<https://urldefense.us/v3/__https:/github.com/notifications/unsubscribe-auth/AE5VWELUF7CSLKNGNVUSYR3TS55ZVANCNFSM4KBWSBYQ__;!!G2kpM7uM-TzIFchu!gxMiH-ZDEp6QyIMpHJp77gefSAmCg2CyymCb9yKa9pvDkQ1Zm5lNT4rX7ZU-_qE$>.

[data-man]

It would be nice to add a regex validator.

[henryiii]

Release should happen fairly soon, probably end of this week. Will need to update contributors, changelog, upcoming -> new features labels.

[henryiii]

It would be nice to add a regex validator.

That would require GCC 4.9+. It's easy to add one yourself, though - and maybe it could be added as an optional include. Those are a bit easier in 2.0.

[phlptp]

I think a number of the validators should be split into a separate optional include. Then we would have a little more freedom for a validator library that wouldn't slow down compilation if someone didn't need them. At that point adding a regex validator shouldn't be an issue either. But lets get the 2.0 release out first.

[phlptp]

@henryiii are you changing the minimum compiler requirement on 2.0?

[henryiii]

No, it't still 4.8+. CentOS 7 is still an important target (and manylinux1 is 4.8 too). But I'd be okay with an optional file having a higher requirement.

[henryiii]

This is now out!