"Anders F Björklund" <afb@algonet.se> wrote in message news:d0vphn$hgt$3@digitaldaemon.com...
> Walter wrote:
>
> > When I go back to writing C++ code, I'll sometimes put in a
cast(type)expr,
> > and then just look at it in confusion as to why it fails to compile <g>.
>
> That should be easy enough to fix, though ?
>
> #define cast
>
> ;-)

Just goes to show, as you can write FORTRAN in C, you can write Pascal in C (#define BEGIN { #define END } ), you can now write D in C!

On Fri, 11 Mar 2005 15:26:23 +0100, Anders F Björklund <afb@algonet.se> wrote:
> This sounds a lot like renaming "key in array" to "array.contains(key)",
> that is: changing syntax so that it looks like a method/function call...

Just to interject (I don't want to divert this thread, but..)

My suggestion was not a "renaming" of "in" to "contains".
My suggestion is that "in" goes back to returning/resulting in bool, contains is added to avoid double lookups and [] throws an exception when the key is missing.

> I must say that I don't really like it. As with the associative arrays,
> there is nothing stopping for instance a wrapper class to have such a
> method implemented for it ?

Yes, but my view is that I should not need a wrapper for something this basic, if I do, the built-in type is incomplete.

> (kinda like how the .ptr property works now)
> But changing the built-in expressions to look like object method calls ?

I would actually prefer if some built-in expressions eg.

char[] a;

a.sort;
a.reverse;

looked more like method calls.

Regan

Hey,

> Maybe you like "byte[] (somestring)" better ? (It's Pascal-style...)
> I think that D should keep following the C / Java syntax, myself.

Oh no! That would get very complicated, I bet. int i = int some_float; damn.

> I would think you should find cast(x) to be easier than just (x), but...
> (at least you have a special keyword to put your brain into "cast mode")

Yes, 'cast' should definately stay :-)

>> Ow yes, I am totally for that. Please, I never meant to critizize D's context free grammar. We can keep the 'cast', but... make it look different. cast[int] has the same problems, being an existing syntax (AA) for something completely different. Dare I suggest cast<int> ??
>
> Just sounds like the C++ casts, but without the variations ? As in: all of the same ugliness, but none of the advantages...

Well, 'without the variations' is a big advantage. A single 'cast' to worry about.. cast<type>, but no idea how that would parse / whether it's context free or not..

Lionello.

Lionello Lunesu wrote:

>>Maybe you like "byte[] (somestring)" better ? (It's Pascal-style...)
> 
> Oh no! That would get very complicated, I bet. int i = int some_float; damn.

I didn't actually suggest it, just noted what that other language used.

BTW;
The parenthesis were not optional: Int i := Int (some_float); { damn }

>>Just sounds like the C++ casts, but without the variations ?
> 
> Well, 'without the variations' is a big advantage. A single 'cast' to worry about.. cast<type>, but no idea how that would parse / whether it's context free or not..

I suppose it just looks like a typo, to someone versed in C++ ?
(a typo between "(type)" and "reinterpret_cast<type>", that is)

Seems better to have a "new" syntax, for a "new" cast operator.

--anders

>> Well, 'without the variations' is a big advantage. A single 'cast' to worry about.. cast<type>, but no idea how that would parse / whether it's context free or not..
>
> I suppose it just looks like a typo, to someone versed in C++ ?
> (a typo between "(type)" and "reinterpret_cast<type>", that is)

I bet a lot of D seems like a typo to a C++ programmer. I bet s/he thinks the programmer forgot a lot...

L.