dedekind::algebra::HasFieldOperators Concept Reference

Pure syntactic shape: T closes strictly under the full field operator surface +, binary -, unary -, *, /, and exposes the multiplicative unit T{1}. More...

Concept definition

template<typename T>
concept dedekind::algebra::HasFieldOperators =  HasRingOperators<T> && HasGroupOperatorsMul<T>

Detailed Description

Pure syntactic shape: T closes strictly under the full field operator surface +, binary -, unary -, *, /, and exposes the multiplicative unit T{1}.

The aggregator concept for the field-operator surface. Equal in content to HasRingOperators<T> && HasGroupOperatorsMul<T>:

• HasRingOperators<T> — +, binary -, unary -, * close strictly on T (the additive-group + ring surface);
• HasGroupOperatorsMul<T> — *, /, T{1} close strictly on T (the multiplicative-group surface).

The shared * clause is idempotent in C++ concepts; the union names the full set of operators a field-style callsite needs to write plain field arithmetic in C++ syntax.

Canonical positive witness: Rational for any HasRingOperators I.

Shape vs. semantics: HasFieldOperators<unsigned int> fires (the literal +, -, *, / all close on unsigned int and unsigned int{1} is well-formed), even though the textbook claim "@c unsigned int is a field" is false (integer / is truncation, not field inverse; 5/3 = 1, not 5/3). The semantic claim lives in IsField, gated by the species-trait registry; HasFieldOperators is shape-only. The shape concept does refuse on narrow unsigned types (unsigned char, unsigned short — integer promotion lifts the result of + and * to int) and on bool (same reason).

Introduced under #394 as the user-requested ℚ-deal companion of HasRingOperators / HasGroupOperatorsAdd.

field__StdLibrary_Analog

The C++ standard library's closest analog is std::is_arithmetic_v<T> (in <type_traits>): true iff T is one of the built-in arithmetic types (the integral types — including bool, char, the signed/unsigned variants — and the floating-point types). The two predicates are not equivalent but carry a clear relationship:

• HasFieldOperators is broader: it accepts user-defined types whose literal field operator surface closes (Rational, Complex<F>, QuadraticReal<D>); std::is_arithmetic does not lift to user types.
• HasFieldOperators is narrower at the integer-promotion boundary: the operator surface requires {a + b} {->} {std::same_as<T>} closure, but C++ integer promotion lifts the result of arithmetic on the narrow integer types to int — so bool (logical operators replace the arithmetic role; + / * promote), the narrow unsigned types (unsigned char, unsigned short), and the narrow signed types (signed char, short) all satisfy std::is_arithmetic but not HasFieldOperators. Closure fires at int / long and at the floating-point types.

In short: HasFieldOperators is the user-extensible refinement of what std::is_arithmetic names mechanically for the built-in types only. The static_asserts below pin the relationship at the built-in carriers where the two agree and where they intentionally diverge.

See also

https://en.cppreference.com/w/cpp/types/is_arithmetic