www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Keyword "as" for casting

reply "Lionello Lunesu" <lio lunesu.removethis.com> writes:
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?)
Mar 31 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Lionello Lunesu wrote:


 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.


I like it, better than the reinterpret_cast<SomeTypeName> "alternative".


 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?


Next to the regular one, sounds like a neat idea. Pretty minor, but...


 (Uhm.. "isnot" doesn't seem to work though; what's the status of it? Will it 
 be added? Patent problems?) 


There probably will never be a "isnot" keyword. I think due to ugliness?

It would be much better if Walter could just say that, once and for all.

--anders
Mar 31 2005
parent pragma <pragma_member pathlink.com> writes:
In article <d2gpru$rmu$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

Lionello Lunesu wrote:

 (Uhm.. "isnot" doesn't seem to work though; what's the status of it? Will it 
 be added? Patent problems?) 


There probably will never be a "isnot" keyword. I think due to ugliness?


My personal problem with "isnot" is that it looks like a horribly misnamed Apple
product:

iSnot.

$0.02

- EricAnderton at yahoo.com
Mar 31 2005
prev sibling next sibling parent reply zwang <nehzgnaw gmail.com> writes:
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.



Object Pascal offers the "as" operator, but it is almost never used
in the context like "if (obj as typeName) ...", because an exception will
be raised if obj is not an instance of typeName or its derived types.



 
 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?)
Mar 31 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
zwang wrote:


 Object Pascal offers the "as" operator, but it is almost never used
 in the context like "if (obj as typeName) ...", because an exception will
 be raised if obj is not an instance of typeName or its derived types.


That's the same as how () casts work in Java, with ClassCastException.

In D, however, such a "cast()" will silently return null instead -
which makes constructs such as the "if ( )" above still work...
(it's rather similar to how the "in" works for the dynamic arrays,
it returns a null if it's not present - which works as boolean too)

Of course, it's only pretty if the language treats pointers as booleans.

--anders
Mar 31 2005
prev sibling parent "Lionello Lunesu" <lio lunesu.removethis.com> writes:
"object as Class" should not behave different from cast(Class)object. 
Anyway, you'll get the AccessViolationException or what's it called when you 
actually try to use the null pointer.

Furthermore you can do: assert( object as Class );  Has a nice ring to it, 
doesn't it?

L.
Mar 31 2005
prev sibling next sibling parent Chris Sauls <ibisbasenji gmail.com> writes:
Lionello Lunesu wrote:

 if (obj as SomeTypeName) ....
 
 I don't remember what language it was, but I liked that construction.


Might've been Visual Basic.  I know they have the "as Type" formula for 
variables, so it might have other uses as well.  Having never really 
gotten far with Visual Basic, I couldn't say.  I know XBasic (the 
language VB is literally a rip-off of) uses a colon for such things.  Or 
did some years ago anyhow, haven't touched it in about... seven years.

-- Chris Sauls
Mar 31 2005
prev sibling next sibling parent "Craig Black" <cblack ara.com> writes:
 So... Who else likes "as" for casting?


I like it a lot.  Very elegant.

-Craig
Mar 31 2005
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Lionello Lunesu" <lio lunesu.removethis.com> wrote in message 
news:d2gp84$r5u$1 digitaldaemon.com...

 So... Who else likes "as" for casting?


I suppose it looks a bit nicer, but I have two problems with it:  one, I 
don't really find anything wrong with cast(type), and two, it would be quite 
a change to have to write casts "backwards."  For example, a double cast, 
which looks like..

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.

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?).
Mar 31 2005
next sibling parent brad domain.invalid writes:
Personally, I quite like the "object as type" syntax.  However - I don't 
think that D should have two completely different ways to do the same 
thing.  So while I like it, I think that it shouldn't be used because we 
already have a construct that does that job.  Now, if you could somehow 
get cast(type)object deprecated, and "object as type" made the One True 
Way of doing casting, then I would agree :)

Brad
Mar 31 2005
prev sibling parent "Lionello Lunesu" <lio lunesu.removethis.com> writes:
"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.
Mar 31 2005
prev sibling next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"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?
Mar 31 2005
parent reply "Lionello Lunesu" <lio lunesu.removethis.com> writes:
 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.
Mar 31 2005
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
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
Mar 31 2005
parent "Lionello Lunesu" <lio lunesu.removethis.com> writes:
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
Mar 31 2005
prev sibling next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
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 


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/
Mar 31 2005
parent reply "Lionello Lunesu" <lio lunesu.removethis.com> writes:
 On the other hand, "as type" reminds me as BASIC, but not in a good way.


You have any good memories from BASIC?
If "as" is associated with basic, it'll never be excepted :-)

L.
Apr 01 2005
next sibling parent J C Calvarese <jcc7 cox.net> writes:
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
Apr 01 2005
prev sibling parent =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
Lionello Lunesu wrote:

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



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. :)
Apr 01 2005
prev sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Lionello Lunesu" <lio lunesu.removethis.com> wrote in message 
news:d2iphk$304d$1 digitaldaemon.com...

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


C and C++ are very different. D should keep as close to C as possible and 



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


There is no equivalent to "is" and "in" in C. Casting is a well-known 

significantly will cause confusion.


 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 :-/


It's perfectly fine to not like a syntax. And it's perfectly fine to suggest 
alternatives. I believe, though, in this case the current syntax is the best 
alternative yet proposed. As someone else said it is familiar and easily 
parsable/greppable/etc. These things are always judgement calls so people 
who come to different conclusions are just weighing the factors differently.
Apr 01 2005
next sibling parent reply "Lionello Lunesu" <lio lunesu.removethis.com> writes:
 There is no equivalent to "is" and "in" in C. Casting is a well-known 

 significantly will cause confusion.


I was referring to D and I've used "is" and "in" as examples where the 

used?") route.


 It's perfectly fine to not like a syntax. And it's perfectly fine to 
 suggest alternatives. I believe, though, in this case the current syntax 
 is the best alternative yet proposed. As someone else said it is familiar 
 and easily parsable/greppable/etc. These things are always judgement calls 
 so people who come to different conclusions are just weighing the factors 
 differently.


True. Now I wonder what reasons where given to add "is" to the language, 
where we already had "===" for the same thing.
(And as far as greppability is concerned: "as" is just as greppable; 
parsability? I don't know much about parsing)

L.
Apr 01 2005
next sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
 True. Now I wonder what reasons where given to add "is" to the language, 
 where we already had "===" for the same thing.


It was added in Nov 2003 - here's the archive around that time
http://www.digitalmars.com/d/archives/18188.html
Apr 01 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ben Hinkle wrote:


True. Now I wonder what reasons where given to add "is" to the language, 
where we already had "===" for the same thing.


 
 It was added in Nov 2003 - here's the archive around that time
 http://www.digitalmars.com/d/archives/18188.html


Here's hoping that they can all be left in, even if redundant...
But maybe that's just the Perl guy in me speaking ? (TIMTOWTDI)

But I think it can be useful to have all of "is", "in" and "as" -
even if there are perfectly good other ways to accomplish those:

* "is" is needed, since some people find '===' confusing.
   (even though there is no pretty alternative for '!==')

* "in" is needed, since the hash[key] lookup is broken*...
   (even though it returns a pointer, instead of a bool)

* "as" is needed, since some people don't like cast(type).
   (even though it might look strange, in complex cases)

Hopefully, adding one doesn't mean removing the other one ?
(and if it does, I would still prefer '!==' and 'cast(type)')

--anders

PS.
* I know, I know, it is also needed to separate invalid keys
   from values which happens to have the default value too,
   and to avoid double lookups when both testing and getting.
   (I won't go into that particular topic here, thank you...)
   I meant that it adds new keys, when you just try to read it ?
Apr 01 2005
parent reply Sean Kelly <sean f4.ca> writes:
In article <d2jl9m$qv3$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

* "in" is needed, since the hash[key] lookup is broken*...
   (even though it returns a pointer, instead of a bool)


..

PS.
* I know, I know, it is also needed to separate invalid keys
   from values which happens to have the default value too,
   and to avoid double lookups when both testing and getting.
   (I won't go into that particular topic here, thank you...)
   I meant that it adds new keys, when you just try to read it ?


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.
Apr 01 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Apr 01 2005
prev sibling parent "Lionello Lunesu" <lio lunesu.removethis.com> writes:
Thanks.. I'm now trying to find out what the ultimate reason was, so that I 
can use the same and convice everybody that I'm right... ...right...

L.
Apr 01 2005
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
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.


Personally, I never use "===" because it's too easy to mistype and misread.  In
some respects I do like the alternative tokens in C++, even though no one ever
uses them: and, bitor, or, xor, etc.


Sean
Apr 01 2005
prev sibling parent reply David L. Davis <SpottedTiger yahoo.com> writes:
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!"
Apr 01 2005
parent "Lionello Lunesu" <lio lunesu.removethis.com> writes:
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.
Apr 03 2005
prev sibling parent reply Matthias Becker <Matthias_member pathlink.com> writes:
 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?).


C and C++ are very different. 


Right.


D should keep as close to C as possible 


Why?








[quote]
The as operator is like a cast except that it yields null on conversion failure
instead of raising an exception. More formally, an expression of the form:

expression as type

is equivalent to:

expression is type ? (type)expression : (type)null

except that expression is evaluated only once.

Note that the as operator only performs reference conversions and boxing
conversions. The as operator cannot perform other conversions, such as
user-defined conversions, which should instead be performed using cast
expressions.
[/quote]



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


There is no equivalent to "is" and "in" in C. 


Why is that important? There is no foreach in C. C is a ugly and complicated
language. Why should we stay close to that?


Casting is a well-known 

significantly will cause confusion.







 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 :-/


It's perfectly fine to not like a syntax. And it's perfectly fine to suggest 
alternatives. I believe, though, in this case the current syntax is the best 
alternative yet proposed. As someone else said it is familiar and easily 
parsable/greppable/etc. These things are always judgement calls so people 
who come to different conclusions are just weighing the factors differently. 


greping for 'cast' is easier than greping 'as'? Could you explain that please?

-- Matthias Becker
Apr 01 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
D should keep as close to C as possible


 Why?


The hard part is deciding what "close" means and "as possible". To quote the 
web site: "The general look of D is like C and C++. This makes it easier to 
learn and port code to D. Transitioning from C/C++ to D should feel natural. 
The programmer will not have to learn an entirely new way of doing things."










"as" in addition to "cast" to me says they made a mistake. D's "cast" 
operator does just fine by itself.


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


There is no equivalent to "is" and "in" in C.


 Why is that important? There is no foreach in C. C is a ugly and 
 complicated
 language. Why should we stay close to that?


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. 
Casting exist in C and so we should stay close to that.


Casting is a well-known

significantly will cause confusion.





see above


 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 :-/


It's perfectly fine to not like a syntax. And it's perfectly fine to 
suggest
alternatives. I believe, though, in this case the current syntax is the 
best
alternative yet proposed. As someone else said it is familiar and easily
parsable/greppable/etc. These things are always judgement calls so people
who come to different conclusions are just weighing the factors 
differently.


 greping for 'cast' is easier than greping 'as'? Could you explain that 
 please?


I didn't say "as" isn't grepable. I said the current behavior is 
parsable/grepable/etc.
Apr 01 2005
parent "Lionello Lunesu" <lio lunesu.removethis.com> writes:


 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.
Apr 03 2005
prev sibling next sibling parent reply "John C" <johnch_atms hotmail.com> writes:
"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.



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?)
Mar 31 2005
parent "Lionello Lunesu" <lio lunesu.removethis.com> writes:
 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.
Mar 31 2005
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
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
Mar 31 2005
prev sibling parent Derek Parnell <derek psych.ward> writes:
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
Mar 31 2005