www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Minor extension to cast syntax

reply Mike <vertex gmx.at> writes:
Hi!

There's some minor thing about the cast syntax that would be very nice to have.
I haven't seen this mentioned here anytime, so ...

cast ( Type ) UnaryExpression

Now, the thing is that casts usually look like ...

cast(type)(some_expression);

... at least in my source code. Most casts need the second pair of parentheses.
So I suggest an additional casting syntax:

cast ( Type, UnaryExpression )

like the VB.Net CStyle ... that thing would be easier to read in complex
expressions (like casting an int to float for some calculation then casting it
back to int, like in drawing stuff that doesn't need to be that accurate.

cast(int)(cast(float)(width - length * position) * scaling);
cast(int, cast(float, width - length * position) * scaling);

After years of writing/reading code you get a pretty good feeling for matching
parentheses when you look at a line of code, but those closing parentheses in
the first line always confuse the eye when you scan the line.

Personally I often forget some parentheses in casts or I find out that I need a
cast after I wrote the expression. Placing the missing parentheses in the first
line is just needlessly complicated. On the other hand the current cast syntax
is perfect when you have a single ... uhm "piece" of expression at the right
hand side of the cast operator, so having the choice between those two forms
would be nice.

Hope that makes sense

-Mike
Oct 31 2007
next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Mike Wrote:


 cast(int)(cast(float)(width - length * position) * scaling);
 cast(int, cast(float, width - length * position) * scaling);


First one looks cleaner to me, but maybe that's just because I'm used to it.
I'm not against adding the syntax, but I'd never use it.
Oct 31 2007
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Mike" wrote

 Hi!

 There's some minor thing about the cast syntax that would be very nice to 
 have. I haven't seen this mentioned here anytime, so ...

 cast ( Type ) UnaryExpression

 Now, the thing is that casts usually look like ...

 cast(type)(some_expression);

 ... at least in my source code. Most casts need the second pair of 
 parentheses. So I suggest an additional casting syntax:

 cast ( Type, UnaryExpression )


Mike,

This sounds like a matter of personal preference.  Since you can already 
achieve the same thing via the current syntax (with very little change), it 
would seem that the cost/reward ratio is awfully high.

-Steve
Oct 31 2007
prev sibling next sibling parent reply Gregor Richards <Richards codu.org> writes:
Blech. Makes it look like you're calling a function with arguments being 
a type and then some expression. The current syntax is more similar to 
calling a templated cast function:

cast(int)(foo)
cast!(int)(foo)

That is, cast is a function with a template parameter of the type you're 
casting it to. This isn't how it's implemented at all of course, but the 
syntax is reminiscent of that, and I think that's the better analogy.

  - Gregor Richards
Oct 31 2007
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 10/31/07, Gregor Richards <Richards codu.org> wrote:

 The current syntax is more similar to
 calling a templated cast function:

 cast(int)(foo)
 cast!(int)(foo)

 That is, cast is a function with a template parameter of the type you're
 casting it to. This isn't how it's implemented at all of course, but the
 syntax is reminiscent of that, and I think that's the better analogy.


Indeed. And in D2, we've now also got

to!(int)(foo)

which follows the same pattern
Oct 31 2007
parent reply Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Janice Caron Wrote:


 On 10/31/07, Gregor Richards <Richards codu.org> wrote:

 The current syntax is more similar to
 calling a templated cast function:

 cast(int)(foo)
 cast!(int)(foo)

 That is, cast is a function with a template parameter of the type you're
 casting it to. This isn't how it's implemented at all of course, but the
 syntax is reminiscent of that, and I think that's the better analogy.


 
 Indeed. And in D2, we've now also got
 
 to!(int)(foo)
 
 which follows the same pattern


to is a difficult word to google. The shriek doesn't help. Would someone care
to enlighten me as to precisely what to does and how a "to" conversion differs
from a cast?
Oct 31 2007
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 10/31/07, Bruce Adams <tortoise_74 yeah.who.co.uk> wrote:

 Indeed. And in D2, we've now also got

 to!(int)(foo)

 which follows the same pattern


 to is a difficult word to google. The shriek doesn't help. Would someone care
to enlighten me as to precisely what to does and how a "to" conversion differs
from a cast?


See
http://digitalmars.com/d/phobos/std_conv.html
Oct 31 2007
parent Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Janice Caron Wrote:


 On 10/31/07, Bruce Adams <tortoise_74 yeah.who.co.uk> wrote:

 Indeed. And in D2, we've now also got

 to!(int)(foo)

 which follows the same pattern


 to is a difficult word to google. The shriek doesn't help. Would someone care
to enlighten me as to precisely what to does and how a "to" conversion differs
from a cast?


 
 See
 http://digitalmars.com/d/phobos/std_conv.html


Thanks.
Oct 31 2007
prev sibling parent reply Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Gregor Richards Wrote:


 Blech. Makes it look like you're calling a function with arguments being 
 a type and then some expression. The current syntax is more similar to 
 calling a templated cast function:
 
 cast(int)(foo)
 cast!(int)(foo)
 
 That is, cast is a function with a template parameter of the type you're 
 casting it to. This isn't how it's implemented at all of course, but the 
 syntax is reminiscent of that, and I think that's the better analogy.
 
   - Gregor Richards


Surely a cast is really a kind of function opCast() so using function syntax is
appropriate. The old syntax sticks out as unusual. There is that idea in
language design that if it can be done as a function it should be unless there
is a good reason not to. So, having inherited the C like syntax was their ever
a good reason for it? does that reason still apply? If you were starting over
again (as was supposed to be the case with D) would you still do it this way?

Regards,

Bruce.
Oct 31 2007
parent reply Gregor Richards <Richards codu.org> writes:
Bruce Adams wrote:

 Gregor Richards Wrote:
 

 Blech. Makes it look like you're calling a function with arguments being 
 a type and then some expression. The current syntax is more similar to 
 calling a templated cast function:

 cast(int)(foo)
 cast!(int)(foo)

 That is, cast is a function with a template parameter of the type you're 
 casting it to. This isn't how it's implemented at all of course, but the 
 syntax is reminiscent of that, and I think that's the better analogy.

   - Gregor Richards


 
 Surely a cast is really a kind of function opCast() so using function syntax
is appropriate.


My point was not the function syntax, my point was that it was a 
function that takes a type as an argument. That makes no sense.


 The old syntax sticks out as unusual.


Good. Casting is an unusual operation.


 There is that idea in language design that if it can be done as a function it
should be unless there is a good reason not to.


In highly dynamic languages where performance isn't a primary objective, 
yes. Dynamic arrays, anyone?


 So, having inherited the C like syntax was their ever a good reason for it?


Yes. casting is a procedure which is not similar to anything else in C, 
so it has its own syntax.


 does that reason still apply?


Yes, casting is a procedure which is not similar to anything else in D, 
so it has its own syntax.



 If you were starting over again (as was supposed to be the case with D) would
you still do it this way?


I write dynamic languages :)


 
 Regards,
 
 Bruce.
 


  - Gregor Richards
Oct 31 2007
parent reply Gregor Richards <Richards codu.org> writes:
Gregor Richards wrote:

 There is that idea in language design that if it can be done as a 
 function it should be unless there is a good reason not to.


 
 In highly dynamic languages where performance isn't a primary objective, 
 yes. Dynamic arrays, anyone?
 


I should also mention, while I'm at it, that this can NOT be done as a 
function.

  - Gregor Richards
Oct 31 2007
next sibling parent reply Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Gregor Richards Wrote:


 Gregor Richards wrote:

 There is that idea in language design that if it can be done as a 
 function it should be unless there is a good reason not to.


 
 In highly dynamic languages where performance isn't a primary objective, 
 yes. Dynamic arrays, anyone?
 


 
 I should also mention, while I'm at it, that this can NOT be done as a 
 function.
 
   - Gregor Richards


It could if your language was dynamic enough to support types as first class
objects so that no meta syntax was required. :)
Oct 31 2007
next sibling parent reply Gregor Richards <Richards codu.org> writes:
Bruce Adams wrote:

 Gregor Richards Wrote:
 

 Gregor Richards wrote:

 There is that idea in language design that if it can be done as a 
 function it should be unless there is a good reason not to.


 In highly dynamic languages where performance isn't a primary objective, 
 yes. Dynamic arrays, anyone?


 I should also mention, while I'm at it, that this can NOT be done as a 
 function.

   - Gregor Richards


 
 It could if your language was dynamic enough to support types as first class
objects so that no meta syntax was required. :)
 


Yeah, but that's a matter of goals ... I love dynamic languages, my pet 
language is entirely prototype-based, so "types" are really just 
prototype objects, and are therefore passable like any other object. It 
makes things like generics really easy and intuitive, and of course 
casting is just one comparison away :)

But D is a static language, and has different goals.

  - Gregor Richards
Oct 31 2007
parent reply Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Gregor Richards Wrote:


 Bruce Adams wrote:

 Gregor Richards Wrote:
 

 Gregor Richards wrote:

 There is that idea in language design that if it can be done as a 
 function it should be unless there is a good reason not to.


 In highly dynamic languages where performance isn't a primary objective, 
 yes. Dynamic arrays, anyone?


 I should also mention, while I'm at it, that this can NOT be done as a 
 function.

   - Gregor Richards


 
 It could if your language was dynamic enough to support types as first class
objects so that no meta syntax was required. :)
 


 
 Yeah, but that's a matter of goals ... I love dynamic languages, my pet 
 language is entirely prototype-based, so "types" are really just 
 prototype objects, and are therefore passable like any other object. It 
 makes things like generics really easy and intuitive, and of course 
 casting is just one comparison away :)
 
 But D is a static language, and has different goals.
 
   - Gregor Richards


Agreed but wouldn't it be nice to find a language with the best of both world?
By the way, which is your pet language.

Regards,

Bruce.
Oct 31 2007
parent Gregor Richards <Richards codu.org> writes:
Bruce Adams wrote:

 Gregor Richards Wrote:
 

 Bruce Adams wrote:

 Gregor Richards Wrote:


 Gregor Richards wrote:

 There is that idea in language design that if it can be done as a 
 function it should be unless there is a good reason not to.


 In highly dynamic languages where performance isn't a primary objective, 
 yes. Dynamic arrays, anyone?


 I should also mention, while I'm at it, that this can NOT be done as a 
 function.

   - Gregor Richards


 It could if your language was dynamic enough to support types as first class
objects so that no meta syntax was required. :)


 Yeah, but that's a matter of goals ... I love dynamic languages, my pet 
 language is entirely prototype-based, so "types" are really just 
 prototype objects, and are therefore passable like any other object. It 
 makes things like generics really easy and intuitive, and of course 
 casting is just one comparison away :)

 But D is a static language, and has different goals.

   - Gregor Richards


 
 Agreed but wouldn't it be nice to find a language with the best of both world?
By the way, which is your pet language.
 
 Regards,
 
 Bruce.


A little language I call "Plof". http://www.codu.org/plof/

Plof2 is the current incarnation, which (as with Plof1) is giving way to 
Plof3 :P ... suffice to say that Plof isn't really a usable language 
yet, I mainly use it as an environment for playing with language design.

  - Gregor Richards
Oct 31 2007
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Bruce Adams wrote:

 Gregor Richards Wrote:
 

 Gregor Richards wrote:

 There is that idea in language design that if it can be done as a 
 function it should be unless there is a good reason not to.


 In highly dynamic languages where performance isn't a primary objective, 
 yes. Dynamic arrays, anyone?


 I should also mention, while I'm at it, that this can NOT be done as a 
 function.

   - Gregor Richards


 
 It could if your language was dynamic enough to support types as first class
objects so that no meta syntax was required. :)
 


D could very well allow types as function parameters, and that wouldn't 
require any particular dynamicness or anything like that to the 
language. It would just a be a uniformization of function and template 
syntax for invocation and declaration, and, if done well, it could be a 
very cool addition (especially with the coming of AST macros). We have 
already some advances in this, like CTFE. Indeed, templates are really 
just compile time functions, which are also able to take some 
compile-time only constructs (such as types, aliases, etc.).



-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Nov 03 2007
prev sibling parent BCS <BCS pathlink.com> writes:
Gregor Richards wrote:

 Gregor Richards wrote:
 

 There is that idea in language design that if it can be done as a 
 function it should be unless there is a good reason not to.



 In highly dynamic languages where performance isn't a primary 
 objective, yes. Dynamic arrays, anyone?


 
 I should also mention, while I'm at it, that this can NOT be done as a 
 function.
 
  - Gregor Richards



you sort of can. Allow static virtual member function
and then let types (including built in's) define
opCastFrom's Then this

cast(T)(r);

gets rewritten as this

T.opCastFrom(r);

where the T is a "runtime Type variable" that is in
fact just a v-tbl pointer.

Except for the static virtual member functions, if any
of that gets implemented I will fly out to Seattle and
throw new WetSpaghetti();// at Walter.
Oct 31 2007