feat: add limits to input attributes

[kdrienCG]

This PR adds the possibility to specify a min and/or a max value to Wrappers attributes.

The goal is to provide the foundations for two follow-up efforts planned in future PRs:

• applying this limit feature wherever GEOS has known, constant ranges that can be validated;
• extending the generated documentation (e.g. with additional text or a dedicated column) to display the limits associated with each attribute.

---

Usage:

registerWrapper( viewKeysStruct::fooString(), &m_foo )
  .setLimits( 0.0, 1.0 )  // sets a minimal value of 0.0 and a maximal value of 1.0

This will serve as a documentation for values, but also prevents users from making typos that could lead to wrong results, taking time to find (if noticed).

The limits come with 3 modes:

• Indicative: No validation of the input is made, serves as documentation only.
• Warning: A warning is emitted if the attribute's value is outside the allowed range.
• Error: An error is emitted if the attribute's value is outside the allowed range.

The mode can be set when specifying the limit, using this syntax:

  .setLimits( 0.0, 1.0, LimitsMode::Warning )

... or it will default to Error if unset.

Limits also support inclusive and exclusive bounds:

  .setLimits( inclusive( 0.0 ), exclusive( 1.0 ) )

Not using inclusive(...) or exclusive(...) will default to an inclusive limit.

---

Some examples:

  .setLimits( 0.0, 1.0 )  // [0.0, 1.0]
  .setLimits( 0.0, std::nullopt )  // [0.0, +inf)
  .setLimits( inclusive( 0.0 ), std::nullopt )  // [0.0, +inf)
  .setLimits( std::nullopt, exclusive( 0.0 ) )  // (-inf, 0.0)

[dkachuma]

I really like this idea. It will simplify greatly some of the boiler plate validation code.

Will this work for lists of numbers?

[MelReyCG]

Please apply this feature on at least one (maybe basic) 'Group' to demonstrate usage (array and scalar ideally).

[MelReyCG]

un-needed inclusion, beware of clangd ;)

[MelReyCG]

There are still some,
<type_traits>, <optional>, maybe some more

[MelReyCG]

do we want this constructor explicit?

[kdrienCG]

It was made not explicit so we can write .setLimits( 0.0, 1.0 ) instead of .setLimits( WrapperBound{ 0.0 }, WrapperBound{ 1.0 } )

[MelReyCG]

That implicit conversion from any double to your type, at this (critical) level of the inclusion hierarchy, may cause the compiler to try undesired casts.
Why not an overload or a different signature for setLimits()?

[kdrienCG]

Please apply this feature on at least one (maybe basic) 'Group' to demonstrate usage (array and scalar ideally).

Applied to BrooksCoreyBakerRelativePermeability that uses arrays in commit 931c469

[MelReyCG]

There are still some,
<type_traits>, <optional>, maybe some more

[MelReyCG]

What gives the following in the log?

Suggested change

	string const msg = GEOS_FMT( "Value {} for attribute '{}' is outside the allowed range {}.",
	value, getDataContext(), m_limits.getRangeStr() );
	switch( m_limitsMode )
	{
	case WrapperLimitsMode::Warning:
	GEOS_WARNING( msg );
	break;
	case WrapperLimitsMode::Error:
	GEOS_THROW( msg, InputError );
	break;
	default:
	GEOS_LOG_RANK_0( "Unimplemented WrapperLimitsMode" );
	break;
	string const msg = GEOS_FMT( "Value {} is outside the allowed range {}.",
	value, m_limits.getRangeStr() );
	switch( m_limitsMode )
	{
	case WrapperLimitsMode::Warning:
	GEOS_WARNING( msg, getDataContext() );
	break;
	case WrapperLimitsMode::Error:
	GEOS_THROW( msg, InputError, getDataContext() );
	break;
	default:
	GEOS_LOG_RANK_0( "Unimplemented WrapperLimitsMode" );
	break;

[MelReyCG]

That implicit conversion from any double to your type, at this (critical) level of the inclusion hierarchy, may cause the compiler to try undesired casts.
Why not an overload or a different signature for setLimits()?