Remove complex and imaginary types?

[Bill Baxter]

Georg Wrede wrote:
> Walter Bright wrote:
>> The issue comes up now and then about why have complex and imaginary 
>> types, rather than using structs?  
> No argument there. But then, what is the whole point of the issue? IMHO, 
>  the notion of having them as Fundamental, or Canonical Types in the 
> language, is totally decoupled from the fact that they are or not are 
> handled in some "bundled library".
> 
> The fact that they are recognised in the language itself, is far more 
> valuable than whether they are at all (or Perfectly) addressed in some 
> library (included or not, or even that you have to buy at (possibly 
> outrageous) cost).

There is one thing we'd lose that hasn't been mentioned.
We'd lose the ability to have complex template parameters.

But maybe it's time to extend that capability to all value types, anyway.

>> The remaining advantage is that of imaginary literals, i.e. the i 
>> postfix:
>>
>>     3 + 5i
> 
> I'd really like to reserve the above phrase to be reserved to mean an 
> imaginary number. 

You seem to be mixing up imaginary and complex.
But anyway, as per Don's comment, regardless of what else happens it's 
probably a good idea to make 5i be a complex number with zero real part, 
rather than a pure imaginary number.  And do away with the 
pure-imaginary types.


> If one has the library delivered right with the 
> standard compiler or if one has to walk around the Globe in search of 
> the One library that actually implements it, I'd still want to have this 
> particular notation reserved (in the Language Grammar itself) for this 
> particular purpose.
> 
>> Assuming we solve the literal problem, existing code would only need 
>> to add:
>>
>>     import std.complex;
>>
>> to acquire complex and imaginary types.
> 
> Yes, of course. If the standard library doesn't implement imaginary, 
> then the most rational thing to do would be to write "import 
> whatever.complex". In any case, the notation "3 + 5i" should be reserved 
> for imaginary numbers, period. 

I don't think it could really work that way.  Upon encountering the text 
3+5i the compiler has to know what sort of value to create.  If it has 
to import a module to know what type that is then that module is going 
to have to be somehow hard-coded.  The result is basically that it has 
to be a built-in type.

Unless of course Walter invents a general way to associate literal 
suffixes with user types.

--bb