Add Promoted to std.traits.

[tsbockman]

Add a Promoted!T trait which evaluates to the type used for (non-unary) arithmetic operations on type T. Example: static assert(is(typeof(Promoted!ubyte == int)));.

[JackStouffer]

ushort?

[tsbockman]

static assert(is(typeof(real.mant_dig) == int));

[aG0aep6G]

Is "fixed point" the right term for this? I would expect a number with a fractional part (with fixed precision) behind that name.

[tsbockman]

Is "fixed point" the right term for this?

I intended it as the opposite of isFloatingPoint, since isFixedPoint == (isScalarType && !isFloatingPoint). Do you have a suggestion for a better name?

I would expect a number with a fractional part (with fixed precision) behind that name.

All matching types have a fixed precision of zero places after the decimal point.

[andralex]

Interesting rationale, but the converse of floating point is not fixed point; the latter is a mere alternative for implementing approximations of real numbers. Integrals and their ilk are a distinct matter.

How frequent is this likely to be? Should it include integral enum types?

[tsbockman]

Interesting rationale, but the converse of floating point is not fixed point...

I am not particularly attached to the isFixedPoint name - I'm just waiting for someone to suggest something better: descriptive and meaningfully shorter than the implementation.

How frequent is this likely to be [used]?

When converting functions into templates, people tend to replace the parameter int a with A a ... if (isIntegral!A). The two are not fully compatible, though, because int a will accept bool, char, and wchar as well.

The range of types accepted by A a ... if (isFixedPoint!A) is much closer to those accepted by int a. In my opinion most template functions with isIntegral in the constraints are candidates for conversion to isFixedPoint, instead.

Of course, the whole thing is just a hack to work around a weakness in the language: the inability to declare a template function in such a way that type deduction works properly when implicit conversions are involved.

Should it include integral enum types?

I considered it unwise to deviate from the behaviour of the existing isWhatever traits, so it does the same thing that isIntegral does: it gives the same answer for an enum type as it would for the enum's base type.

[JackStouffer]

LGTM

You should email Andrei as these are name additions

[andralex]

What would be an example of unifying FP and integral precision?

[tsbockman]

A floating-point type F can losslessly represent all possible values of an integral type N if-and-only-if precision!T >= precision!N.

This trait is used by smartOp to help compute the optimal common numeric type for multi-argument functions like binary().

[JackStouffer]

Anyone else?

[tsbockman]

Anyone else?

Unresolved:

• A less confusing name is needed for isFixedPoint, but none has been suggested yet.
• @andralex has not yet made a decision about precision.

[andralex]

To move forward with this PR, I suggest it be reduced to only add Promoted. I don't think precision and isFloatingPoint (under any name) add enough value. At any rate those can be added later with the appropriate evidence.

[andralex]

(removing my label after posting my response)

[JackStouffer]

Ping @tsbockman

[tsbockman]

@JackStouffer I have removed precision and isFixedPoint from this PR, added a changelog entry, and tweaked the examples slightly to make it clearer what Promoted is for.

[JackStouffer]

Andrei has approved the addition and the code, no one else has objected, so I'm pulling

[JackStouffer]

Auto-merge toggled on