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.

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

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

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

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

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

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/

+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?
>
>

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

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