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>

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

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.

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

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.

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.

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

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

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

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