Matthew wrote:

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

I think we already (almost) have the tools for this: auto classes.

The problem is that they still require that 'new' cruft.  Structs don't, and we're all lazy oafs, so here we are. :)

This deserves emphasis:

> 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 agree.  Only now are we starting to get a feel for what the completed language is turning into, and we should feel lucky that it's happening before 1.0, when there's still a chance to fix things.

Fixing the conceptual bugs is a lot harder than fixing the implementation bugs once you have backwards compatibility to worry about. :)

I forget who said this, but it seems fitting:

    "It's done when there isn't anything you could possibly remove"

 -- andy

In article <cgc4fc$20kf$1@digitaldaemon.com>, Matthew says...
>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.

Okay, let's call this a poll and see where the votes go. I do hope Walter counts up the votes.


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

At first, I liked the bit type. Then I learned of some problems with bit arrays and wrote a workaround for some special cases, but problems remained with (for example) expressions like &myBitArray[3], or passing myBitArray[3] to a function as an out or inout parameter. Currently, I'd say I could live with ditching the bit /if/ a bitarray type existed to replace it. I have functions in my (pending) random number library which return a bit[]. I do need bit /arrays/, I just don't need bit.

So, if the suggestion had been:

>- drop the bit type and replace it with a bitarray type

then I would have voted yes. Without the replacement, I'm not sure.

Furthermore, the only (note, *ONLY*) reason I don't want to argue about bool at this time, is because I know that doing so would be a complete waste of time, because this is one area in which Walter doesn't appear to listen to majority opinion. But "bool" must be aliased to /something/, since libraries need, on occasion, to return "true" or "false" to calling applications. So if we really can't have a typesafe bool until the distant future, then for now I'd prefer to see it aliased to int (rather than byte).


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

We don't need to vote on whether or not to have a serious discussion. Just start the thread - I'll join in.



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

Sorry, you've lost me. If there is only /one/ possible return type, then why not just return void? Surely, you only need a return value if there are at least two possibilities for it?


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

Removing opCmp() gets a loud yes vote from me.

I'm still not convinced about opEquals() though. In math (and yes, I know D is
not math), an equals test always makes sense - even if you're comparing apples
and oranges (but the answer is always false in such cases). For example, if N is
the set of non-negative integers, and V is the set of three dimensional vectors,
(two sets which don't intersect), then I can still write:

#    For all v in V there does not exist an n in N such that v = n

and it would be a true statement (as opposed to a meaningless statement). For most things, you want == to return false, but you always want an object to be equal to itself. The current default gives this behaviour in /most/ cases, and for that reason I think it should stand (and simply be overridden where that behaviour is different from the default).

But I'm with you on opCmp().



>- give pseudo methods to built-in types, e.g. toString()

Aye


>- stop shoehorning C-struct and stack-based class functionality into the single D class-key "struct".

At first, I wasn't too keen on this, but then I realized that mostly I was objecting because I didn't like the suggested names for things. But since you said "Any of those naming yucks are irrelevant", I guess you're saying you only want the feature, not necessarily any particular syntax. That being so, I'll vote yes, and here are my suggested names for things:

* struct         -- a D-style structure, as now
* union          -- a D-style union, as now
* strict struct  -- a struct which is only permitted to contain primitive types,
>                   strict stucts and strict unions
* strict union   -- a union which is only permitted to contain primitive types,
>                   strict stucts and strict unions

The "strict" variants are your C-style structs/unions.


>(A side effect of this is that sklasses could have ctors, and
>maybe even dtors!!)

No, I think there are some very real issues with D-structs having D-structors. I think we'll have to be content with constructors only for a while. (When are we going to get those struct constructors, by the way?)


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

Aye.


>- allow recursive templates

Aye.

And member function templates.
And type deduction.


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

Aye.

In particular, it should /not/ be an error for a module (d source file) and a
package (directory) to have the same name in the same place. This is a
/horrible/ wart.



>- make bool => int

I vote for make bool => bool, a distinct type. But I know Walter will ignore that. bool => int would be my second preference.


>- have incomplete switch cases be flagged as compile-time errors

Aye



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

That's not a fair question. "bit" type is the status quo. One does not need a "compelling case" to maintain the status quo. Rather, the status quo remains unless there is a compelling case to change it.

Personally, I don't think there is a compelling case to keep the bit, but I'd expect to need a stronger argument than that to ditch it.

Come to think of it, I don't think there's a compelling case for keeping char or wchar either. Let's ditch them both, then we can rename "dchar" as "char" and use /one/ character type throughout, with appropriate transcoding relegated to library routines. Just /imagine/ how much that would simplify D string handling. No more toUTF8(); no more cast(dchar[])"hello"; - just the obvious representation:

#    string = array of characters

What more could you want?

D's multiple char types are a bad idea because they don't store characters, they store "code units" (UTF-xx fragments), and trying to explain this to everyone is getting to be more trouble than it's worth. Once library-based transcoding is in place, with the UTF family fully supported, we actually won't need char or wchar any more.

(Sorry, that digression should probably have been in a separate thread).


Arcane Jill

Ok, so I'm a newbie to the language, but I think that makes it even more significant that I can immediately recognize and agree on four issues brought up by people a lot smarter than me who've used the language a lot longer <g>.

Based on the criteria of usefulness, ease of compiler implementation and performance, I think built-in AA's, the bit type and 'bool as bit' could be dropped. I also strongly agree that a stack based class needs to be added.

- Built-in AA's. I originally thought the idea was cool, but they are not performant and already they are seemingly being 'replaced' by library functionality (that in itself is pretty damning). The clincher here is that they also seem to force other things on the language that perhaps should not be there. If AA's and the adverse semantics they currently require for D can be fixed then I think they would still be a great addition.

- Bit type. Seems cool but in reality may only end up as a 'nice to have for small jobs' type of thing that is better implemented through libraries anyhow. Also I think it makes the language itself harder to implement. Take a look at gc.d for example. About 1/5 of that code is dedicated just to bit arrays. I'd imagine it adds a fair amount to the compiler implementation as well.

- bool as bit. For this I have to ask: Why?!? Much slower than byte or word and I really don't see any real practical advantage to it, at least at this point in my D education.

- Stack based class. IMHO, this is perhaps the most important performance advantage that C++ has over Java from a pure computer science point of view. And evidently in the 'real world' it can make a heck of a difference because C++ is surviving, some would say thriving, for OOP programming in a world where Java is widely recognized as a better pure-OOP language (Much of the currently relevant 'Java is SLOW' sentiment is related to this one thing). It would be really, really useful to have Ctors for some sort of very efficient object.

I think D should really, really concentrate on 1) fixing the weaknesses of C/++ whilst 2) avoiding the weaknesses of Java and C#. Add nice to have functionality only if it doesn't impede 1) & 2) _or_ add weaknesses to D that may facilitate a need for 'E' ;)

- Dave

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

I'll give my full support (FWIW) to each of the items you note, except for
opEquals(). And I'll add (or emphasize) a few more, too:

1) the damnable name-resolution approach belongs in hell; not a modern language. AJ's example of breaking opEquals(), opCmp() etc shows just how puny and fragile the approach truly is. If D were strongly-typed regarding method-arguments, all those wacky examples of sloppy-coding and edge-conditions would not be a problem. As Regan pointed out a while back, it's the conversion and promotion of primitive types that cause the confusion over which method should be invoked within an inheritance scheme. If that were fixed, the method-alias 'concept' would have zero value, at best.

2) Interface-contracts should be satisfied by any means available to the class; including inherited methods, abstract declarations, etc, etc

3) primitive types should have overloaded methods on them, like properties (this needs /more/ emphasis). Andy noted that C # uses value classes, and that D could do something slick via a struct for each primitive type.

4) the override keyword should be mandatory.

5) bit-array is now stillborn. Better off with a bit-set class, or equivalent.

6) AAs are a dead duck. The one benefit they exhibit (IMO) is that the compiler can sneakily avoid casting the return value, and it works for primitive types. Both of these can be addressed by templates. The negatives against AAs are as long as my arm. Array sorting is in the same boat. There was a need at one time, but that time has long since past.

7) additional emphasis on the shared GC, and the whole DLL issue.

8) the weird dual behavior of concatenation (~+ different than ax ~ y ~ z)

9) printf is /still/ linked-in via the root Object

I, also, am an optimist regarding D. That doesn't mean I have to close my eyes to the flaws it often exhibits.



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

but I wouldn't use an auto class to make a numeric type... numeric types need to be in containers and need to sit in the heap if people wish to keep them there... auto is merely to tell the compiler that resources need to be freed as soon as the class goes out of scope...it doesn't specify where the "class" itself comes from

Andy Friesen wrote:
> 
> I think we already (almost) have the tools for this: auto classes.
> 
> The problem is that they still require that 'new' cruft.  Structs don't, and we're all lazy oafs, so here we are. :)
> 

Matthew wrote:
> Me too. I dislike the root class having things that derived classes (or their designers) cannot make informed choices
> on.
> 
> And a runtime assert is a revolting way to denote that a type should not take part in comparison operations.
> 
> "Lars Ivar Igesund" <larsivar@igesund.net> wrote in message news:cf3ik6$2abe$1@digitaldaemon.com...
> 
>>Ivan Senji wrote:
>>
>>
>>>opCmp shouldn't be discriminated this way! :)
>>
>>Ivan's correct. You got my vote.
>>
>>Lars Ivar Igesund
> 
> 
> 
If there were multiple inheritance, then I could see your point.
There isn't.

I know that in principle it's feasible to add them in to every class via interfaces...but UGH!

The problem is, sometimes I need to add functionality that's common to multiple subclasses of a class that didn't need it.  And it needs to be seen as not just the same name, but the same function (with variations for inherited alterations).

Well, I CAN do it, I've proven that.  I've also proved I don't like the process.  And the functions that most frequently need to be added are the operator equivalents.  And of those, the comparison operators are the most frequent.

Having opCmp defined at Object saves me a bunch of time, though what I really want is more like "This comparison is via the grandparent inheritance object".

I DO wish that C++ hadn't poisoned the well for multiple inheritance.  Eiffel showed a valid and decent approach, but almost nobody notices because C++ has convinced everyone that it's a horrible idea.  (Even Ada95 did it better than C++, and Ada95 was designed under tremendous constraints...and decided on by a committee.)

In article <cgc4fc$20kf$1@digitaldaemon.com>, Matthew says...
>
>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

Agreed.  It's a nice idea, but seems to cause too many problems in practice.

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

As long as they're removed from Object and not removed altogether.  Unless we want to rely entirely on external comparison functions, which seems clunky.

>- give pseudo methods to built-in types, e.g. toString()

Works for me.

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

I like using "struct" for POD types, but it stinks that there's no built-in support for constructors.  As for stack classes, I think "auto" might serve in most cases.

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

Definately.  This has to be sorted out before 1.0.

>- allow recursive templates

Yes please.

>- make bool => int

Why make it == sizeof(int) rather than sizeof(byte)?  Not to derail the thread,
I'm just curious.

>- have incomplete switch cases be flagged as compile-time errors

I haven't seen any discussion of this one.  Will have to search the archives.

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

I haven't done enough class-level programming in D to really say.  I like the idea of the built-in AAs, even though they don't have all the features that a library implementation would have.  Would it be too much to keep AAs and drop Object.opCmp and Object.OpEquals?

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

I still have your long post on bits marked "unread" so I will get around to replying to it, but I can summarize.  I personally like "bit" though I think it is a mistake to confuse it with "bool."  Also, getting bit to work with slicing and such seems complex enough that I don't think it's worth keeping.  A bitset library class could be implemented fairly easily and has the potential to be just as fast as the language version we have now.  Also, I think it would be a mistake to have more than one language type that has "bool" semantics.  So adding bool as a separate type and leaving bit is just not workable IMO.

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

Agreed.  Especially since most of these issues are fairly significant aspects of the language.  I suppose it's worth discussing all of this with attention to the fact that D should be different from C++, so feature evaluation should be as disconnected from past experience as possible.


Sean

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cgcfba$284k$1@digitaldaemon.com...

> >- have a serious discussion about dropping the AA built-in type
>
> We don't need to vote on whether or not to have a serious discussion. Just start the thread - I'll join in.

I was lazily hoping to prompt arguments from others who have stronger (and better informed) opinions on the subject than I

> >- make the return type from opApply delegates be an enum with a single public "Ok" member
>
> Sorry, you've lost me. If there is only /one/ possible return type, then why not just return void? Surely, you only need a return value if there are at least two possibilities for it?

The foreach delegate, created by the compiler, can return 0 to indicate "continue enumeration" to opApply(), or it can return one of several other integer values to indicate "break", "goto" and other such things. The author of an opApply() *MUST* only either return 0, or retain unaltered the non-0 value returned by the delegate. But since the type is int there's nothing syntactically helping them do so. If we had an enum with only one public value, say Ok, or ContinueEnumeration, coders would have to resort to casting to break the foreach mechanism, whereas at the moment all they need do is any integral operation. Naturally, the compiler would use other values, but we don't care about what they are, since they're hidden in the foreach/delegate mechanisms.

> >- stop shoehorning C-struct and stack-based class functionality into the single D class-key "struct".
>
> At first, I wasn't too keen on this, but then I realized that mostly I was objecting because I didn't like the suggested names for things. But since you said "Any of those naming yucks are irrelevant", I guess you're saying you only want the feature, not necessarily any particular syntax. That being so, I'll vote yes, and here are my suggested names for things:
>
> * struct         -- a D-style structure, as now
> * union          -- a D-style union, as now
> * strict struct  -- a struct which is only permitted to contain primitive types,
> >                   strict stucts and strict unions
> * strict union   -- a union which is only permitted to contain primitive types,
> >                   strict stucts and strict unions
>
> The "strict" variants are your C-style structs/unions.

I don't like the two keyword. How about "cstruct" and "cunion"?

> >(A side effect of this is that sklasses could have ctors, and
> >maybe even dtors!!)
>
> No, I think there are some very real issues with D-structs having D-structors. I think we'll have to be content with constructors only for a while. (When are we going to get those struct constructors, by the way?)

Sure. I'm not in the least expert about D structs, so I take your word for that.

> Aye.
>
> And member function templates.

We have these, although there are problems with them.

> And type deduction.

> >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.
>
> That's not a fair question. "bit" type is the status quo. One does not need a "compelling case" to maintain the status quo. Rather, the status quo remains unless there is a compelling case to change it.
>
> Personally, I don't think there is a compelling case to keep the bit, but I'd expect to need a stronger argument than that to ditch it.

Reasonable

> Come to think of it, I don't think there's a compelling case for keeping char or wchar either. Let's ditch them both, then we can rename "dchar" as "char" and use /one/ character type throughout, with appropriate transcoding relegated to library routines. Just /imagine/ how much that would simplify D string handling. No more toUTF8(); no more cast(dchar[])"hello"; - just the obvious representation:
>
> #    string = array of characters
>
> What more could you want?
>
> D's multiple char types are a bad idea because they don't store characters, they store "code units" (UTF-xx fragments), and trying to explain this to everyone is getting to be more trouble than it's worth. Once library-based transcoding is in place, with the UTF family fully supported, we actually won't need char or wchar any more.
>
> (Sorry, that digression should probably have been in a separate thread).

No. It was apposite. And also thrilling. Let's have only one char type, if indeed it really is possible. That'd be marvellous. (I'm one of those completely baffled by D's internationalisation mechanisms!)

In article <cgdt7a$267$1@digitaldaemon.com>, Matthew says...

>> >- have a serious discussion about dropping the AA built-in type
>>
>> We don't need to vote on whether or not to have a serious discussion. Just start the thread - I'll join in.
>
>I was lazily hoping to prompt arguments from others who have stronger (and better informed) opinions on the subject than I

Ah, well that's probably not I. I am very familiar with /using/ C++'s STL containers, but I have never /written/ a decent container class. (I do know how they work though, so I'm kind of half-informed).




>> Surely, you only need a return value if there are at least two possibilities for it?
>
>The foreach delegate, created by the compiler, can return 0 to indicate "continue enumeration" to opApply(), or it can return one of several other integer values to indicate "break", "goto" and other such things. The author of an opApply() *MUST* only either return 0, or retain unaltered the non-0 value returned by the delegate. But since the type is int there's nothing syntactically helping them do so. If we had an enum with only one public value, say Ok, or ContinueEnumeration, coders would have to resort to casting to break the foreach mechanism, whereas at the moment all they need do is any integral operation. Naturally, the compiler would use other values, but we don't care about what they are, since they're hidden in the foreach/delegate mechanisms.

So in other words there are TWO possible returns. Why can't they be true and false then? I'm not arguing with you, just trying to understand, and keep things simple.

(Of course, I understand that bools are less typesafe than enums. It's something that I've complained about for ages. But if you want to use enums to get around the lack of type-safety in bools then that merely strengthens the case for typesafe bools.)



>> The "strict" variants are your C-style structs/unions.
>
>I don't like the two keyword. How about "cstruct" and "cunion"?

Okay. Suits me.


Arcane Jill

"Arcane Jill" <Arcane_member@pathlink.com> escribió en el mensaje
news:cgf74s$ogc$1@digitaldaemon.com
| In article <cgdt7a$267$1@digitaldaemon.com>, Matthew says...
|| The foreach delegate, created by the compiler, can return 0 to indicate
"continue
|| enumeration" to opApply(), or it can return one of several other integer
values
|| to indicate "break", "goto" and other such things. The author of an opApply()
|| *MUST* only either return 0, or retain unaltered the non-0 value returned by
the
|| delegate. But since the type is int there's nothing syntactically helping
them do
|| so. If we had an enum with only one public value, say Ok, or
ContinueEnumeration,
|| coders would have to resort to casting to break the foreach mechanism,
whereas at
|| the moment all they need do is any integral operation. Naturally, the
compiler
|| would use other values, but we don't care about what they are, since they're
|| hidden in the foreach/delegate mechanisms.
|
| So in other words there are TWO possible returns. Why can't they be true and
| false then? I'm not arguing with you, just trying to understand, and keep
things
| simple.
|

Not two: several, as Matthew stated. We don't know which values are those, and I don't think we have to. So a bool wouldn't suffice.

-----------------------
Carlos Santander Bernal