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?

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

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?

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?

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?

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

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

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

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

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

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.

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]

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.

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.

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]

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.

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.

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.

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?

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

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

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

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.

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:

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.

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?

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?

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

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!)

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?

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?

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

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