Explore CTAD-friendly public constant and variable wrapper types

[ipapadop]

Motivation

The current public factories and implementation types use different names:

auto c = deferred::constant(42); // returns constant_<int>
auto v = deferred::variable(42); // returns variable_<int>

A more conventional class-template interface could use class template argument deduction:

deferred::constant c{42};
deferred::variable v{42};

This resembles standard-library wrappers such as std::optional and makes the constructed type explicit without spelling template arguments.

Proposed direction

Evaluate renaming constant_ and variable_ to public class templates constant and variable, with deduction guides where implicit deduction is insufficient.

Possible usage:

deferred::constant c{42};
deferred::variable v{42};
deferred::variable<int> default_initialized;

Design considerations

• A namespace cannot contain a class template and function template with the same name, so this conflicts with the existing constant() and variable() factories.
• Determine whether factories should be renamed, removed in a major version, or preserved through differently named compatibility helpers.
• Preserve the factories' current recursive evaluation behavior. Direct construction from a callable must either retain that behavior or explicitly differ and be documented.
• Preserve reference/ownership behavior and deduction of arrays, function types, and cv-qualified inputs.
• Ensure default construction remains available for variable<T>.
• Evaluate source migration ergonomics and whether the cosmetic benefit justifies the breaking change.
• Do not introduce deduction guides that silently retain references when ownership is expected.

Compatibility

This is inherently API-breaking if the public types take the existing factory names. It should be treated as a major-version design investigation rather than an immediate refactor.

Acceptance criteria

• A design decision documents whether public class templates should replace the factories.
• Proposed deduction guides cover lvalues, rvalues, callable inputs, and default-initialized variables.
• Recursive callable evaluation semantics are explicitly addressed.
• A migration path for existing constant(...) and variable(...) call sites is documented.
• If implemented, compile-time tests verify deduced types and ownership.
• Existing runtime behavior is preserved or intentional differences are documented as breaking changes.