In article <d2jgkd$lpc$1@digitaldaemon.com>, Lionello Lunesu says...
>
> ...
>
>True. Now I wonder what reasons where given to add "is" to the language, where we already had "===" for the same thing.
>
> ...
>L.
>
Lionello, there was a question like this just recently:

? Doesn't "===" and "is" (both operators for comparing to a reference) have the same meaning, which should be used?

Answer from Walter's forum post 20th January 2005: Yes, use "is" from now on.
The === (triple equals) turned out to be a problem distinguishing from ==
(double equals) with some fonts.

David L.

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"

Sean Kelly wrote:

> Perhaps it's my background with C++ (std::vector behaves the same way), but I
> consider this correct behavior.  hash[key] is a valid lvalue, while the result
> of "in" is not.

C++ STL is the only friend that D hashes have in the world :-)

Anyway, the workaround works: key in hash ? hash[key] : key.init

--anders

In article <d2j06f$5c9$1@digitaldaemon.com>, Lionello Lunesu says...
>
>> On the other hand, "as type" reminds me as BASIC, but not in a good way.
>
>You have any good memories from BASIC?

Sure. Actually, I'm still using BASIC, too. It has its uses. It's great for beginners (that's how I began). VBA and its cousins makes it easy to blend documents and scripting together. I just prefer to use the C-style syntax if I can.

>If "as" is associated with basic, it'll never be excepted :-)

For some people, I'm sure that true. For me "as" reminds me of... Dim i As Byte

which seems wordy compared to the C/C++/D syntax...
byte i;

I've been a fan of cast() for years now, so it's not surprising that I haven't
warmed up to the "as" idea since I first saw it a few days ago. ;)

I'm not dead-set against the "as" proposal, I just don't see how it's worth it's potential costs: more bugs would appear while Walter implements it, the release of D 1.0 would be delayed by an extra month or two, more people from C/C++ might be turned off by it ("I'm too cool to use something that looks like /that/!").

jcc7

Lionello Lunesu wrote:
> (...)
> If "as" is associated with basic, it'll never be excepted :-)
> (...)

The "as" casting operator it's also available on C#. In C# the C-style cast throws an exception if the object can't be converted to the type. The "as" cast on the other hand, returns null (Pretty much like in D).

Also, there's a new language for the CLR (I'm using it right now) called Boo. It uses the "as" keyword both as a cast operator and as a type declarator:

class PictureShape:
    [Property(Picture)]
    private m_picture as Image

    def DoSomethingClever(): as Bitmap
        return Image.Clone() as Bitmap

I'm not really sure about the "as" cast operator because it doesn't fix the worst problem of the cast() operator in D, the amount of parenthesis:

f = cast(f)(cast(D)(cast(B)a).toC()).toE())
f = ((a as B).toC() as D).toE() as F

This is an extreme example off course, but I usually get confused and have to start counting parenthesis. It reminds me of another language witch has Lots of Irritating and Stupid Parentheses. :)

Hi..

> ? Doesn't "===" and "is" (both operators for comparing to a reference)
> have the
> same meaning, which should be used?
>
> Answer from Walter's forum post 20th January 2005: Yes, use "is" from now
> on.
> The === (triple equals) turned out to be a problem distinguishing from ==
> (double equals) with some fonts.

Thanks from pointing that out. So it seems there's no argument for "is" that can really be applied to "as" to convince others :-) Too bad.

L.

> As someone already noted the C# cast throws an exception on failure so they needed another operator to do what D's cast does. The fact that C# needs "as" in addition to "cast" to me says they made a mistake. D's "cast" operator does just fine by itself.

I agree. It would be complicating to add a second and different cast operator.

> For concepts that exist in both C and D we should stay close to the C behavior. The "foreach", "is", and "in" features do not exist in C so the argument that since D has those features it should have "as" is moot.

Note that it was a reaction to an argument going something like "it looks too much like [language X] and not enough like C++", so I referred to "in" and "is" as examples where D also differed from C++. In itself this is not an argument for adding "as".

> Casting exist in C and so we should stay close to that.

hash look-up exists in C too, lets stay close to that too then (adding the key on look-up?). Reference equality exists in C too (using a property like .ptr) so why not create a close-to-C form for that: if (A.ptr == B.ptr)...

Exactly my point: D is not C/C++. It looks like them, is based on them, but it's not them!

What makes D better than C/C++? Is it cast(x)? Can do that with a define. The GC? Can do that in C too. The RTTI? C++ has that too. Built-in unittest?

I think it's the fresh look at things. It's the fact that it dares to differ from C/C++!

> I didn't say "as" isn't grepable. I said the current behavior is parsable/grepable/etc.

...Which are not really arguments for cast(x) since "as" is just as parsable (I suppose) and grepable..

L.