Remove complex and imaginary types?

[Georg Wrede]

Walter Bright wrote:
> The issue comes up now and then about why have complex and imaginary 
> types, rather than using structs?  

Assuming the opponents of the D programming language are not reading 
this, I'd like to remind you of the upsides.

A language that is C(++) like, and that endorses Complex and Imaginary 
types right in the language itself, gains a few points in any 
"cross-the-tees" language comparison. Additionally, while any 
"self-respecting professional" doesn't let his reputation degrade into 
falling for such "mundaneties", some of the critics (especially those 
who actually are capable of creating their own opinion based on their 
experience and intellect, as opposed to the average opinion at the golf 
club), surely would welcome the notion of having these data types 
chiseled right into the language -- irrespectively of whether there is a 
Canonical library implementation or not.

> All but one of the advantages of having them be core types can be
> addressed with advancing compiler technology.

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).

> Getting rid of them will release 6 keywords, and make the 
> core language simpler.

Now, this is the one subject that gets me downright ballistic. During 
the (some six) years I've been a part of D, I have constantly had a 
problem with this keyword number issue.

I've studied languages, I've taught Computer Programming for years at 
University Level, and, to this day, I haven't got a compelling answer to 
"why less keywords is Better, "Even at the cost of confusing any or all 
of the students of a particular language"".

I've also studied Natural Languages (as in Finnish, Swedish, English, 
German, Spanish, Russian, French), and during those years, I've gotten a 
fair idea of the relation of the number of words versus the number of 
concepts, and how these relate to the understandability and learning 
speed of them.

As a result of this all, I'm definitely of the opinion that "one concept 
warrants one word", and that "the same word for different purposes is 
poison", and that "the same concept with different words is poison".

(Do I have to say "const", anybody???")

> 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.

> 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. Whether the original compiler writer 
bothers to deliver the relevant library implementation or not, is 
besides the issue.

A Serious Language ought to have this notation chiseled down.

=========================================

Now, having said all that, if it turns out that Walter's ONLY suggestion 
here was that instead of simply using "3 + 5i" instead of preceding it 
with "import std.complex" -- please, then, disreagard this entire post.

Still, some of my points may be valid even so. :-)