complex number support

[Quirin Schroll]

On Sunday, 15 February 2026 at 21:04:17 UTC, Timon Gehr wrote:
> On 2/9/26 12:20, Quirin Schroll wrote:
>> 
>> If you want to make D’s imaginary and complex types perfect, 
>> allow for an implicit conversion from floating point types to 
>> complex types that are bigger. I can’t remember how often I’ve 
>> written `+ 0i`.
>
> Apparently that used to exist and was removed:
> https://forum.dlang.org/post/di2p73$2mgj$1@digitaldaemon.com

On Thursday, 6 October 2005 at 09:02:28 UTC, Don Clugston wrote:
> […]
> In general, implicit conversions from non-complex to complex 
> types actually *increases* the number of casts required. We'd 
> be better off without them.
>
> The underlying problem is that implicit casts mean that a 
> conversion from `float` or `double` to `real` is not considered 
> superior to a conversion to `creal`, so that ambiguities arise 
> very easily.
> […]

I think the last argument isn’t correct anymore. Absolutely 
no-one is going to ask for an implicit conversion of `cT` to `T` 
unless VRP can prove it must have an imaginary part of `0i`. So, 
you have `float` → `real` → `creal`. So, in a situation where a 
`real` and a `creal` overload compete, the `real` one wins 
because there’s no generally viable `creal` → `real` conversion.

On the other hand, yes, if `cfloat` and `real` compete, they’re 
both a match with conversion and there’s no conversion between 
them, so partial ordering can’t determine one of them the best 
match. I can’t really imagine a situation where you have 
`f(cfloat)` and `f(double)`/`f(real)`, but not also `f(float)`.

This seems to be that kind of situation: “Doctor, it hurts if I 
hit me knee with a hammer.” — “Don’t do it, then.”