Replacing built-in complex? What's this about?

[Stewart Gordon]

Andrei Alexandrescu wrote:
<snip>
> I think that the justification should go the other way. A feature's 
> existence must be justified, not its removal.

I disagree.  It's important to weigh up the benefits against the costs 
of removing a feature.

<snip>
> Cartesian vs. polar is an opt-in, not a must. All operations work
> with both representations, obviously with different performance
> tradeoffs.

But that's almost a vacuous truth at the moment, because no real 
operations have been implemented yet.

>> - D has the potential to supersede Fortran as a scientific programming 
>> language.  Indeed, "Numerical programmers" is one entry in the "Who D 
>> is For" list.  So if Fortran has an excuse for built-in complex, why 
>> not D?
> 
> Because of advancement in compiler technology.

So, is complex scheduled for removal from Fortran?

>> To conclude, while library complex types are a nice idea, there's no 
>> need for them to replace the built-in complex types.  IMO it would 
>> work well to keep the built-in complex types, and have std.complex 
>> available as an alternative for when you want more power than that 
>> provided by the built-in types.  What's more, std.complex should 
>> provide conversions between its complex types and the built-in ones.
>>
>> Thoughts?
> 
> I'd say, to paraphrase: "Although built-in complex types are a nice 
> idea, there's no need for them to replace the library complex types." I 
> took the liberty to replace "while" with "although" because that usage 
> of "while" is considered bad style :o).

They cannot replace the library complex types, because these built-in 
types came first.

> Keeping both complex types around would further degrade justification 
> for the built-in counterpart.

You could just as well claim that library implementations of associative 
arrays, sorting and the like degrade justification for the built-in 
counterparts.  But it's still useful to have the built-in counterparts.

Stewart.