View mode: basic / threaded / horizontal-split · Log in · Help
May 05, 2004
Re: Deprecating C style casts
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
Re: Deprecating C style casts
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
Re: Deprecating C style casts
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
Re: Deprecating C style casts
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
Re: Deprecating C style casts
"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
Re: Deprecating C style casts
"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
Re: Deprecating C style casts
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
Re: Deprecating C style casts
+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
Re: Deprecating C style casts
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
Re: Deprecating C style casts
> > 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 ...
1 2 3 4 5
Top | Discussion index | About this forum | D home