May 05, 2004
"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
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
"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
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 06, 2004
"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 06, 2004
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 06, 2004
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 06, 2004
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
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
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!)