www.digitalmars.com         C & C++   DMDScript  

D - [VOTE:] Should the cast operator be mandatory?

reply "Matthew" <matthew stlsoft.org> writes:
Matthew: Yes
Mar 17 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Matthew wrote:


Matthew: Yes


Cast on everything be mandatory?  Details, sorry I missed the discussion 
on this.

-- 
-Anderson: http://badmama.com.au/~anderson/
Mar 17 2004
parent reply "Matthew" <matthew stlsoft.org> writes:
"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:c39hva$1m1u$1 digitaldaemon.com...

 Matthew wrote:


Matthew: Yes


 Cast on everything be mandatory?


Anytime a cast is used, it should be via the cast operator, rather than a
C-style cast.

It doesn't mean that all implicit conversions should be given a cast. That's
another debate entirely.


  Details, sorry I missed the discussion
 on this.


Haven't time to summarise, but there're lots of recent posts.
Mar 17 2004
next sibling parent reply "Ben Hinkle" <bhinkle4 juno.com> writes:
I tried scanning the subject lines for cast and could only find the one
about
implicit narrow casting.
Is there a subject line for the thread about C-style casts?

If the primary reason to remove C-style casts is to make parsing
easier then I'd say go for it because parsing code is a big part of
writing quality tools and editors.

For users the mental jump from (foo)bar to cast(foo)bar is pretty
easy compared to other semantics changes D has from C (hint,
arrays).

-Ben

"Matthew" <matthew stlsoft.org> wrote in message
news:c39k1e$1pnp$1 digitaldaemon.com...

 "J Anderson" <REMOVEanderson badmama.com.au> wrote in message
 news:c39hva$1m1u$1 digitaldaemon.com...

 Matthew wrote:


Matthew: Yes


 Cast on everything be mandatory?


 Anytime a cast is used, it should be via the cast operator, rather than a
 C-style cast.

 It doesn't mean that all implicit conversions should be given a cast.


That's

 another debate entirely.


  Details, sorry I missed the discussion
 on this.


 Haven't time to summarise, but there're lots of recent posts.
Mar 17 2004
parent J C Calvarese <jcc7 cox.net> writes:
In article <c3abvi$527$1 digitaldaemon.com>, Ben Hinkle says...

I tried scanning the subject lines for cast and could only find the one
about
implicit narrow casting.
Is there a subject line for the thread about C-style casts?


It's another case of thread drift. I can't blame anyone else because I'm part of
the problem. ;)

Subject: Re: [BUG] dmd does not implement LR analysis
URL:     http://www.digitalmars.com/drn-bin/wwwnews?D/25705



If the primary reason to remove C-style casts is to make parsing
easier then I'd say go for it because parsing code is a big part of
writing quality tools and editors.

For users the mental jump from (foo)bar to cast(foo)bar is pretty
easy compared to other semantics changes D has from C (hint,
arrays).

-Ben

"Matthew" <matthew stlsoft.org> wrote in message
news:c39k1e$1pnp$1 digitaldaemon.com...

 "J Anderson" <REMOVEanderson badmama.com.au> wrote in message
 news:c39hva$1m1u$1 digitaldaemon.com...

 Matthew wrote:


Matthew: Yes


 Cast on everything be mandatory?


 Anytime a cast is used, it should be via the cast operator, rather than a
 C-style cast.

 It doesn't mean that all implicit conversions should be given a cast.


That's

 another debate entirely.


  Details, sorry I missed the discussion
 on this.


 Haven't time to summarise, but there're lots of recent posts.




Justin
http://jcc_7.tripod.com/d/
Mar 17 2004
prev sibling parent larry cowan <larry_member pathlink.com> writes:
As I understand it, the vote is whether, having the "cast" keyword, it should
be required rather than optional for all explicit casts.  Sorry, I thought it
was required, at least in some cases.  My vote is YES, always (or forget the
word as a keyword entirely).  I prefer D's form to C's form - it points out more
obviously where something is being type-changed from your expectation, and can
be searched for more easily. 

In article <c39k1e$1pnp$1 digitaldaemon.com>, Matthew says...

"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:c39hva$1m1u$1 digitaldaemon.com...

 Matthew wrote:


Matthew: Yes


 Cast on everything be mandatory?


Anytime a cast is used, it should be via the cast operator, rather than a
C-style cast.

It doesn't mean that all implicit conversions should be given a cast. That's
another debate entirely.


  Details, sorry I missed the discussion
 on this.


Haven't time to summarise, but there're lots of recent posts.
Mar 17 2004
prev sibling next sibling parent reply Andy Friesen <andy ikagames.com> writes:
Matthew wrote:

 Matthew: Yes


cast(X)x good
(X)x not.

Yes.

  -- andy
Mar 17 2004
parent reply Juan C <Juan_member pathlink.com> writes:
Well, yes, but -- "Oh no! It'll make porting from C more difficult!"
It seems to me that this is another case where Walter would prefer to leave in a
flaw from C -- rather than making D the best language it can be.

In article <c39n7m$1uqk$1 digitaldaemon.com>, Andy Friesen says...

Matthew wrote:

 Matthew: Yes


cast(X)x good
(X)x not.

Yes.

  -- andy
Mar 17 2004
next sibling parent "Matthew" <matthew stlsoft.org> writes:
"Juan C" <Juan_member pathlink.com> wrote in message
news:c39vkk$2fof$1 digitaldaemon.com...

 Well, yes, but -- "Oh no! It'll make porting from C more difficult!"


In this case that "more difficult" is a good thing!


 It seems to me that this is another case where Walter would prefer to


leave in a

 flaw from C -- rather than making D the best language it can be.

 In article <c39n7m$1uqk$1 digitaldaemon.com>, Andy Friesen says...

Matthew wrote:

 Matthew: Yes


cast(X)x good
(X)x not.

Yes.

  -- andy
Mar 17 2004
prev sibling parent reply Vathix <vathix dprogramming.com> writes:
Juan C wrote:

 Well, yes, but -- "Oh no! It'll make porting from C more difficult!"
 It seems to me that this is another case where Walter would prefer to leave in
a
 flaw from C -- rather than making D the best language it can be.
 


How about making it a deprecated feature, so you have to pass -d to the 
command line for it to compile?

-- 
Christopher E. Miller
Mar 17 2004
parent reply "Matthew" <matthew stlsoft.org> writes:
I could live with that, but I reckon it'll just smell like a warning by
another name to big-W

"Vathix" <vathix dprogramming.com> wrote in message
news:c3a43k$2ocm$1 digitaldaemon.com...

 Juan C wrote:

 Well, yes, but -- "Oh no! It'll make porting from C more difficult!"
 It seems to me that this is another case where Walter would prefer to




leave in a

 flaw from C -- rather than making D the best language it can be.


 How about making it a deprecated feature, so you have to pass -d to the
 command line for it to compile?

 -- 
 Christopher E. Miller
Mar 17 2004
parent =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
Matthew wrote:


 I could live with that, but I reckon it'll just smell like a warning by
 another name to big-W


Except, of course, unlike C compilers where you have to explicitly tell 
it to enforce stricter behaviour through -ansi, -warnings-as-errors (or 
suchnot), in this case the code would *not* compile unless you 
explicitly told it to ignore something.

Not that I support the idea of deprecating it. There's no reason to 
leave twaddle with a language to make it easier to do bad things 
conveniently, when part of the point of the language has been to *break* 
compatability to correct flaws, where C++ did not.

Cheers,
Sigbjørn Lund Olsen
Mar 19 2004
prev sibling next sibling parent "C. Sauls" <ibisbasenji yahoo.com> writes:
Chris S. -- Yes!

Matthew wrote:

 Matthew: Yes
Mar 17 2004
prev sibling next sibling parent Andrew Edwards <remove_ridimz remove_yahoo.com> writes:
On Wed, 17 Mar 2004 12:18:00 -0000, Matthew <matthew stlsoft.org> wrote:


 Matthew: Yes


Andrew: Yes!
Vathix's deprecated (-d) suggestion may warrant a second look! However, I 
don't think it necessary.
Mar 17 2004
prev sibling next sibling parent "Carlos Santander B." <carlos8294 msn.com> writes:
Sí, yes, oui. Sorry, can't remember more of those :D.

-----------------------
Carlos Santander Bernal
Mar 17 2004
prev sibling next sibling parent J C Calvarese <jcc7 cox.net> writes:
Matthew wrote:

 Matthew: Yes
 


Yes. C-style casts hurt my eyes.

-- 
Justin
http://jcc_7.tripod.com/d/
Mar 17 2004
prev sibling next sibling parent C <dont respond.com> writes:
Yes

On Wed, 17 Mar 2004 12:18:00 -0000, Matthew <matthew stlsoft.org> wrote:=



 Matthew: Yes
Mar 17 2004
prev sibling next sibling parent "Derek Parnell" <Derek.Parnell psyc.ward> writes:
My vote: Yes

Reasons:
(a) An explicit keyword makes the coder's intentions more obvious to the  
reader.
(b) An explicit keyword makes the code more 'grepable'.
(c) Makes Walter's job easier (less parsing bugs etc...)


-- 
Derek
Mar 17 2004
prev sibling next sibling parent "Phill" <phill pacific.net.au> writes:
Yep (so im aware of what im actually doing)

Phill.

"Matthew" <matthew stlsoft.org> wrote in message
news:c39fo1$1iq4$3 digitaldaemon.com...

 Matthew: Yes
Mar 18 2004
prev sibling next sibling parent =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
Matthew wrote:


 Matthew: Yes
 
 


Yes.

Cheers,
Sigbjørn Lund Olsen
Mar 19 2004
prev sibling next sibling parent "Kris" <someidiot earthlink.net> writes:
Another "yes"


"Matthew" <matthew stlsoft.org> wrote in message
news:c39fo1$1iq4$3 digitaldaemon.com...

 Matthew: Yes
Mar 19 2004
prev sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
The cast operator is broken; it should be "cast (a, b)", so no.  Having 
a non-broken alternative that at least has the benefit of being historic 
is better than one which makes code look like crap.
Mar 22 2004
next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <c3oo6k$2v44$1 digitaldaemon.com>, Burton Radons says...

The cast operator is broken; it should be "cast (a, b)", so no.  Having 
a non-broken alternative that at least has the benefit of being historic 
is better than one which makes code look like crap.


We discussed alternative cast sintax, the one that looks better is
a.castTo(B)
however seems to have been rejected by Walter.
(were you here at that time?)

the problem with cast(a,b) is that it's not explicit whit is
the type.

Ant
Mar 23 2004
parent Burton Radons <loth users.sourceforge.net> writes:
Ant wrote:

 In article <c3oo6k$2v44$1 digitaldaemon.com>, Burton Radons says...
 

The cast operator is broken; it should be "cast (a, b)", so no.  Having 
a non-broken alternative that at least has the benefit of being historic 
is better than one which makes code look like crap.


 
 
 We discussed alternative cast sintax, the one that looks better is
 a.castTo(B)
 however seems to have been rejected by Walter.
 (were you here at that time?)


I wasn't.  But I don't like fake methods and properties; they get into a 
lot of unintentional conflicts and method conflicts are much messier 
than function conflicts.


 the problem with cast(a,b) is that it's not explicit whit is
 the type.


Eh?  You don't have any functions or methods that take more than one 
argument?  Just have an explicit error in the compiler; a couple doses 
of that and one shouldn't make the mistake ever again.
Mar 23 2004
prev sibling parent Andy Friesen <andy ikagames.com> writes:
Burton Radons wrote:

 The cast operator is broken; it should be "cast (a, b)", so no.  Having 
 a non-broken alternative that at least has the benefit of being historic 
 is better than one which makes code look like crap.


I like it.  It looks like a cast and not a function call.  It's also 
easy for a compiler to parse and for a programmer to recognize.

  -- andy
Mar 23 2004