www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - cast(x)something

reply "Lionello Lunesu" <lio lunesu.removethis.com> writes:
Damn, this must currently be the ugliest construct in D:

somefunction( cast(byte[])somestring );

Honestly, cast(type)identifier, what the hell. It's a syntax that doesn't 
fit any other construction. 'casting' feels like a function call (it takes 
some input value, possibly changes it, and returns another value), so 
something.castTo(x) makes a lot more sense and fits an existing syntax.

I know it was suggested before, but... I just can't believe people actually 
type cast(x)foo :-S

At least in C++ the syntax was compatible with existing constructions 
dynamic_cast<class>(someobject) can in fact be manually implemented as a 
template function.

I've tried something in D, but didn't work. It probably shouldn't work, but 
I don't understand the error messages. And why is there no row number in the 
last message "cannot implicitly..."? By the way, with that 'array4' I'm 
trying to use the feature that a function foo(a) can be called as a.foo(), 
but I noticed it doesn't work for bar(a,b) => a.bar(b).

Lionello Lunesu

<code>

byte[] castToByteArray( char[] a ) { return cast(byte[])a; }

template castTo(A,B) { B ptr = cast(B)A; }

void main(char args[][] )
{
 char[] string = "test";

//ugly :-(
 byte[] array = cast(byte[])string;
//Works
 byte[] array2 = string.castToByteArray();

//dc.d(19): template instance castTo!(string,byte[]) does not match any 
template declaration
//dc.d(19): undefined identifier template instance 
castTo!(string,byte[]).ptr
//dc.d(19): voids have no value
//dc.d(19): cannot implicitly convert expression (template instance 
castTo!(string,byte[]).ptr) of type void to byte[]
 byte[] array3 = castTo!(string,byte[]).ptr;

//dc.d(23): template castTo!(byte[]) is not a member of string
//cannot implicitly convert expression (0) of type int to byte[]
 byte[] array4 = string.castTo!(byte[]);
}

</code>
Mar 11 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Lionello Lunesu wrote:


 Damn, this must currently be the ugliest construct in D:
 
 somefunction( cast(byte[])somestring );


It's not all that different from the C or Java syntax:

somefunction( (byte[]) somestring );

I find it to be very familiar construct, because of that.


 Honestly, cast(type)identifier, what the hell. It's a syntax that doesn't 
 fit any other construction. 'casting' feels like a function call (it takes 
 some input value, possibly changes it, and returns another value), so 
 something.castTo(x) makes a lot more sense and fits an existing syntax.


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

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


 I know it was suggested before, but... I just can't believe people actually 
 type cast(x)foo :-S


"cast" was just added to make D syntax context free. An honorable goal ?

http://www.digitalmars.com/d/expression.html#UnaryExpression


 At least in C++ the syntax was compatible with existing constructions 
 dynamic_cast<class>(someobject) can in fact be manually implemented as a 
 template function.


Hmm, so "dynamic_cast<type>" is pretty, and "cast" is ugly ?

Guess it depends of the Eye of the Beholder, or something... :-)

--anders
Mar 11 2005
next sibling parent reply "Lionello Lunesu" <lio lunesu.removethis.com> writes:
Hallo dar! (That's swedish, right? Just preparing for my holiday.)

I feel the need to mention that I'm no newbie when it comes to C/C++. I've 
typed my share of ugly constructions and syntaxes in C/C++ for way too long 
but I refuse to continue doing it. That's why I'm keeping an eye on D.


 Damn, this must currently be the ugliest construct in D:
 somefunction( cast(byte[])somestring );


 It's not all that different from the C or Java syntax:

 somefunction( (byte[]) somestring );


Yes, indeed it is similar, and I have to admit I find (int)something just as 
ugly. It looks like a reversed function call!


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


I don't necessarily want the 'function call syntax', it was just a 
suggestion. I bet we can come up with an even better syntax; 
[int]something.. Yes, it seems it's the parantheses that I find ugly. They 
are involved in too many things already. cast(x) already looks like a 
function call, but it comes BEFORE an identifier!? Seems my brain needs some 
context to understand that construction :-S


 I know it was suggested before, but... I just can't believe people 
 actually type cast(x)foo :-S


 "cast" was just added to make D syntax context free. An honorable goal ?

 http://www.digitalmars.com/d/expression.html#UnaryExpression


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


 At least in C++ the syntax was compatible with existing constructions 
 dynamic_cast<class>(someobject) can in fact be manually implemented as a 
 template function.


 Hmm, so "dynamic_cast<type>" is pretty, and "cast" is ugly ?


I told you, it must be the parantheses being abused for something new :-)


 Guess it depends of the Eye of the Beholder, or something... :-)


As so many things, I know. Just thought that I'd mention it, in case 
somebody is keeping a list of ugly things that some folks think might be 
improved :-&

Lionello.
Mar 11 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Lionello Lunesu wrote:


 Hallo dar! (That's swedish, right? Just preparing for my holiday.)


Yes, that is correct! It's spelled "hallå där", but it doesn't matter.


It's not all that different from the C or Java syntax:
somefunction( (byte[]) somestring );


 
 Yes, indeed it is similar, and I have to admit I find (int)something just as 
 ugly. It looks like a reversed function call!


I figured as much, actually. It's like when Matthew mentions in passing
that he hates Java, which explains a few dislikings of some D parts :-)

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


 I don't necessarily want the 'function call syntax', it was just a 
 suggestion. I bet we can come up with an even better syntax; 
 [int]something.. Yes, it seems it's the parantheses that I find ugly. They 
 are involved in too many things already. cast(x) already looks like a 
 function call, but it comes BEFORE an identifier!? Seems my brain needs some 
 context to understand that construction :-S


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


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

--anders
Mar 11 2005
parent reply "Lionello Lunesu" <lio lunesu.removethis.com> writes:
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.
Mar 13 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Mar 14 2005
parent "Lionello Lunesu" <lio lunesu.removethis.com> writes:
 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.
Mar 16 2005
prev sibling parent reply Mike Parker <aldacron71 yahoo.com> writes:
Lionello Lunesu wrote:


 completely different. Dare I suggest cast<int> ??


Please, no! I'm trying to escape ugliness like that :)

Actually, D's syntax is quite comfortable once you start 'thinking in 
D'. I think a lot of people coming from Java/C++ backgrounds take 
comfort in the similarities and find the language easy to pick up, but 
everyone seems to find something awkward here and there. cast(x) is 
something I'm quite happy with now. It really stands out when you are 
glancing through a source file, it's second nature once you've typed a 
lot of D, and it's one of the things that makes D actually 'D' instead 
of 'modified C++'.

There are certainly some wrinkles that still need to be ironed out, and 
many differing opinions on what sort of iron to use. But the cast syntax 
  was put in with very few (if any) objections from the community at the 
time and (hopefully) isn't changing anytime soon.
Mar 12 2005
next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
It's been a long while since, but the cast issue was discussed 
thoroughly at the time.

Mike Parker wrote:

 Lionello Lunesu wrote:
 

 completely different. Dare I suggest cast<int> ??


 
 
 Please, no! I'm trying to escape ugliness like that :)
 
 Actually, D's syntax is quite comfortable once you start 'thinking in 
 D'. I think a lot of people coming from Java/C++ backgrounds take 
 comfort in the similarities and find the language easy to pick up, but 
 everyone seems to find something awkward here and there. cast(x) is 
 something I'm quite happy with now. It really stands out when you are 
 glancing through a source file, it's second nature once you've typed a 
 lot of D, and it's one of the things that makes D actually 'D' instead 
 of 'modified C++'.
 
 There are certainly some wrinkles that still need to be ironed out, and 
 many differing opinions on what sort of iron to use. But the cast syntax 
  was put in with very few (if any) objections from the community at the 
 time and (hopefully) isn't changing anytime soon.
Mar 12 2005
prev sibling next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Mike Parker wrote:


 Actually, D's syntax is quite comfortable once you start 'thinking in 
 D'. I think a lot of people coming from Java/C++ backgrounds take 
 comfort in the similarities and find the language easy to pick up, but 
 everyone seems to find something awkward here and there. 


I think that "cast(Type)" syntax is a reasonable compromise between
"(Type)" (as in C and Java) and "whatever_cast<Type>" (found in C++)

Currently it even issues a friendly error message on the old style ?

--anders
Mar 12 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Mike Parker" <aldacron71 yahoo.com> wrote in message
news:d0ugrc$28ba$1 digitaldaemon.com...

 Actually, D's syntax is quite comfortable once you start 'thinking in
 D'. I think a lot of people coming from Java/C++ backgrounds take
 comfort in the similarities and find the language easy to pick up, but
 everyone seems to find something awkward here and there. cast(x) is
 something I'm quite happy with now. It really stands out when you are
 glancing through a source file, it's second nature once you've typed a
 lot of D, and it's one of the things that makes D actually 'D' instead
 of 'modified C++'.


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

Now that I'm used to the cast(type)expr, it just feels right, after an
initial period of awkwardness.

The D cast notation has three advantages - it visually stands out in a
forest of (), it's greppable, and it makes the grammar context-free to
parse.
Mar 12 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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

;-)

--anders
Mar 12 2005
parent "Walter" <newshound digitalmars.com> writes:
"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!
Mar 12 2005
prev sibling parent "Regan Heath" <regan netwin.co.nz> writes:
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
Mar 13 2005
prev sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Lionello Lunesu" <lio lunesu.removethis.com> wrote in message 
news:d0s7g2$203s$1 digitaldaemon.com...


 Honestly, cast(type)identifier, what the hell. It's a syntax that doesn't 
 fit any other construction. 'casting' feels like a function call (it takes 
 some input value, possibly changes it, and returns another value), so 
 something.castTo(x) makes a lot more sense and fits an existing syntax.


I think cast(type)expr is fine, as it's (1) fairly familiar-looking to 
C/C++/Java vets, and (2) could be construed as a sort of template with an 
implied set of second parentheses.  Sort of like cast!(int)(expr).

Though I will agree with you, type.castTo(expr) fits better into the syntax, 
even though it's a bit more cryptic.

int a=int.castTo(float.castTo(x)/float.castTo(y));

As opposed to

int a=cast(int)(cast(float)x/cast(float)y);
Mar 12 2005