Remove complex and imaginary types?

Bruce Adams tortoise_74 at yeah.who.co.uk
Mon Jan 7 15:14:18 PST 2008


On Mon, 07 Jan 2008 13:21:21 -0000, renoX <renosky at free.fr> wrote:

> Robert Fraser Wrote:
>
>> Oskar Linde wrote:
>> > Walter Bright wrote:
>> >> The issue comes up now and then about why have complex and imaginary
>> >> types, rather than using structs? All but one of the advantages of
>> >> having them be core types can be addressed with advancing compiler
>> >> technology. Getting rid of them will release 6 keywords, and make the
>> >> core language simpler. Given the increasing complexity of D, this  
>> will
>> >> help.
>> >>
>> >> The remaining advantage is that of imaginary literals, i.e. the i
>> >> postfix:
>> >>
>> >>     3 + 5i
>> >>
>> >> Assuming we solve the literal problem, existing code would only need
>> >> to add:
>> >>
>> >>     import std.complex;
>> >>
>> >> to acquire complex and imaginary types.
>> >
>> > Sounds like a good idea. Complex math is probably only used in a very
>> > small subset of D code, and if most advantages of having the types  
>> built
>> > in are rendered irrelevant I see no reason not to take this  
>> opportunity
>> > to simplify the language.
>> >
>> > Regarding literals, I'd say this is would be an adequate replacement  
>> for
>> > the above expression:
>> >
>> >     3 + 5*i
>> >
>> > And last, getting rid of the creal and ireal keywords can only be a  
>> good
>> > thing. :)
>> >
>>
>> The identifier "i" is rather frequently used, so I don;t think that's a
>> good idea. I'd prefer an opPostfix or something that allows literals
>> with postfixes to be converted to different types. This would be
>> especially nice for dealing with units, i.e.:
>>
>> writef("%s", toMiles(10km + 13ft));
>
> I think that you have the right suggestion here: what's wrong about the  
> complex is that it is a too specific mechanism, having a generic  
> built-in postfix unit mechanism would allow complex, quaternion, unit  
> libraries.. which is very nice.
>
> In theory there is no difference between "cast(km)10 + cast(ft)13" and  
> "10km + 13ft" but in practice there is a big one: the second one is much  
> more readable!
>
> Regards,
> renoX
>
Ignoring my previous post this rings a bell. I'm sure I've seen it in
another language somewhere, probably a dynamic one.



More information about the Digitalmars-d mailing list