Remove complex and imaginary types?

[Simen Kjaeraas]

renoX <renosky at free.fr> wrote:

> Reiner Pope a écrit :
>> Daniel919 Wrote:
>>
>>>>>> 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. 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.
>>>> I do too. And been thinking along the lines of simply putting a hack  
>>>> in that the postfix 'i' means that it's a literal of type  
>>>> 'imaginary', and the compiler looks to see if "std.complex" was  
>>>> imported.
>>>>
>>>> This isn't as outlandish as it sounds, as there's precedent for it  
>>>> both in C++ <typeinfo> and java.lang.String, as well as D's Object.
>>> What about a more general solution like
>>> -----------------------------
>>> import std.stdio, std.conv;
>>>
>>> struct complex {
>>>      real re;
>>>      real im;
>>>      complex opAdd(real r) { return complex(re+r, im); }
>>>      complex opAdd_r(real r) { return complex(re+r, im); }
>>>      complex opAdd(complex c) { return complex(re+c.re, im+c.im); }
>>>      string toString() { return std.conv.toString(re) ~ "+" ~  
>>> std.conv.toString(im) ~ "i"; }
>>> }
>>>
>>> //complex opPostfix("i")(T)(T im) { return complex(0,im); }
>>>
>>> void main() {
>>> //    complex c =      1+5i      +     2+3i       +     6i;
>>>      complex c = 1+complex(0,5) + 2+complex(0,3) + complex(0,6);
>>>      writefln( c );
>>> }
>>> -----------------------------
>>>
>>> This would also allow
>>>
>>> real opPostfix("L")(T)(T x) { return x; }
>>>
>>> T opPostfix("k")(T)(T x) { return x * 1000; }
>>> meter opPostfix("m")(T)(T x) { return meter(x); }
>>  Here's my version from a while back:   
>> http://www.digitalmars.com/d/archives/digitalmars/D/Suffix-based_literal_syntax_53992.html
>>    -- Reiner
>
> I like a lot all those proposal for adding suffix based literal, but I'm  
> afraid that these could interfere(sp?) with the ones already existing in  
> the language, so I wonder if 'library added' suffix shouldn't have an  
> operator to distinguish them for the language one.
>
> I'm thinking about the underscore '_': 5.8f_km would be replaced by  
> km(5.8f), if there is no operator, there are some risk of ambiguity:  
> "5.8fm" is-it 5.8f meters or 5.8 femtometers?
>
> With 5.8f_m and 5.8_fm you remove the ambiguity and the _ is visually  
> 'pleasing' so this syntax would still be used.
>
> Regards,
> renoX
>
>
>
>

Votes++

In addition to removing ambiguity, requiring an initial underscore would  
lower the chance of collisions with other symbols.

---
Simen Kjaeraas