"Vathix" <vathix@dprogramming.com> wrote in message news:opsjowgqowkcck4r@tc3-ppp187.dialup.wzrd.com...
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/740 and the
> replies, posted back in July. I know I've found a few more cases since
> then but didn't bother posting them, one being switch(f.prop).
> - Chris

I'll take care of them. Thanks, -Walter

Jarrett Billingsley wrote:
<snip>
> Class properties feel like a weird compiler hack.  There is no official "property" keyword or anything like that.  In fact, the following, although confusing, is legal:
<snip>
> Something() is not a property, though I can call it with the property syntax.

Indeed.  Guess there are possible excuses like saving typing, saving a keyword or opening up IODCC potential.  Of course, there may well be some more 'real' motives/advantages.

The price is that documentation generators can't automatically give properties special treatment.  But putting properties into a member group for Doxygen seems to work OK for my purposes.

> The "classes are references even though the syntax looks like they're local" (A a=new A) makes some template definitions painful and redundant.

Would you care to give an example?

> I think it'd be easier to bring back class pointers (A* a=new A) and simply flag any attempt to create class instances on the stack as an error.

This would invite people to go back to treating classes as value types, bringing back some of the weaknesses we were trying to avoid.

> Casting is, frankly, a pain.  Not only do we now have the ugly cast(type)expr operator, but we cannot create more than one opCast per class (understandable)

For some values of "understandable", yes.  I still don't see that it had to be designed in such a way that you could have only one, rather than something like

    void opCast(out int qwert)

or some special function syntax as C++ kind-of has.  Or maybe even making opCast the one function name that can be return-type overloaded (IWC calling opCast by name would probably become illegal).

> and there is no such thing as opAssign (NOT understandable). 

http://www.digitalmars.com/d/faq.html#assignmentoverloading

> We are then stuck making all these stupid "toSomething()" member functions, which can potentially cause frustration (imagine if you have int x; x=a.toInt();  then you change x's type to float.  it'll then cast to int and then to float, rather than automatically selecting a's toFloat() operator (if it has one)).  If there's one thing I love about C++, it's its ability to hide all that nasty casting crap.  The only problem with C++ is that sometimes it's a little obscure as to what goes through what function when implicitly casting.  But 99% of the time it's a very simple, obvious cast anyway, so I don't see what's wrong with implicit casting.
<snip>

Basically that it can get tricky, both to follow and to implement, and be an easy source of bugs.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on on the 'group where everyone may benefit.

> Indeed.  Guess there are possible excuses like saving typing, saving a keyword or opening up IODCC potential.  Of course, there may well be some more 'real' motives/advantages.

Just wondering - what is "IODCC?"  I googled it and all I got were a bunch of confusing CVS repositories and a page about someone using java to control his train set.

> Would you care to give an example?

I think it has something to do with == vs. is.  Making one template that uses the == operator would cause problems when used with classes.  I may be wrong, but Walter agrees with me, and I seem to remember someone coming across this problem in DTL or something, so..

Jarrett Billingsley schrieb:
> Just wondering - what is "IODCC?"  I googled it and all I got were a bunch
> of confusing CVS repositories and a page about someone using java to control
> his train set.

Search for IOCCC, you'll understand :)

> Search for IOCCC, you'll understand :)

Oh, dear lord.. that's one of the funnier things I've seen in a long time :) An operating system and an 11-bit ALU made entirely in the preprocessor? Man, these people have a lot of time on their hands.