I like "as" also.  Probably will not get into D though.

-Craig

"clayasaurus" <clayasaurus@gmail.com> wrote in message news:dahij9$2v2b$1@digitaldaemon.com...
> If you know what type you are looking for. It will take a while to search int = float, bar = foo, char = ubyte, etc. With cast, you just search for 'cast(' and collect them all.
>
> IMO, cast() sticks out like a sore thumb, as it should. It's the reason why C style casting was depreciated...
>
> int bob = (int)floatnum;
>
> It is harder to find this type of cast in the code, I assume 'as' would
> be a little easier to find than (int), but cast() is uglier and easier
> to find.
>
> Should cast's in D blend nicely with the code and be easy to program? I don't think we want to encourage casting, do we?

You're right. D's cast syntax was deliberately chosen to make it stand out. There's a school of thought that says that a cast is indicative either of poor program design or poor language design. But since D is meant to be a practical language, sometimes it's more practical to cast than redesign the whole program! Nevertheless, since casts are a blunt instrument, they should be used with caution and merit attention in a serious code review. Hence the standout syntax.

Hi,

>"clayasaurus" <clayasaurus@gmail.com> wrote in message news:dahij9$2v2b$1@digitaldaemon.com...
>> If you know what type you are looking for. It will take a while to search int = float, bar = foo, char = ubyte, etc. With cast, you just search for 'cast(' and collect them all.
>>
>> IMO, cast() sticks out like a sore thumb, as it should. It's the reason why C style casting was depreciated...
>>
>> int bob = (int)floatnum;
>>
>> It is harder to find this type of cast in the code, I assume 'as' would
>> be a little easier to find than (int), but cast() is uglier and easier
>> to find.
>>
>> Should cast's in D blend nicely with the code and be easy to program? I don't think we want to encourage casting, do we?
>
>You're right. D's cast syntax was deliberately chosen to make it stand out. There's a school of thought that says that a cast is indicative either of poor program design or poor language design. But since D is meant to be a practical language, sometimes it's more practical to cast than redesign the whole program! Nevertheless, since casts are a blunt instrument, they should be used with caution and merit attention in a serious code review. Hence the standout syntax.

This is a very good point, and I suppose it's a good thing that it does that. However, what about using 'as' for the cases where the cast is less "blunt," like a cast-down? Those aren't always bad design. Maybe for unsigned/signed casts?

// Some examples:
class Foo {}
class Bar : Foo {}
class Bob {}
Bar bar = new Foo as Bar; // OK.
Bar bar = new Bob as Bar; // Wrong.

// or:
long l = 1;
string s = "1";
int i = l as int; // OK.
int i = s as int; // Wrong.

Cheers,
--AJG.

"AJG" <AJG_member@pathlink.com> wrote in message news:dal5ps$2fcm$1@digitaldaemon.com...
> This is a very good point, and I suppose it's a good thing that it does
that.
> However, what about using 'as' for the cases where the cast is less
"blunt,"
> like a cast-down? Those aren't always bad design. Maybe for
unsigned/signed
> casts?
>
> // Some examples:
> class Foo {}
> class Bar : Foo {}
> class Bob {}
> Bar bar = new Foo as Bar; // OK.
> Bar bar = new Bob as Bar; // Wrong.
>
> // or:
> long l = 1;
> string s = "1";
> int i = l as int; // OK.
> int i = s as int; // Wrong.

I just don't see that it adds much over the current cast syntax. Furthermore, there are potential parsing problems as in:

    s as int**p;

Does that parse as (s as int*)*p or (s as int)*(*p) ?

Walter wrote:
> "AJG" <AJG_member@pathlink.com> wrote in message
> news:dal5ps$2fcm$1@digitaldaemon.com...
> 
>>This is a very good point, and I suppose it's a good thing that it does
> 
> that.
> 
>>However, what about using 'as' for the cases where the cast is less
> 
> "blunt,"
> 
>>like a cast-down? Those aren't always bad design. Maybe for
> 
> unsigned/signed
> 
>>casts?
>>
>>// Some examples:
>>class Foo {}
>>class Bar : Foo {}
>>class Bob {}
>>Bar bar = new Foo as Bar; // OK.
>>Bar bar = new Bob as Bar; // Wrong.
>>
>>// or:
>>long l = 1;
>>string s = "1";
>>int i = l as int; // OK.
>>int i = s as int; // Wrong.
> 
> 
> I just don't see that it adds much over the current cast syntax.
Compare next

(cast(Interface3)(cast(Interface2)(cast(Interface1)obj).getObjWithInterface2()).getObjWithInterface3()).func();

and

(((obj as Interface1).getObjWithInterface2() as
Interface2).getObjWithInterface3() as Interface3).func();

or

obj.as(Interface1).getObjWithInterface2().as(Interface2).getObjWithInterface3().as(Interface3).func();

IMHO last form is little bit easier to read for human eyes
> Furthermore, there are potential parsing problems as in:
> 
>     s as int**p;
> 
> Does that parse as (s as int*)*p or (s as int)*(*p) ?
> 
>