In article <cgar00$126b$1@digitaldaemon.com>, Andy Friesen says...

>The real problem is that opEquals and opCmp are defined for Object, which means that any object must be comparable to any other:

I figured out a way to make == (etc) into a compile error. Here's an example:

#    class A
#    {
#        void opEquals() {}   // sneaky, huh?
#    }
#
#    void main()
#    {
#        A a = new A();
#        A b = new A();
#
#        if (a == b)    // Line 11 - now a compile error!
#        {
#            printf("hello world\n");
#        }
#    }

This is what you get when you try to compile it:

eq.d(11): function opEquals () does not match argument types (A )
eq.d(11): Error: expected 0 arguments, not 1
eq.d(11): void does not have a boolean value

Well, at least the file and line number are right! :)

It works because of Walter's now famous rule that name resolution happens before signature matching. The zero-argument version of opEquals() will be found first, so the rule says it will be used, and the version in Object won't! But that function has the wrong argument list, so now D can't find a match at all. Voila - one compile-time error. And you can do the same thing for opCmp() too.

Arcane Jill

Nice one! That's rather amusing, Jill <G>


"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cgat6b$1424$1@digitaldaemon.com...
> In article <cgar00$126b$1@digitaldaemon.com>, Andy Friesen says...
>
> >The real problem is that opEquals and opCmp are defined for Object, which means that any object must be comparable to any other:
>
> I figured out a way to make == (etc) into a compile error. Here's an
example:
>
> #    class A
> #    {
> #        void opEquals() {}   // sneaky, huh?
> #    }
> #
> #    void main()
> #    {
> #        A a = new A();
> #        A b = new A();
> #
> #        if (a == b)    // Line 11 - now a compile error!
> #        {
> #            printf("hello world\n");
> #        }
> #    }
>
> This is what you get when you try to compile it:
>
> eq.d(11): function opEquals () does not match argument types (A )
> eq.d(11): Error: expected 0 arguments, not 1
> eq.d(11): void does not have a boolean value
>
> Well, at least the file and line number are right! :)
>
> It works because of Walter's now famous rule that name resolution happens
before
> signature matching. The zero-argument version of opEquals() will be found
first,
> so the rule says it will be used, and the version in Object won't! But
that
> function has the wrong argument list, so now D can't find a match at all.
Voila
> - one compile-time error. And you can do the same thing for opCmp() too.
>
> Arcane Jill
>
>

Arcane Jill wrote:
> In article <cgar00$126b$1@digitaldaemon.com>, Andy Friesen says...
> 
> 
>>The real problem is that opEquals and opCmp are defined for Object, which means that any object must be comparable to any other:
> 
> 
> I figured out a way to make == (etc) into a compile error. Here's an example:
> 
> #    class A
> #    {
> #        void opEquals() {}   // sneaky, huh?
> #    }
> #    #    void main()
> #    {
> #        A a = new A();
> #        A b = new A();
> #    #        if (a == b)    // Line 11 - now a compile error!
> #        {
> #            printf("hello world\n");
> #        }
> #    }
> 
> This is what you get when you try to compile it:
> 
> eq.d(11): function opEquals () does not match argument types (A )
> eq.d(11): Error: expected 0 arguments, not 1
> eq.d(11): void does not have a boolean value
> 
> Well, at least the file and line number are right! :)
> 
> It works because of Walter's now famous rule that name resolution happens before
> signature matching. The zero-argument version of opEquals() will be found first,
> so the rule says it will be used, and the version in Object won't! But that
> function has the wrong argument list, so now D can't find a match at all. Voila
> - one compile-time error. And you can do the same thing for opCmp() too.

Awesome!

How about this one? :)

    class Rational {
        int numerator, denominator;
        int opCmp(Rational rhs) { ... }
    }

    Rational[] r = ...;
    r.sort; // sorts by hash code!

 -- andy

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:cgamjk$uvl$1@digitaldaemon.com...
> Ivan Senji wrote:
> <snip>
> > There isn't really much more i could say about this. Why does == have to work as === by default?   I have never writen a code were two objects are equal when they are in the same place in memory (===),
>
> To save the user having to write code like
>
>      int opEquals(Object o) {
>          return this === o;
>      }
>
> everywhere when they _do_ write code like that.

That's no argument. One might also say that *every* single object

Such things are convention - and a bad one in this case - rather than any kind of software engineering axiom.

> For example, suppose you have an auto class representing a lock on some resource.  How would you define two of them being equal?  Them locking the same resource?  If the setup is such that each resource can only be locked once, then the lock object is equal only to itself.

This is nonsense. Why should lock objects be value-comparable in any way? I can think of no reason why one would ever need to so do. Indeed of all such things I've been writing and using over the last 10+ years in C++, I've never had cause to do such a thing.

C++ misstepped badly in allowing copying (initialisation and assignment) by default for classes, where it should have only preserved that for structs. But it wisely does not provide any default value comparison for class types. We know why D has done such a thing - built-in AAs, and array.sort - but it's a serious mistake, and is a blight on the language. If a given semantic makes sense for only a subset of all types, why provide it for all? That's MFC!

> Suppose you have a GUI library.  Two GUI control objects could be considered equal if they interface the same control.  But if the library can only create controls, and not interface existing controls (such as those on a Windows dialog resource), and cannot create two objects interfacing the same control, then each control object is equal only to itself.

*If* that's the value comparison you define for two GUI control objects, then you should be able to define that. No-one's saying otherwise, just that the default === === == is jejune and harmful.

> For that matter, I can't think of any examples in which an object should not be equal to itself.  Can you?

Absolutely. Any type that is not a value type should not facilitate value comparison. That's a practically infinite set of things

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cgat6b$1424$1@digitaldaemon.com...
> In article <cgar00$126b$1@digitaldaemon.com>, Andy Friesen says...
>
> >The real problem is that opEquals and opCmp are defined for Object, which means that any object must be comparable to any other:
>
> I figured out a way to make == (etc) into a compile error. Here's an example:
>
> #    class A
> #    {
> #        void opEquals() {}   // sneaky, huh?
> #    }

No. Stupid. (it, not you <g>)

All one needs to is cast an A to Object, and then it's visible again.


> #
> #    void main()
> #    {
> #        A a = new A();
> #        A b = new A();
> #
> #        if (a == b)    // Line 11 - now a compile error!
> #        {
> #            printf("hello world\n");
> #        }
> #    }
>
> This is what you get when you try to compile it:
>
> eq.d(11): function opEquals () does not match argument types (A )
> eq.d(11): Error: expected 0 arguments, not 1
> eq.d(11): void does not have a boolean value
>
> Well, at least the file and line number are right! :)
>
> It works because of Walter's now famous rule that name resolution happens before signature matching. The zero-argument version of opEquals() will be found first, so the rule says it will be used, and the version in Object won't! But that function has the wrong argument list, so now D can't find a match at all. Voila - one compile-time error. And you can do the same thing for opCmp() too.
>
> Arcane Jill
>
>

brilliant! Score one for compile-time type checking!

down with runtime checks ;-)

Arcane Jill wrote:
> In article <cgar00$126b$1@digitaldaemon.com>, Andy Friesen says...
> 
> 
>>The real problem is that opEquals and opCmp are defined for Object, which means that any object must be comparable to any other:
> 
> 
> I figured out a way to make == (etc) into a compile error. Here's an example:
> 
> #    class A
> #    {
> #        void opEquals() {}   // sneaky, huh?
> #    }
> #    #    void main()
> #    {
> #        A a = new A();
> #        A b = new A();
> #    #        if (a == b)    // Line 11 - now a compile error!
> #        {
> #            printf("hello world\n");
> #        }
> #    }
> 
> This is what you get when you try to compile it:
> 
> eq.d(11): function opEquals () does not match argument types (A )
> eq.d(11): Error: expected 0 arguments, not 1
> eq.d(11): void does not have a boolean value
> 
> Well, at least the file and line number are right! :)
> 
> It works because of Walter's now famous rule that name resolution happens before
> signature matching. The zero-argument version of opEquals() will be found first,
> so the rule says it will be used, and the version in Object won't! But that
> function has the wrong argument list, so now D can't find a match at all. Voila
> - one compile-time error. And you can do the same thing for opCmp() too.
> 
> Arcane Jill
> 
> 

Thank you! I (naturally) agree with everything you said because you agree that something that i am babling about for some time now makes sence. Not that this means that things will change now but atleast they have a slightly better chanse to change. :)

"Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cgblol$1mt9$1@digitaldaemon.com...
>
> "Stewart Gordon" <smjg_1998@yahoo.com> wrote in message
news:cgamjk$uvl$1@digitaldaemon.com...
> > Ivan Senji wrote:
> > <snip>
> > > There isn't really much more i could say about this. Why does == have to work as === by default?   I have never writen a code were two objects are equal when they are in the same place in memory (===),
> >
> > To save the user having to write code like
> >
> >      int opEquals(Object o) {
> >          return this === o;
> >      }
> >
> > everywhere when they _do_ write code like that.
>
> That's no argument. One might also say that *every* single object
>
> Such things are convention - and a bad one in this case - rather than any
kind of software engineering axiom.
>
> > For example, suppose you have an auto class representing a lock on some resource.  How would you define two of them being equal?  Them locking the same resource?  If the setup is such that each resource can only be locked once, then the lock object is equal only to itself.
>
> This is nonsense. Why should lock objects be value-comparable in any way?
I can think of no reason why one would ever
> need to so do. Indeed of all such things I've been writing and using over
the last 10+ years in C++, I've never had
> cause to do such a thing.
>
> C++ misstepped badly in allowing copying (initialisation and assignment)
by default for classes, where it should have
> only preserved that for structs. But it wisely does not provide any
default value comparison for class types. We know
> why D has done such a thing - built-in AAs, and array.sort - but it's a
serious mistake, and is a blight on the
> language. If a given semantic makes sense for only a subset of all types,
why provide it for all? That's MFC!
>
> > Suppose you have a GUI library.  Two GUI control objects could be considered equal if they interface the same control.  But if the library can only create controls, and not interface existing controls (such as those on a Windows dialog resource), and cannot create two objects interfacing the same control, then each control object is equal only to itself.
>
> *If* that's the value comparison you define for two GUI control objects,
then you should be able to define that.
> No-one's saying otherwise, just that the default === === == is jejune and
harmful.
>
> > For that matter, I can't think of any examples in which an object should not be equal to itself.  Can you?
>
> Absolutely. Any type that is not a value type should not facilitate value
comparison. That's a practically infinite set
> of things
>
>
>

"Ivan Senji" <ivan.senji@public.srce.hr> wrote in message news:cgc1s6$1vdk$1@digitaldaemon.com...
> Thank you! I (naturally) agree with everything you said because you agree that something that i am babling about for some time now makes sence. Not that this means that things will change now but atleast they have a slightly better chanse to change. :)

I think you overestimate my influence and/or underestimate Walter's (increasingly shaky, IMO) preference for ease of compiler implementation over language "complexity".

I still like D a lot, but I increasingly see several of its "unique features" as a bad idea. Because we're still pre 1.0, I'd be voting for weilding the scythe at this stage, before we're irretrievably stuck with some very ugly warts.

By no means an exhaustive list:

- drop the bit type
- have a serious discussion about dropping the AA built-in type
- make the return type from opApply delegates be an enum with a single public "Ok" member
- remove some of the top-heavy hierarchy methods, e.g. opCmp(), opEquals()
- give pseudo methods to built-in types, e.g. toString()
- stop shoehorning C-struct and stack-based class functionality into the single D class-key "struct". This is a marriage
made in
hell! The fact that I've identified a very real problem with bit arrays in this regard is, IMO, only the tip of the
ice-berg. Let's let stack-based classes have a new class-key, to go with the fact that they're a new concept. I don't
care if it's something as hideous as "stackclass", "sclass", "stass", or even "sklass". Any of those naming yucks are
irrelevant compared to the current conceptual nightmare. (A side effect of this is that sklasses could have ctors, and
maybe even dtors!!)
- address the DLL-GC issue. This is a *HUGE* issue with respect to the future appeal of the language. Without D
seamlessly supporting DLLs in (almost) all of their potential class/function C/D/D/C guises, it'll be still born.
- allow recursive templates
- have a clear import/name-resolution policy. (Note: I cannot really comment on this, since I've not (yet) dived into
this hairy beast, but I respect the people who've been banging on about it for some time.)

Some others I'd also like to see, but which I'm not going to bother arguing for:

- make bool => int
- have incomplete switch cases be flagged as compile-time errors


If anyone takes this as evidence why D will _never_ take off: don't. But I do hope Walter is influenced to address these issues, as I believe they are going to be very serious areas for criticism if ratified into 1.0. A couple of examples:

- it seems to me that opCmp() and/or opEquals() are in Object to support AAs, and array.sort. They are very troublesome
theoretically,
and are beginning to be practically troublesome for some. Since AAs are getting increasing criticism, aren't we keeping
a big wart in to support a small wart? If so, it's time to get out the liquid paper, I think. And why not just provide a
template sort() function for arrays in Phobos?

- as I've opined recently, the conceptual attractiveness of the bit type is specious. Some of us have had this opinion
for a long time, some more recently, but I'd hazard a guess that now a large portion of D's devotees think it's now more
trouble than it's worth. I still strongly assert that my recent discussion of bit arrays in D structs is compelling, and
I"ve not yet heard any counter to it. Here's a challenge to any remaining holders of the "keep bit" position: can anyone
identify to
me the compelling case for having the bit type, i.e. the things that cannot be adequalty covered by a library.

Anyway, to repeat myself. I am optimisitic about D, but I believe me *must* have a serious refactoring of the language *before* 1.0, and I think we're getting close to the appropriate time, before Walter's time is completely consumed on issues that could disappear just by a collective belt-tightening.

btw, I've a shocking case of the flu at the mo, so if any of this reads as insane, it might well be. :-)

William Smythe, ready with Scythe

>
> "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cgblol$1mt9$1@digitaldaemon.com...
> >
> > "Stewart Gordon" <smjg_1998@yahoo.com> wrote in message
> news:cgamjk$uvl$1@digitaldaemon.com...
> > > Ivan Senji wrote:
> > > <snip>
> > > > There isn't really much more i could say about this. Why does == have to work as === by default?   I have never writen a code were two objects are equal when they are in the same place in memory (===),
> > >
> > > To save the user having to write code like
> > >
> > >      int opEquals(Object o) {
> > >          return this === o;
> > >      }
> > >
> > > everywhere when they _do_ write code like that.
> >
> > That's no argument. One might also say that *every* single object
> >
> > Such things are convention - and a bad one in this case - rather than any
> kind of software engineering axiom.
> >
> > > For example, suppose you have an auto class representing a lock on some resource.  How would you define two of them being equal?  Them locking the same resource?  If the setup is such that each resource can only be locked once, then the lock object is equal only to itself.
> >
> > This is nonsense. Why should lock objects be value-comparable in any way?
> I can think of no reason why one would ever
> > need to so do. Indeed of all such things I've been writing and using over
> the last 10+ years in C++, I've never had
> > cause to do such a thing.
> >
> > C++ misstepped badly in allowing copying (initialisation and assignment)
> by default for classes, where it should have
> > only preserved that for structs. But it wisely does not provide any
> default value comparison for class types. We know
> > why D has done such a thing - built-in AAs, and array.sort - but it's a
> serious mistake, and is a blight on the
> > language. If a given semantic makes sense for only a subset of all types,
> why provide it for all? That's MFC!
> >
> > > Suppose you have a GUI library.  Two GUI control objects could be considered equal if they interface the same control.  But if the library can only create controls, and not interface existing controls (such as those on a Windows dialog resource), and cannot create two objects interfacing the same control, then each control object is equal only to itself.
> >
> > *If* that's the value comparison you define for two GUI control objects,
> then you should be able to define that.
> > No-one's saying otherwise, just that the default === === == is jejune and
> harmful.
> >
> > > For that matter, I can't think of any examples in which an object should not be equal to itself.  Can you?
> >
> > Absolutely. Any type that is not a value type should not facilitate value
> comparison. That's a practically infinite set
> > of things
> >
> >
> >
>
>

"Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cgc4fc$20kf$1@digitaldaemon.com...
>
> "Ivan Senji" <ivan.senji@public.srce.hr> wrote in message
news:cgc1s6$1vdk$1@digitaldaemon.com...
> > Thank you! I (naturally) agree with everything you said because you agree that something that i am babling about for some time now makes sence. Not that this means that things will change now but atleast they have a slightly better chanse to change. :)
>
> I think you overestimate my influence and/or underestimate Walter's
(increasingly shaky, IMO) preference for ease of
> compiler implementation over language "complexity".

I don't think i do. Everyone can have some influence if what they are saying
makes
sence. But afterall D is Walter's baby so he is allowed to take some time to
think
about things. For more than a couple of times i have seen things suddenly
change
after a lot of people complained.

> I still like D a lot, but I increasingly see several of its "unique
features" as a bad idea. Because we're still pre
> 1.0, I'd be voting for weilding the scythe at this stage, before we're
irretrievably stuck with some very ugly warts.

(I had to look up scythe in the dictionary) Yes

> By no means an exhaustive list:
>
> - drop the bit type

I was in favour of keeing bit and adding normal bool, but bit really is only
useful
for bit[] wich could be very nicelly implemented in a library

> - have a serious discussion about dropping the AA built-in type

Don't drop it! (It would be a shame because it can be useful
(for example: quick and dirty implementation of set)) but fix it!

> - make the return type from opApply delegates be an enum with a single
public "Ok" member

Agree

> - remove some of the top-heavy hierarchy methods, e.g. opCmp(), opEquals()

!!

> - give pseudo methods to built-in types, e.g. toString()
> - stop shoehorning C-struct and stack-based class functionality into the
single D class-key "struct". This is a marriage
> made in
> hell!

I'll yust believe you on this one

> The fact that I've identified a very real problem with bit arrays in this
regard is, IMO, only the tip of the
> ice-berg. Let's let stack-based classes have a new class-key, to go with
the fact that they're a new concept. I don't
> care if it's something as hideous as "stackclass", "sclass", "stass", or
even "sklass". Any of those naming yucks are
> irrelevant compared to the current conceptual nightmare. (A side effect of
this is that sklasses could have ctors, and
> maybe even dtors!!)
> - address the DLL-GC issue. This is a *HUGE* issue with respect to the
future appeal of the language. Without D
> seamlessly supporting DLLs in (almost) all of their potential
class/function C/D/D/C guises, it'll be still born.
> - allow recursive templates
> - have a clear import/name-resolution policy. (Note: I cannot really
comment on this, since I've not (yet) dived into
> this hairy beast, but I respect the people who've been banging on about it
for some time.)
>
> Some others I'd also like to see, but which I'm not going to bother
arguing for:
>
> - make bool => int
> - have incomplete switch cases be flagged as compile-time errors
>
>
> If anyone takes this as evidence why D will _never_ take off: don't. But I
do hope Walter is influenced to address these
> issues, as I believe they are going to be very serious areas for criticism
if ratified into 1.0. A couple of examples:
>
> - it seems to me that opCmp() and/or opEquals() are in Object to support
AAs, and array.sort. They are very troublesome
> theoretically,
> and are beginning to be practically troublesome for some. Since AAs are
getting increasing criticism, aren't we keeping
> a big wart in to support a small wart? If so, it's time to get out the
liquid paper, I think. And why not just provide a
> template sort() function for arrays in Phobos?
>
> - as I've opined recently, the conceptual attractiveness of the bit type
is specious. Some of us have had this opinion
> for a long time, some more recently, but I'd hazard a guess that now a
large portion of D's devotees think it's now more
> trouble than it's worth. I still strongly assert that my recent discussion
of bit arrays in D structs is compelling, and
> I"ve not yet heard any counter to it. Here's a challenge to any remaining
holders of the "keep bit" position: can anyone
> identify to
> me the compelling case for having the bit type, i.e. the things that
cannot be adequalty covered by a library.
>
> Anyway, to repeat myself. I am optimisitic about D, but I believe me
*must* have a serious refactoring of the language
> *before* 1.0, and I think we're getting close to the appropriate time,
before Walter's time is completely consumed on
> issues that could disappear just by a collective belt-tightening.

I am also very optimistic (as are most of us here probabbly or we wouldn't
be
using this language for such a long time now)

Walter is going to fix things :)

> btw, I've a shocking case of the flu at the mo, so if any of this reads as
insane, it might well be. :-)

I read nothing crazy...

> William Smythe, ready with Scythe

...until now :)


> >
> > "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cgblol$1mt9$1@digitaldaemon.com...
> > >
> > > "Stewart Gordon" <smjg_1998@yahoo.com> wrote in message
> > news:cgamjk$uvl$1@digitaldaemon.com...
> > > > Ivan Senji wrote:
> > > > <snip>
> > > > > There isn't really much more i could say about this. Why does ==
have
> > > > > to work as === by default?   I have never writen a code were two objects are equal when they are in the same place in memory (===),
> > > >
> > > > To save the user having to write code like
> > > >
> > > >      int opEquals(Object o) {
> > > >          return this === o;
> > > >      }
> > > >
> > > > everywhere when they _do_ write code like that.
> > >
> > > That's no argument. One might also say that *every* single object
> > >
> > > Such things are convention - and a bad one in this case - rather than
any
> > kind of software engineering axiom.
> > >
> > > > For example, suppose you have an auto class representing a lock on
some
> > > > resource.  How would you define two of them being equal?  Them
locking
> > > > the same resource?  If the setup is such that each resource can only
be
> > > > locked once, then the lock object is equal only to itself.
> > >
> > > This is nonsense. Why should lock objects be value-comparable in any
way?
> > I can think of no reason why one would ever
> > > need to so do. Indeed of all such things I've been writing and using
over
> > the last 10+ years in C++, I've never had
> > > cause to do such a thing.
> > >
> > > C++ misstepped badly in allowing copying (initialisation and
assignment)
> > by default for classes, where it should have
> > > only preserved that for structs. But it wisely does not provide any
> > default value comparison for class types. We know
> > > why D has done such a thing - built-in AAs, and array.sort - but it's
a
> > serious mistake, and is a blight on the
> > > language. If a given semantic makes sense for only a subset of all
types,
> > why provide it for all? That's MFC!
> > >
> > > > Suppose you have a GUI library.  Two GUI control objects could be considered equal if they interface the same control.  But if the
library
> > > > can only create controls, and not interface existing controls (such
as
> > > > those on a Windows dialog resource), and cannot create two objects interfacing the same control, then each control object is equal only
to
> > > > itself.
> > >
> > > *If* that's the value comparison you define for two GUI control
objects,
> > then you should be able to define that.
> > > No-one's saying otherwise, just that the default === === == is jejune
and
> > harmful.
> > >
> > > > For that matter, I can't think of any examples in which an object
should
> > > > not be equal to itself.  Can you?
> > >
> > > Absolutely. Any type that is not a value type should not facilitate
value
> > comparison. That's a practically infinite set
> > > of things
> > >
> > >
> > >
> >
> >
>
>
>

Matthew wrote:
> "Ivan Senji" <ivan.senji@public.srce.hr> wrote in message news:cgc1s6$1vdk$1@digitaldaemon.com...
> 
>>Thank you! I (naturally) agree with everything you said because
>>you agree that something that i am babling about for some time
>>now makes sence. Not that this means that things will change now
>>but atleast they have a slightly better chanse to change. :)
> 
> 
> I think you overestimate my influence and/or underestimate Walter's (increasingly shaky, IMO) preference for ease of
> compiler implementation over language "complexity".
> 
> I still like D a lot, but I increasingly see several of its "unique features" as a bad idea. Because we're still pre
> 1.0, I'd be voting for weilding the scythe at this stage, before we're irretrievably stuck with some very ugly warts.
>
agree...there are huge swaths of good ideas, but the bad features keep many of the good features at bay but introducing unnecessary run-time problems.

> By no means an exhaustive list:
> 
> - drop the bit type
agree--it's only useful as vector<bool> which can be a specialization in DTL. the number of people who use this is I'm sure ironically small. I used it back when I had 640K of memory to save space for a "has this part of the framebuffer changed" pool. it made the system grind to a halt wrt speed ;-), so I ate the memory cost of a char-per. Perhaps if they were built in, it would have gone faster, but nowadays I'd use vector<bool> to try it

> - have a serious discussion about dropping the AA built-in type
agree..that belongs in a library--perhaps in phobos, but a library nevertheless.  If it can't be written efficiently *in* the language then perhaps the language needs to change

> - make the return type from opApply delegates be an enum with a single public "Ok" member
> - remove some of the top-heavy hierarchy methods, e.g. opCmp(), opEquals()
got to get rid of these-- if I have an opEquals() (typo, no argument) function in a subclass, then it depends whether or not I've cast my subclass to object which one it'll call--yuck!

> - give pseudo methods to built-in types, e.g. toString()
sure...the whole std.string.toString(...) is clunky and leads me to alias tos(..) everywhere

> - stop shoehorning C-struct and stack-based class functionality into the single D class-key "struct". This is a marriage
> made in
> hell! The fact that I've identified a very real problem with bit arrays in this regard is, IMO, only the tip of the
> ice-berg. Let's let stack-based classes have a new class-key, to go with the fact that they're a new concept. I don't
> care if it's something as hideous as "stackclass", "sclass", "stass", or even "sklass". Any of those naming yucks are
> irrelevant compared to the current conceptual nightmare. (A side effect of this is that sklasses could have ctors, and
> maybe even dtors!!)
agree...numeric types as stack-based items is important...classes force people into using the heap--and for librarys people need to be as generic as possible, i.e. using the stack unless new MyStruct is used....


> - address the DLL-GC issue. This is a *HUGE* issue with respect to the future appeal of the language. Without D
> seamlessly supporting DLLs in (almost) all of their potential class/function C/D/D/C guises, it'll be still born.
> - allow recursive templates
the metaprogramming language must be turing complete, yes! (at least with some sort of recusion limit set by the user)

> - have a clear import/name-resolution policy. (Note: I cannot really comment on this, since I've not (yet) dived into
> this hairy beast, but I respect the people who've been banging on about it for some time.)
> 
> Some others I'd also like to see, but which I'm not going to bother arguing for:
I agree that the way it is now makes it utterly fragile to import new libraries which may cause completely unrelated conflicts with other libraries.
> 
> - make bool => int
typesafety wrt bools is also a key issue here I'd think...but arguing is wasteful of time
> - have incomplete switch cases be flagged as compile-time errors
anything potentially incorrect that *can* be a compile time error *should* be one :-)

fixing all these issues will help D take off... I think adding more compile time sort of checks is also important--things like manditory override keywords and other ways to help a willing programmer prevent self-foot-shooting ;-)
--Daniel

> 
> 
> If anyone takes this as evidence why D will _never_ take off: don't. But I do hope Walter is influenced to address these
> issues, as I believe they are going to be very serious areas for criticism if ratified into 1.0. A couple of examples:
> 
> - it seems to me that opCmp() and/or opEquals() are in Object to support AAs, and array.sort. They are very troublesome
> theoretically,
> and are beginning to be practically troublesome for some. Since AAs are getting increasing criticism, aren't we keeping
> a big wart in to support a small wart? If so, it's time to get out the liquid paper, I think. And why not just provide a
> template sort() function for arrays in Phobos?
> 
> - as I've opined recently, the conceptual attractiveness of the bit type is specious. Some of us have had this opinion
> for a long time, some more recently, but I'd hazard a guess that now a large portion of D's devotees think it's now more
> trouble than it's worth. I still strongly assert that my recent discussion of bit arrays in D structs is compelling, and
> I"ve not yet heard any counter to it. Here's a challenge to any remaining holders of the "keep bit" position: can anyone
> identify to
> me the compelling case for having the bit type, i.e. the things that cannot be adequalty covered by a library.
> 
> Anyway, to repeat myself. I am optimisitic about D, but I believe me *must* have a serious refactoring of the language
> *before* 1.0, and I think we're getting close to the appropriate time, before Walter's time is completely consumed on
> issues that could disappear just by a collective belt-tightening.
> 
> btw, I've a shocking case of the flu at the mo, so if any of this reads as insane, it might well be. :-)
> 
> William Smythe, ready with Scythe
> 
> 
>>"Matthew" <admin.hat@stlsoft.dot.org> wrote in message
>>news:cgblol$1mt9$1@digitaldaemon.com...
>>
>>>"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message
>>
>>news:cgamjk$uvl$1@digitaldaemon.com...
>>
>>>>Ivan Senji wrote:
>>>><snip>
>>>>
>>>>>There isn't really much more i could say about this. Why does == have
>>>>>to work as === by default?   I have never writen a code were two
>>>>>objects are equal when they are in the same place in memory (===),
>>>>
>>>>To save the user having to write code like
>>>>
>>>>     int opEquals(Object o) {
>>>>         return this === o;
>>>>     }
>>>>
>>>>everywhere when they _do_ write code like that.
>>>
>>>That's no argument. One might also say that *every* single object
>>>
>>>Such things are convention - and a bad one in this case - rather than any
>>
>>kind of software engineering axiom.
>>
>>>>For example, suppose you have an auto class representing a lock on some
>>>>resource.  How would you define two of them being equal?  Them locking
>>>>the same resource?  If the setup is such that each resource can only be
>>>>locked once, then the lock object is equal only to itself.
>>>
>>>This is nonsense. Why should lock objects be value-comparable in any way?
>>
>>I can think of no reason why one would ever
>>
>>>need to so do. Indeed of all such things I've been writing and using over
>>
>>the last 10+ years in C++, I've never had
>>
>>>cause to do such a thing.
>>>
>>>C++ misstepped badly in allowing copying (initialisation and assignment)
>>
>>by default for classes, where it should have
>>
>>>only preserved that for structs. But it wisely does not provide any
>>
>>default value comparison for class types. We know
>>
>>>why D has done such a thing - built-in AAs, and array.sort - but it's a
>>
>>serious mistake, and is a blight on the
>>
>>>language. If a given semantic makes sense for only a subset of all types,
>>
>>why provide it for all? That's MFC!
>>
>>>>Suppose you have a GUI library.  Two GUI control objects could be
>>>>considered equal if they interface the same control.  But if the library
>>>>can only create controls, and not interface existing controls (such as
>>>>those on a Windows dialog resource), and cannot create two objects
>>>>interfacing the same control, then each control object is equal only to
>>>>itself.
>>>
>>>*If* that's the value comparison you define for two GUI control objects,
>>
>>then you should be able to define that.
>>
>>>No-one's saying otherwise, just that the default === === == is jejune and
>>
>>harmful.
>>
>>>>For that matter, I can't think of any examples in which an object should
>>>>not be equal to itself.  Can you?
>>>
>>>Absolutely. Any type that is not a value type should not facilitate value
>>
>>comparison. That's a practically infinite set
>>
>>>of things
>>>
>>>
>>>
>>
>>
> 
> 
>