"Lionello Lunesu" <lio@lunesu.removethis.com> wrote in message news:d2gp84$r5u$1@digitaldaemon.com...
> Remember me? I'm the guy that didn't like the syntax "cast(type)variable". Sorry to bring this up again...
>
> I recently came across some code while browsing, something like this:
>
> if (obj as SomeTypeName) ....
>
> I don't remember what language it was, but I liked that construction. The keyword "as" would fit nicely in D, like "in", "is", "isnot": it's practically english.
>
> It shouldn't replace cast(type) but maybe exist next to it, like === for "is" and !== for "isnot" exist next to eachother.
>
> So... Who else likes "as" for casting?
>
> Lionello
>
> (Uhm.. "isnot" doesn't seem to work though; what's the status of it? Will it be added? Patent problems?)

It looks a little wierd to me to type
    ubyte* x = malloc(100) as (ubyte*);
It's not C-like enough. Why change something that ain't broke?

"Lionello Lunesu" <lio@lunesu.removethis.com> wrote in message news:d2gp84$r5u$1@digitaldaemon.com...
> Remember me? I'm the guy that didn't like the syntax "cast(type)variable". Sorry to bring this up again...
>
> I recently came across some code while browsing, something like this:
>
> if (obj as SomeTypeName) ....
>
> I don't remember what language it was, but I liked that construction. The keyword "as" would fit nicely in D, like "in", "is", "isnot": it's practically english.

In C#, casting raises an exception if the types aren't compatible, so 'as' was introduced to return null instead of throwing. I don't think we need this concept in D, since a cast failure returns null anyway.

I'd like to see support for implicit and explicit user-defined conversions so that casts aren't necessary where they don't make sense.

>
> It shouldn't replace cast(type) but maybe exist next to it, like === for "is" and !== for "isnot" exist next to eachother.
>
> So... Who else likes "as" for casting?
>
> Lionello
>
> (Uhm.. "isnot" doesn't seem to work though; what's the status of it? Will it be added? Patent problems?)
> 

I don't like the idea because it's inconsistent with the C-like syntac of D. ie. that the type is always a prefix symbol, not a postfix one.  With that in mind, would having type as a postfix symbol cause any problems with the single-pass nature of the D compiler?


Sean

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:d2hmgo$1rgj$1@digitaldaemon.com...
> writefln("%x",cast(uint)cast(void*)A);
>
> would be
>
> writefln("%x",((A as void*) as uint));
>
> Which looks, to me, even messier and more nonsensical.

Uhm, I think I'd write that as "cast(uint)(cast(void*)A)" which is also messy. Maybe the "as" contstruction would work with one pair of ( ) less?

Furthermore, double casts... Really, that's pretty hacky in the first place. writef* should just print reference types as "0x%16X". Also, references should get a property .ptr so no opCast is called when casting: "A.ptr as uint".

> Something I always thought would be a nice alternative.  In BASIC languages, there are functions such as "str()" and "int()" to cast values (though they're not used that much as most BASICs are weakly typed).  Why not just make it possible to use types as.. functions?
>
> writefln("%x",uint(void*(A)));
>
> Then I remembered, this would probably clash with a _bunch_ of existing syntaxes (syntaces?).

This has something to do with a context free grammar, that's what D's grammar seems to be and C/C++ not. Probably parsers a lot easier, but don't ask me for details though...

L.

> It looks a little wierd to me to type
>    ubyte* x = malloc(100) as (ubyte*);
> It's not C-like enough. Why change something that ain't broke?

That's a funny one :-)
It's not C enough! Seems that there are two camps here: those that think D's
too much C (probably java programmers?) and those that think it's not C
enough (those that love STL?).

But really, what about "if (A is B)"? or "if (c in AA)" ? Do we need strange tokens for all operations? I think "as" fits in nicely, being a two letter keyword. Not many clashes, not a useful variable name either: "int as;" has no meaning (as opposed to "length" etc..).

And the "ain't broke", depends who you ask. (whom you ask? :-S)
I still think cast(ubyte*)malloc(100) looks like two function calls, whose
results are somehow combined. I know it works, it used it too, no problems
there, but it just looks strange. It's something 'new', a new syntax, and I
hate new stuff :-/

L.

> I'd like to see support for implicit and explicit user-defined conversions so that casts aren't necessary where they don't make sense.

That's a good idea. So if you're casting some type to some other type a lot, you'll simply declare a method for it, and that's the end of it. Nice.

And to prevent double casts (ugh), references should get a property .ptr (like arrays)?

L.

On Fri, 1 Apr 2005 09:25:55 +0300, Lionello Lunesu <lio@lunesu.removethis.com> wrote:
> and those that think it's not C
> enough (those that love STL?).

STL is not C. STL is C++.

Regan

Of course, you're right.... :-/
I was just referring to the extreme "tokenization" going on in C, with STL
in C++ being the extreme realization of that (I think)..

L.

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsojiytgy23k2f5@nrage.netwin.co.nz...
> On Fri, 1 Apr 2005 09:25:55 +0300, Lionello Lunesu <lio@lunesu.removethis.com> wrote:
>> and those that think it's not C
>> enough (those that love STL?).
>
> STL is not C. STL is C++.
>
> Regan

Lionello Lunesu wrote:
>>It looks a little wierd to me to type
>>   ubyte* x = malloc(100) as (ubyte*);
>>It's not C-like enough. Why change something that ain't broke?
> 
> 
> That's a funny one :-)
> It's not C enough! Seems that there are two camps here: those that think D's too much C (probably java programmers?) and those that think it's not C enough (those that love STL?).

To a certain extent that's true. Many people want D to be almost exactly C. Others want D to much more like Java. In the past, one persistent poster even seemed to want D to have every feature that C# has.

My opinion is that D should share syntax with C when it makes sense (and is easy on the eyes). The cast(type) syntax is close to C, but better IMO. On the other hand, "as type" reminds me as BASIC, but not in a good way. Seems less desirable to me, but I can't really explain why. Maybe I'm just so used to D's cast(type)?

-- 
jcc7
http://jcc_7.tripod.com/d/

On Thu, 31 Mar 2005 15:08:35 +0300, Lionello Lunesu wrote:

> Remember me? I'm the guy that didn't like the syntax "cast(type)variable". Sorry to bring this up again...
> 
> I recently came across some code while browsing, something like this:
> 
> if (obj as SomeTypeName) ....
> 
> I don't remember what language it was, but I liked that construction. The keyword "as" would fit nicely in D, like "in", "is", "isnot": it's practically english.
> 
> It shouldn't replace cast(type) but maybe exist next to it, like === for "is" and !== for "isnot" exist next to eachother.
> 
> So... Who else likes "as" for casting?

I suggest that it is not adequate to 'solve' the problem. "Oh? And what exactly is the 'problem'?", I hear you ask. Well, seeing you asked ... ;-)

Definition: 'Casting' tells the compiler that the declared data type is to be ignored in this instance and that the compiler should instead assume the data type that the coder is explicitly naming. The assumption is that the coder probably knows what they are doing.

There are two categories of 'casting'. One converts data and the other doesn't. Of the converting types, one will not lose any data and the other may lose data. If we want the compiler to warn the coder of potential mistakes when using a cast, the compiler needs to know if the cast is a conversion or not, and if a conversion whether or not it might lose data in the process. The compiler can then warn if data might be lost.

But in order for the compiler to have this much knowledge, it must know about the nature of each data type, and how to do a conversion from one data type to another. For built-in data types, this is of course possible and reasonable. But for user defined data types, such as structures and classes, the coder would have to provide this information to the compiler.

The current cast syntax does not distinguish between the various types of casts. Meaning that if I code ...

   double X;
   uint   Y;
   . . .
   X = cast(double)Y;

the compiler doesn't actually know if you if you are intending to do a conversion or not. It just makes an assumption and issues warnings based on that assumption. Further more, sometimes the assumption is to do a conversion and other times the assumption the compiler makes is to *not* make a conversion. There is not much sense of consistency.

   double X = cast(double)Y;  // Does a conversion.
   int Z = cast(int)Y; // Does not do a conversion.

So, to cut a long story short, wouldn't it be really, really nice, if we could tell the compiler what our intention was, and if needed, how to do a conversion if it didn't already know how.

I figure that something like the 'as' idea (and others) might need to be thrashed around a bit more to help solve the 'problems' outlined above. I also suspect that the much maligned opCast() could be employed somehow to help us too.

Imagine being able to do ...

   struct Q
   { . . .
      void opCast(in double A, out Q B) { . . . }
   };
   Q q;
   double z;
   . . .
   // Copy the bytes of Z, without conversion, to Q.
   q = cast_ptr(byte[])z;
   // Copy the value of z, with conversion, to Q.
   q = cast_as(Q)z;

-- 
Derek
Melbourne, Australia
1/04/2005 4:54:00 PM