www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Deprecating C style casts

reply "Walter" <newshound digitalmars.com> writes:
Currently, D supports C style casts:

    (type)expression

as well as D style casts:

    cast(type)expression

The C style casts are tricky to parse right, and I think will cause
increasing problems down the road due to the syntactical ambiguities with
it. The D style cast has no such problems, and it has the advantage of being
greppable (as some programming styles consider an explicit cast to be a bug,
and being able to find and check them all to be a Good Thing).

What do people think about first deprecating, then removing, the C style
cast?
May 05 2004
next sibling parent Roel Mathys <roel.mathys yucom.be> writes:
Walter wrote:

 Currently, D supports C style casts:
 
     (type)expression
 
 as well as D style casts:
 
     cast(type)expression
 
 The C style casts are tricky to parse right, and I think will cause
 increasing problems down the road due to the syntactical ambiguities with
 it. The D style cast has no such problems, and it has the advantage of being
 greppable (as some programming styles consider an explicit cast to be a bug,
 and being able to find and check them all to be a Good Thing).
 
 What do people think about first deprecating, then removing, the C style
 cast?
 
 


just do it,
D has no intention of compiling C code, and it will certainly mark the 
spots where something funny is going on

roel
May 05 2004
prev sibling next sibling parent =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
Walter wrote:

 What do people think about first deprecating, then removing, the C style
 cast?


+1

-- 
Julio César Carrascal Urquijo
http://jcesar.f2o.org/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS$ d- s+:+ a-- C++> ULS++ P++ L+> !E W+++ N+ o? K? w++>
O---  M V? PS+ PE Y+ PGP t+ 5- X+++  R- tv+(++) b++> DI!
D++> G e+> h-- r- y+
------END GEEK CODE BLOCK------
May 05 2004
prev sibling next sibling parent C <qbert atari-soldiers.com> writes:
Yea rip em out there.  I vote yes, take away C style casts.

C

On Wed, 5 May 2004 10:04:08 -0700, Walter <newshound digitalmars.com> 
wrote:


 Currently, D supports C style casts:

     (type)expression

 as well as D style casts:

     cast(type)expression

 The C style casts are tricky to parse right, and I think will cause
 increasing problems down the road due to the syntactical ambiguities with
 it. The D style cast has no such problems, and it has the advantage of 
 being
 greppable (as some programming styles consider an explicit cast to be a 
 bug,
 and being able to find and check them all to be a Good Thing).

 What do people think about first deprecating, then removing, the C style
 cast?




-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
May 05 2004
prev sibling next sibling parent "Jeroen van Bemmel" <someone somewhere.com> writes:
please do

deprecate in the next release, remove in the one after that. Fix is trivial 
enough to warrant such a short period

"Walter" <newshound digitalmars.com> wrote in message 
news:c7b6vn$1o0h$1 digitaldaemon.com...

 Currently, D supports C style casts:

    (type)expression

 as well as D style casts:

    cast(type)expression

 The C style casts are tricky to parse right, and I think will cause
 increasing problems down the road due to the syntactical ambiguities with
 it. The D style cast has no such problems, and it has the advantage of 
 being
 greppable (as some programming styles consider an explicit cast to be a 
 bug,
 and being able to find and check them all to be a Good Thing).

 What do people think about first deprecating, then removing, the C style
 cast?
May 05 2004
prev sibling next sibling parent reply imr1984 <imr1984_member pathlink.com> writes:
i dont see what's wrong with C style casts. Exactly how would this proposal
reduce my D-coding bugs?

In article <c7b6vn$1o0h$1 digitaldaemon.com>, Walter says...

Currently, D supports C style casts:

    (type)expression

as well as D style casts:

    cast(type)expression

The C style casts are tricky to parse right, and I think will cause
increasing problems down the road due to the syntactical ambiguities with
it. The D style cast has no such problems, and it has the advantage of being
greppable (as some programming styles consider an explicit cast to be a bug,
and being able to find and check them all to be a Good Thing).

What do people think about first deprecating, then removing, the C style
cast?
May 05 2004
parent reply Andy Friesen <andy ikagames.com> writes:
imr1984 wrote:


 i dont see what's wrong with C style casts. Exactly how would this proposal
 reduce my D-coding bugs?


I don't think it will.

What it will do is make the compiler simpler, and the language easier to 
parse.  That means that the compiler will be faster, and code analyzing 
tools will be better.

  -- andy
May 05 2004
parent reply "Chr. Grade" <tickle everymail.net> writes:
The closer D will remain related to C and Cpp, the more likely people 
are willing to have a closer look at D and programm with it and switch 
to it. D has to be intuitive for D-newbies. I merely tried D because it 
looked and felt so familiar.
I'd be more than disencouraged if C/Cpp style casts were missing, 
because I'm simply used to them; I like them.


 
 I don't think it will.
 
 What it will do is make the compiler simpler, and the language easier to 
 parse.  That means that the compiler will be faster, and code analyzing 
 tools will be better.
 
  -- andy
May 05 2004
next sibling parent "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Chr. Grade" <tickle everymail.net> wrote in message
news:c7bdm6$217m$1 digitaldaemon.com...

 The closer D will remain related to C and Cpp, the more likely people
 are willing to have a closer look at D and programm with it and switch
 to it. D has to be intuitive for D-newbies. I merely tried D because it
 looked and felt so familiar.
 I'd be more than disencouraged if C/Cpp style casts were missing,
 because I'm simply used to them; I like them.


You will easilly get used to D casts because they better show the intention
of the programmer, they are much easier to parse, and find in the code.


 I don't think it will.

 What it will do is make the compiler simpler, and the language easier to
 parse.  That means that the compiler will be faster, and code analyzing
 tools will be better.

  -- andy
May 05 2004
prev sibling next sibling parent reply Andy Friesen <andy ikagames.com> writes:
Chr. Grade wrote:


 
 The closer D will remain related to C and Cpp, the more likely people 
 are willing to have a closer look at D and programm with it and switch 
 to it. D has to be intuitive for D-newbies. I merely tried D because it 
 looked and felt so familiar.
 I'd be more than disencouraged if C/Cpp style casts were missing, 
 because I'm simply used to them; I like them.


It seems a pretty tiny syntactic spec, don't you think?  The meaning of 
a cast is still utterly the same; it's just one tiny keyword which just 
so happens to vastly simplify things for the implementors.

  -- andy
May 05 2004
parent reply "Chr. Grade" <tickle everymail.net> writes:
Either D feels like C/Cpp or it doesn't. Such thing obscures the 
relation to C/Cpp and puts up an obstacle for frist timers.
C style casts will be cut out first. And what's next? How many times 
will I have to partially rewrite my code. Over and over? Every time a 
new compiler version is released?
Programming at Walter's and the D-community's mercy. So, that's the 
downside of D?

And where's the C hardcore faction?


 Chr. Grade wrote:
 

 The closer D will remain related to C and Cpp, the more likely people 
 are willing to have a closer look at D and programm with it and switch 
 to it. D has to be intuitive for D-newbies. I merely tried D because 
 it looked and felt so familiar.
 I'd be more than disencouraged if C/Cpp style casts were missing, 
 because I'm simply used to them; I like them.


 
 
 It seems a pretty tiny syntactic spec, don't you think?  The meaning of 
 a cast is still utterly the same; it's just one tiny keyword which just 
 so happens to vastly simplify things for the implementors.
 
  -- andy
May 05 2004
next sibling parent reply Chris Lawson <cl mangler.tinfoilhat.ca> writes:
Chr. Grade wrote:

 
 Either D feels like C/Cpp or it doesn't. Such thing obscures the 
 relation to C/Cpp and puts up an obstacle for frist timers.
 C style casts will be cut out first. And what's next? How many times 
 will I have to partially rewrite my code. Over and over? Every time a 
 new compiler version is released?
 Programming at Walter's and the D-community's mercy. So, that's the 
 downside of D?


Keep in mind that the compiler version hasn't crested 1.0 yet.  I doubt 
there will be syntax changes within the 1.x branch.  Even within a 
pre-release compiler the plan is to deprecate then remove C casts, that 
seems reasonable.


 
 And where's the C hardcore faction?


Not to put too fine a point on it; they're probably still coding away in 
C and ignoring most imperative language innovations from the last couple 
decades.

Chris


 

 Chr. Grade wrote:


 The closer D will remain related to C and Cpp, the more likely people 
 are willing to have a closer look at D and programm with it and 
 switch to it. D has to be intuitive for D-newbies. I merely tried D 
 because it looked and felt so familiar.
 I'd be more than disencouraged if C/Cpp style casts were missing, 
 because I'm simply used to them; I like them.




 It seems a pretty tiny syntactic spec, don't you think?  The meaning 
 of a cast is still utterly the same; it's just one tiny keyword which 
 just so happens to vastly simplify things for the implementors.

  -- andy
May 05 2004
parent reply "Chr. Grade" <tickle everymail.net> writes:
I love this hazy nuance of absolutism; especially "imperative language 
innovation".


 And where's the C hardcore faction?
 
 Not to put too fine a point on it; they're probably still coding away in 
 C and ignoring most imperative language innovations from the last couple 
 decades.
 
 Chris
May 05 2004
parent reply Chris Lawson <cl mangler.tinfoilhat.ca> writes:
My point is that anyone who would refuse to change their casting syntax 
probably isn't looking around for new programming languages in the first 
place.

Chris

Chr. Grade wrote:


 
 I love this hazy nuance of absolutism; especially "imperative language 
 innovation".
 

 And where's the C hardcore faction?

 Not to put too fine a point on it; they're probably still coding away 
 in C and ignoring most imperative language innovations from the last 
 couple decades.

 Chris
May 05 2004
parent reply "Chr. Grade" <tickle everymail.net> writes:
I'm not looking for a new language, but an enhancement of C/Cpp.
People looking for a completely new language won't chose D.

Chris Lawson wrote:

 My point is that anyone who would refuse to change their casting syntax 
 probably isn't looking around for new programming languages in the first 
 place.
 
 Chris
May 05 2004
parent reply Chris Lawson <cl mangler.tinfoilhat.ca> writes:
Chr. Grade wrote:


 
 I'm not looking for a new language, but an enhancement of C/Cpp.


And you want enhancements with zero change in syntax?  I don't think 
that's reasonable.


 People looking for a completely new language won't chose D.


I don't see how that follows.

Chris


 
 Chris Lawson wrote:
 

 My point is that anyone who would refuse to change their casting 
 syntax probably isn't looking around for new programming languages in 
 the first place.

 Chris
May 05 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Chris Lawson" <cl mangler.tinfoilhat.ca> wrote in message
news:c7bmsl$2gi0$1 digitaldaemon.com...

 Chr. Grade wrote:


 I'm not looking for a new language, but an enhancement of C/Cpp.


 And you want enhancements with zero change in syntax?  I don't think
 that's reasonable.


 People looking for a completely new language won't chose D.


 I don't see how that follows.


Nor is it borne out in experience. I have turned three people onto D who've not
previously used C or C++ (other than to be scared of them, that is).

None of them have yet seen fit to join the rambunctious debate that is the D
newsgroup(s), but they are using the language.
May 05 2004
prev sibling next sibling parent reply "Unknown W. Brackets" <unknown at.simplemachines.dot.org> writes:
Chr. Grade wrote:

 
 Either D feels like C/Cpp or it doesn't. Such thing obscures the 
 relation to C/Cpp and puts up an obstacle for frist timers.
 C style casts will be cut out first. And what's next? How many times 
 will I have to partially rewrite my code. Over and over? Every time a 
 new compiler version is released?
 Programming at Walter's and the D-community's mercy. So, that's the 
 downside of D?
 
 And where's the C hardcore faction?
 


While personally I am happy with the old syntax.... it did always say to 
me "not C-ish".  I don't know how you can call it "like C/Cpp" when it 
doesn't even seem consistent with the rest of the language.

I mean, every single other way, parenthesis without letters before them 
mean "expression".  If I see (asdfgh), it means to me "the value of the 
variable asdfgh".... but if I see (asdfgh) 1, I have to realize this 
means "1 as a asdfgh".

Now, truthfully, the new method has a problem in conformity itself, in 
that cast(asdfgh) 1 still looks a bit odd in that no other C/D code is 
like that..... but it is worlds better to me than the old method, 
because it makes it clearer that it's *doing something* and not just a 
silly expression.

So, to me, cast(asdfgh) "feels" more like C than even the (asdfgh) I'm 
used to.

You don't have to agree... but, don't think it's programming at the 
"mercy" of anyone - unless you are going to tell me that there is not 
one thing you think is not *PERFECT* about C... otherwise, you were at 
the "mercy" of its designers as well just as much as you are now at the 
"mercy" of D's.

But.... if you thought C is perfect, why would you be here?

You can't have everything your way... because, it happens, sometimes we 
humans are wrong.  We can't help it, it just happens.  Sometimes I'm 
wrong, sometimes you're wrong... that's why we use groups of people to 
decide what is right, because if most people think one thing.... that is 
probably really what's right, and the others are wrong... in that case. 
  But next time it might be the other way around.

-[Unknown]
May 05 2004
parent reply "Chr. Grade" <tickle everymail.net> writes:
Unknown W. Brackets wrote:

 While personally I am happy with the old syntax.... it did always say to 
 me "not C-ish".  I don't know how you can call it "like C/Cpp" when it 
 doesn't even seem consistent with the rest of the language.


Every comparison will mostly result in that kind of conclusion.


 I mean, every single other way, parenthesis without letters before them 
 mean "expression".  If I see (asdfgh), it means to me "the value of the 
 variable asdfgh".... but if I see (asdfgh) 1, I have to realize this 
 means "1 as a asdfgh".


n/c


 Now, truthfully, the new method has a problem in conformity itself, in 
 that cast(asdfgh) 1 still looks a bit odd in that no other C/D code is 
 like that..... but it is worlds better to me than the old method, 
 because it makes it clearer that it's *doing something* and not just a 
 silly expression.
 So, to me, cast(asdfgh) "feels" more like C than even the (asdfgh) I'm
 used to.


1) cast(foo) looks like a function call; like a scripting language
2) Within normal statements, I have never seen a keyword used together 
with paranthesis.


 
 You don't have to agree... but, don't think it's programming at the 
 "mercy" of anyone - unless you are going to tell me that there is not 
 one thing you think is not *PERFECT* about C... otherwise, you were at 
 the "mercy" of its designers as well just as much as you are now at the 
 "mercy" of D's.


Normally, standards are steady and not redefined in a weekly period.


 But.... if you thought C is perfect, why would you be here?


Some enhancements of D (to C) make hacks faster and even more dirty, 
which is good. Although I miss bit fields and define statements, I may 
still code with freedom and close to my old C style. But that seems to 
be in a state of erosion.


 You can't have everything your way... because, it happens, sometimes we 
 humans are wrong.  We can't help it, it just happens.  Sometimes I'm 
 wrong, sometimes you're wrong... that's why we use groups of people to 
 decide what is right, because if most people think one thing.... that is 
 probably really what's right, and the others are wrong... in that case. 
  But next time it might be the other way around.


Condescending, thanks.
May 05 2004
next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
 Now, truthfully, the new method has a problem in conformity itself, in
 that cast(asdfgh) 1 still looks a bit odd in that no other C/D code is
 like that..... but it is worlds better to me than the old method,
 because it makes it clearer that it's *doing something* and not just a
 silly expression.


  > So, to me, cast(asdfgh) "feels" more like C than even the (asdfgh) I'm
  > used to.

 1) cast(foo) looks like a function call; like a scripting language


Good point. As I've said many times in the past, I'd prefer

    cast(type, expr)

On the plus side, however, it's relatively easy to disambiguate a cast from a
function call simply because it uses the keyword cast. This may be used by both
compilers and syntax-highlighting.


 2) Within normal statements, I have never seen a keyword used together
 with paranthesis.



 You don't have to agree... but, don't think it's programming at the
 "mercy" of anyone - unless you are going to tell me that there is not
 one thing you think is not *PERFECT* about C... otherwise, you were at
 the "mercy" of its designers as well just as much as you are now at the
 "mercy" of D's.


 Normally, standards are steady and not redefined in a weekly period.


True. But there isn't a standard yet, is there? We're pre-1.0. So what's your
point?


 You can't have everything your way... because, it happens, sometimes we
 humans are wrong.  We can't help it, it just happens.  Sometimes I'm
 wrong, sometimes you're wrong... that's why we use groups of people to
 decide what is right, because if most people think one thing.... that is
 probably really what's right, and the others are wrong... in that case.
  But next time it might be the other way around.


 Condescending, thanks.


If you open the door ...
May 05 2004
parent reply "Chr. Grade" <tickle everymail.net> writes:
Matthew wrote:

 So, to me, cast(asdfgh) "feels" more like C than even the (asdfgh) I'm
 used to.


1) cast(foo) looks like a function call; like a scripting language


 
 
 As I've said many times in the past, I'd prefer
 
     cast(type, expr)



Why the paranthesis? Why wouldn't a syntax like this be applicable? 
Doesnt it look more like C/Cpp? ->

doob = cast int myVar;
May 05 2004
parent J C Calvarese <jcc7 cox.net> writes:
Chr. Grade wrote:

 
 Matthew wrote:
 

 So, to me, cast(asdfgh) "feels" more like C than even the (asdfgh) I'm
 used to.


 1) cast(foo) looks like a function call; like a scripting language




 As I've said many times in the past, I'd prefer

     cast(type, expr)


 
 
 
 Why the paranthesis? Why wouldn't a syntax like this be applicable? 
 Doesnt it look more like C/Cpp? ->
 
 doob = cast int myVar;


Nostalgia maybe?


I think the parentheses make it more clear what is going on. And the *'s 
could get cluttered.

doob = cast int * myVar;

vs.

doob = cast(int*) myVar;


I prefer the later.

I usually avoid pointers. Hopefully, my example isn't nonsense. :)

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
May 05 2004
prev sibling parent "Unknown W. Brackets" <unknown at.simplemachines.dot.org> writes:
Chr. Grade wrote:


 Unknown W. Brackets wrote:
 
 1) cast(foo) looks like a function call; like a scripting language


So does if(true).  Scary.  But you can always use:

	int i = cast (int) otherVariable;


 2) Within normal statements, I have never seen a keyword used together 
 with paranthesis.


I can take your statement two ways; you either mean that you don't see 
(keyword) except for casting, or you don't see keyword().

The latter is probably not it when you consider if, while, and the like. 
  As far as the former, maybe so.... but, what about casting to a class? 
  That's not a keyword, and it can get confusing like that.


 Normally, standards are steady and not redefined in a weekly period.


Yet that is really what development is, isn't it?  I was under the 
impression that D was under development... and I haven't seen it be 
redefined every week....

But, Mozilla seems not to follow standards by your definition either. 
Their internal functions change, they redefine what css properties 
should do, and how the dom should be handled... not only weekly, but daily.


 

 But.... if you thought C is perfect, why would you be here?


 
 
 Some enhancements of D (to C) make hacks faster and even more dirty, 
 which is good. Although I miss bit fields and define statements, I may 
 still code with freedom and close to my old C style. But that seems to 
 be in a state of erosion.


I'm sorry if you're disenchanted with the changes being made.  I on the 
other hand am happy with them, and would call your "erosion" instead 
development.  I'm sure a happy medium can be achieved, though.


 You can't have everything your way... because, it happens, sometimes 
 we humans are wrong.  We can't help it, it just happens.  Sometimes 
 I'm wrong, sometimes you're wrong... that's why we use groups of 
 people to decide what is right, because if most people think one 
 thing.... that is probably really what's right, and the others are 
 wrong... in that case.  But next time it might be the other way around.


 
 
 Condescending, thanks.


You're welcome.  Maybe you think it's condescending but some people 
don't want to realize that it is indeed the case.... even if they say, 
"of course - you're patronizing me, we all know that."

I live in California... I see this kind of thing every day.

Please, don't be so quick to call me on being "condescending" and 
actually just read it and take it at face value.

-[Unknown]
May 05 2004
prev sibling next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Chr. Grade wrote:


 
 Either D feels like C/Cpp or it doesn't. 


I certainly hope it don't.

Lars Ivar Igesund
May 05 2004
prev sibling next sibling parent Andy Friesen <andy ikagames.com> writes:
Chr. Grade wrote:

 
 Either D feels like C/Cpp or it doesn't.


Ethereal concepts like 'feeling' are rarely absolute. :)


 Such thing obscures the 
 relation to C/Cpp and puts up an obstacle for frist timers.
 C style casts will be cut out first. And what's next? How many times 
 will I have to partially rewrite my code. Over and over? Every time a 
 new compiler version is released?
 Programming at Walter's and the D-community's mercy. So, that's the 
 downside of D?


That's the downside of using a beta compiler for a beta language.  The 
upside, of course, is the chance to change the language for the better.


 And where's the C hardcore faction?


Using C, probably. :)

  -- andy
May 05 2004
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"Chr. Grade" <tickle everymail.net> wrote in message
news:c7bfsq$22rp$1 digitaldaemon.com...

 Either D feels like C/Cpp or it doesn't. Such thing obscures the
 relation to C/Cpp and puts up an obstacle for frist timers.
 C style casts will be cut out first. And what's next? How many times
 will I have to partially rewrite my code. Over and over? Every time a
 new compiler version is released?


I hear you, which is why I put this question here. Also, there are maybe a
hundred or so casts in the phobos source that needs fixing, so I have to
modify my own code, too. On the other hand, it's a trivial change, I can do
a hundred fixes in a few minutes. Just past 'cast' in before the
parentheses.


 Programming at Walter's and the D-community's mercy. So, that's the
 downside of D?

 And where's the C hardcore faction?


I should also point out that the C++ community has also declared C casts as
obsolete (though still in the language) and replaced with static_cast and
related.
May 05 2004
prev sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
C-style cast is informally deprecated even in C++, where you should use 
template-like casts static_cast, dynamic_cast and reinterpret_cast, to 
which D cast is similar enough.

Having said that, D has a few other points where C programmers may 
stumble, and many many points left from C where non-C programmers will. 
This cannot be changed. And the differences from C are largely of 
semantical and not syntactical nature, and may cause some headache at 
first but prove very advantageous later on.

Having also seen that some otherwise legal expressions get rejected 
because they "look like" a C-style cast, but in fact aren't, makes me 
vote to remove C-style casts.

Now, it's already happened. And is one more word "cast" that much of a 
problem?

-eye

Chr. Grade schrieb:

 
 The closer D will remain related to C and Cpp, the more likely people 
 are willing to have a closer look at D and programm with it and switch 
 to it. D has to be intuitive for D-newbies. I merely tried D because it 
 looked and felt so familiar.
 I'd be more than disencouraged if C/Cpp style casts were missing, 
 because I'm simply used to them; I like them.
May 16 2004
prev sibling next sibling parent James McComb <alan jamesmccomb.id.au> writes:
Walter wrote:


 What do people think about first deprecating, then removing, the C style
 cast?


+1

D-style casts: great. C-style casts: lame.
May 05 2004
prev sibling next sibling parent "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:c7b6vn$1o0h$1 digitaldaemon.com...

 What do people think about first deprecating, then removing, the C style
 cast?


+1
May 05 2004
prev sibling next sibling parent Mark T <Mark_member pathlink.com> writes:
What do people think about first deprecating, then removing, the C style
cast?


let it go,  I had to get used to the new C++ casts, so D casts should be no
problem
May 05 2004
prev sibling next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
Do it! No question.

"Walter" <newshound digitalmars.com> wrote in message
news:c7b6vn$1o0h$1 digitaldaemon.com...

 Currently, D supports C style casts:

     (type)expression

 as well as D style casts:

     cast(type)expression

 The C style casts are tricky to parse right, and I think will cause
 increasing problems down the road due to the syntactical ambiguities with
 it. The D style cast has no such problems, and it has the advantage of being
 greppable (as some programming styles consider an explicit cast to be a bug,
 and being able to find and check them all to be a Good Thing).

 What do people think about first deprecating, then removing, the C style
 cast?
May 05 2004
prev sibling next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:c7b6vn$1o0h$1 digitaldaemon.com...

 Currently, D supports C style casts:

     (type)expression

 as well as D style casts:

     cast(type)expression


I should also confess that I'm looking into implementing things like:

    a = (int == T) ? c : d;    // is T an alias for type int?

which will cause even more parser grief disambiguating them from C style
casts. Essentially, I'm looking at the possibility of a type being an
expression. The utility of it is to be able to write simpler and more
straightforward generic code, without resorting to forests of inscrutable
template specializations.
May 05 2004
next sibling parent reply Andy Friesen <andy ikagames.com> writes:
Walter wrote:

 I should also confess that I'm looking into implementing things like:
 
     a = (int == T) ? c : d;    // is T an alias for type int?
 
 which will cause even more parser grief disambiguating them from C style
 casts. Essentially, I'm looking at the possibility of a type being an
 expression. The utility of it is to be able to write simpler and more
 straightforward generic code, without resorting to forests of inscrutable
 template specializations.


My head is spinning:

    static assert(X inherits Y);
    if (X has method void foo(int y, float z)) { ... } else { ... }

  -- andy
May 05 2004
parent "Walter" <newshound digitalmars.com> writes:
"Andy Friesen" <andy ikagames.com> wrote in message
news:c7brvh$2pdu$1 digitaldaemon.com...

 Walter wrote:

 I should also confess that I'm looking into implementing things like:

     a = (int == T) ? c : d;    // is T an alias for type int?

 which will cause even more parser grief disambiguating them from C style
 casts. Essentially, I'm looking at the possibility of a type being an
 expression. The utility of it is to be able to write simpler and more
 straightforward generic code, without resorting to forests of




inscrutable

 template specializations.


 My head is spinning:

     static assert(X inherits Y);


I was thinking that could be done with:
    static assert(cast(Y)X);


     if (X has method void foo(int y, float z)) { ... } else { ... }


That's a lot further down that road <g>.
May 05 2004
prev sibling next sibling parent =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
Walter wrote:

 I should also confess that I'm looking into implementing things like:
 
     a = (int == T) ? c : d;    // is T an alias for type int?
 
 which will cause even more parser grief disambiguating them from C style
 casts. Essentially, I'm looking at the possibility of a type being an
 expression. The utility of it is to be able to write simpler and more
 straightforward generic code, without resorting to forests of inscrutable
 template specializations.


So does that means we could store a type in a variable! That's the 
solution to the var_args problem.

-- 
Julio César Carrascal Urquijo
http://jcesar.f2o.org/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS$ d- s+:+ a-- C++> ULS++ P++ L+> !E W+++ N+ o? K? w++>
O---  M V? PS+ PE Y+ PGP t+ 5- X+++  R- tv+(++) b++> DI!
D++> G e+> h-- r- y+
------END GEEK CODE BLOCK------
May 06 2004
prev sibling next sibling parent "C. Sauls" <ibisbasenji yahoo.com> writes:
Walter wrote:

 I should also confess that I'm looking into implementing things like:
 
     a = (int == T) ? c : d;    // is T an alias for type int?
 
 which will cause even more parser grief disambiguating them from C style
 casts. Essentially, I'm looking at the possibility of a type being an
 expression. The utility of it is to be able to write simpler and more
 straightforward generic code, without resorting to forests of inscrutable
 template specializations.


Hey... I remember talking about something along these lines some time 
ago.  Hope to see it happen.  This combined with the 'variant' type 
proposed elsewhere on the NG would make for one fine system, methinks.

-C. Sauls
-Invironz
May 06 2004
prev sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Walter wrote:
  > I should also confess that I'm looking into implementing things like:

 
     a = (int == T) ? c : d;    // is T an alias for type int?
 
 which will cause even more parser grief disambiguating them from C style
 casts. Essentially, I'm looking at the possibility of a type being an
 expression. The utility of it is to be able to write simpler and more
 straightforward generic code, without resorting to forests of inscrutable
 template specializations.


I like this! But why not use the same method to avoid the ambiguity as 
for cast?

a= (type(int) == type(T)) ? c : d;

or (maybe better)

a= int.type == T.type ? c : d;

or perhaps

a= T.typeEquals(int) ? c : d;

or something like that?


Hauke
May 09 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:c7l3qr$1i5n$1 digitaldaemon.com...

 Walter wrote:
   > I should also confess that I'm looking into implementing things like:

     a = (int == T) ? c : d;    // is T an alias for type int?

 which will cause even more parser grief disambiguating them from C style
 casts. Essentially, I'm looking at the possibility of a type being an
 expression. The utility of it is to be able to write simpler and more
 straightforward generic code, without resorting to forests of




inscrutable

 template specializations.


 I like this! But why not use the same method to avoid the ambiguity as
 for cast?

 a= (type(int) == type(T)) ? c : d;


Something like that will have to be done. For example, is:

    foo*fp[]

an expression or a type? It's ambiguous. There'll have to be something like
what you propose. Probably 'typename' instead of 'type', as 'type' appears
too often as a variable name.


 or (maybe better)
 a= int.type == T.type ? c : d;


Parsing ambiguity problems.


 or perhaps
 a= T.typeEquals(int) ? c : d;

 or something like that?


I think typename(int) will parse easilly and so will work best.
May 11 2004
parent reply "C. Sauls" <ibisbasenji yahoo.com> writes:
Could this fall into the domain of typeof() perhaps?  That's already in 
the language, and likely to be a common companion to whatever becomes 
this.  Or at least that's what I see.

a = typeof(int) == typeof(T) ? c : d;

-C. Sauls
-Invironz

Walter wrote:

 "Hauke Duden" <H.NS.Duden gmx.net> wrote in message
 news:c7l3qr$1i5n$1 digitaldaemon.com...
 

Walter wrote:
  > I should also confess that I'm looking into implementing things like:


    a = (int == T) ? c : d;    // is T an alias for type int?

which will cause even more parser grief disambiguating them from C style
casts. Essentially, I'm looking at the possibility of a type being an
expression. The utility of it is to be able to write simpler and more
straightforward generic code, without resorting to forests of




 
 inscrutable
 

template specializations.


I like this! But why not use the same method to avoid the ambiguity as
for cast?

a= (type(int) == type(T)) ? c : d;


 
 
 Something like that will have to be done. For example, is:
 
     foo*fp[]
 
 an expression or a type? It's ambiguous. There'll have to be something like
 what you propose. Probably 'typename' instead of 'type', as 'type' appears
 too often as a variable name.
 
 

or (maybe better)
a= int.type == T.type ? c : d;


 
 
 Parsing ambiguity problems.
 
 

or perhaps
a= T.typeEquals(int) ? c : d;

or something like that?


 
 
 I think typename(int) will parse easilly and so will work best.
May 11 2004
parent "Walter" <newshound digitalmars.com> writes:
Won't work as an argument to typeof, because
    typeof(foo[])
is ambiguous.
May 17 2004
prev sibling next sibling parent J C Calvarese <jcc7 cox.net> writes:
Walter wrote:

 Currently, D supports C style casts:
 
     (type)expression
 
 as well as D style casts:
 
     cast(type)expression
 
 The C style casts are tricky to parse right, and I think will cause
 increasing problems down the road due to the syntactical ambiguities with
 it. The D style cast has no such problems, and it has the advantage of being
 greppable (as some programming styles consider an explicit cast to be a bug,
 and being able to find and check them all to be a Good Thing).
 
 What do people think about first deprecating, then removing, the C style
 cast?


I'm definitely in favor of this. Let's get rid of those C-style casts.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
May 05 2004
prev sibling next sibling parent Patrick Down <Patrick_member pathlink.com> writes:
+1

In article <c7b6vn$1o0h$1 digitaldaemon.com>, Walter says...

Currently, D supports C style casts:

    (type)expression

as well as D style casts:

    cast(type)expression

The C style casts are tricky to parse right, and I think will cause
increasing problems down the road due to the syntactical ambiguities with
it. The D style cast has no such problems, and it has the advantage of being
greppable (as some programming styles consider an explicit cast to be a bug,
and being able to find and check them all to be a Good Thing).

What do people think about first deprecating, then removing, the C style
cast?
May 05 2004
prev sibling next sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:

 Currently, D supports C style casts:
 
     (type)expression
 
 as well as D style casts:
 
     cast(type)expression
 
 The C style casts are tricky to parse right, and I think will cause
 increasing problems down the road due to the syntactical ambiguities with
 it. The D style cast has no such problems, and it has the advantage of being
 greppable (as some programming styles consider an explicit cast to be a bug,
 and being able to find and check them all to be a Good Thing).
 
 What do people think about first deprecating, then removing, the C style
 cast?


Good idea except for the deprecating part.  C-style casts have been 
informally deprecated for months.  Just remove them now.  Certainly, at 
the very least, remove them before 1.0.

Russ
May 05 2004
parent David L. "SpottedTiger" Davis <David_member pathlink.com> writes:
In article <c7bqka$2mge$1 digitaldaemon.com>, Russ Lewis says...

Walter wrote:

 Currently, D supports C style casts:
 
     (type)expression
 
 as well as D style casts:
 
     cast(type)expression
 
 The C style casts are tricky to parse right, and I think will cause
 increasing problems down the road due to the syntactical ambiguities with
 it. The D style cast has no such problems, and it has the advantage of being
 greppable (as some programming styles consider an explicit cast to be a bug,
 and being able to find and check them all to be a Good Thing).
 
 What do people think about first deprecating, then removing, the C style
 cast?


Good idea except for the deprecating part.  C-style casts have been 
informally deprecated for months.  Just remove them now.  Certainly, at 
the very least, remove them before 1.0.

Russ


[Warning: 1st post]
I agree with Russ and the others who wish to see the C-Style casts removed.
Otherwise there's going to be a ton of code written that'll have a mixed casting
style, which IMHO will only make the code written harder to read and to
maintained. It's really better to have just the one way (the D-way), and "keep
it simple."

(Note: I've been following this forum for nearly 6 months, and I really like the
way everyone here works so well together to build a better C/C++ like Langauge.
I think "D" is going to be a much better programming Langauge because of it!)
May 06 2004
prev sibling next sibling parent "chris" <news flak.clara.co.uk> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:c7b6vn$1o0h$1 digitaldaemon.com...

 Currently, D supports C style casts:

     (type)expression

 as well as D style casts:

     cast(type)expression


i would prefer somthing like...

(cast type expresson)
(expresion as type)

at least then the expresion and the type are more clearly bracketed together and
much easier on the eye imo.

chris
May 05 2004
prev sibling next sibling parent "Scott Egan" <scotte tpg.com.aux> writes:
I'll never be able to program again.  But then the doco already made me
think I had to use cast().

Fire away.


"Walter" <newshound digitalmars.com> wrote in message
news:c7b6vn$1o0h$1 digitaldaemon.com...

 Currently, D supports C style casts:

     (type)expression

 as well as D style casts:

     cast(type)expression

 The C style casts are tricky to parse right, and I think will cause
 increasing problems down the road due to the syntactical ambiguities with
 it. The D style cast has no such problems, and it has the advantage of


being

 greppable (as some programming styles consider an explicit cast to be a


bug,

 and being able to find and check them all to be a Good Thing).

 What do people think about first deprecating, then removing, the C style
 cast?
May 06 2004
prev sibling next sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
Walter wrote:


What do people think about first deprecating, then removing, the C style
cast?


I guess people should start updating there documentation now if they are 
using any old casts.  Do you know any wiki pages that use C casts?

-- 
-Anderson: http://badmama.com.au/~anderson/
May 06 2004
prev sibling next sibling parent Mike Wynn <one_mad_alien hotmail.com> writes:
On Wed, 5 May 2004 10:04:08 -0700, "Walter"
<newshound digitalmars.com> wrote:


Currently, D supports C style casts:

    (type)expression

as well as D style casts:

    cast(type)expression

The C style casts are tricky to parse right, and I think will cause
increasing problems down the road due to the syntactical ambiguities with
it. The D style cast has no such problems, and it has the advantage of being
greppable (as some programming styles consider an explicit cast to be a bug,
and being able to find and check them all to be a Good Thing).

What do people think about first deprecating, then removing, the C style
cast?


do it ... and finally resolve that persistant BUG

int main( char[][] args ) {
	int a;
	int b
	a = args.length;
	b = (a);

	return 0;
}
//casttest.d(7): semicolon expected, not 'a'
May 06 2004
prev sibling parent reply Brad Anderson <brad sankaty.dot.com> writes:
In DMD 0.89, the following:

     int so = (schar*)slice - (schar*)string;

The compiler suggests:

    "C style cast deprecated, use cast(*schar)(slice)"

That doesn't work, but the following does:

     int so = cast(schar*)slice - cast(schar*)string;

Any danger in ignoring the compiler here?  Should the compiler give a better 
message?

BTW, this is Vathix's string.d

BA
May 17 2004
parent "Walter" <newshound digitalmars.com> writes:
"Brad Anderson" <brad sankaty.dot.com> wrote in message
news:c8bsf6$1rvi$1 digitaldaemon.com...

 In DMD 0.89, the following:

      int so = (schar*)slice - (schar*)string;

 The compiler suggests:

     "C style cast deprecated, use cast(*schar)(slice)"

 That doesn't work, but the following does:

      int so = cast(schar*)slice - cast(schar*)string;

 Any danger in ignoring the compiler here?  Should the compiler give a


better

 message?


No. Yes. <g>
May 24 2004