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

No. There are many returns. But the opApply() implementator may only know the following of the value returned from the delegate:

- the value is zero. Carry on enumerating
- the value is non-zero. This value must be returned *UNMODIFIED* to the caller of opApply. This value is the
communcation from the compiler-generated delegate to the compiler-generated foreach code.

The important aspect of this is that if the opApply() code (accidentally) modifies this value, then the whole thing'll drop like a cow in an abertoire. Since there is *NO NEED* for the opApply() to ever know anything about this value, other than the fact that it is non-zero, I've been requesting that it be changed to a single-valued enum, as in

    enum OpApplyRetVal
    {
        OK    =    0
    };

for a _long_ time. That way, the only way that an error can occur is if the opApply() author _deliberately_ tries to screw it. (Inside the compiler-created infrastructure, Walter'll still use it as an int, of course.)

This is something that would cost nothing performance-wise, would be easy to do in the compiler, has absolutely no bad points to users of D, and offers a significant improvement in robustness. I've never understood why Walter considers this too trivial to be bothered with, and I still question that. Just because no-one's screwed opApply() - to our knowledge, anyway - does not mean that no-one will in the future. IMO, it's pretty much guaranteed. And when one considers that this is _more_ likely the _more_ complex the opApply() is, the harder it will be for the hapless author to spot that they've done something wrong. They'll just think that D's foreach mechanism is flaky shit, and, in a funny kind of way, they'll be right!

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

Let's go for it then, eh?

Walter, cstruct & cunion??

And let's not forget complete & full debug symbols ...


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

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

Ok, if I can keep 'true' and 'false'.

> - have a serious discussion about dropping the AA built-in type
Discussion, yes.

> - make the return type from opApply delegates be an enum with a single public "Ok" member
You make good arguments for this.

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

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

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

> - 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.
Heartily agree. D has made the DllHell much bigger.

> - allow recursive templates
I'm sure that will be nice.

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

And as antiAlias just said;

Complete, working debug symbols.

Lars Ivar Igesund

Dave schrieb:
> 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>.

There are people who have used the language even longer, but don't have enough time to read the newsgroup, or just stick out of discussions which won't change Walters mind anyway. (That is, otherwise we'd loose faith in Walter)

I have been here much longer than Mathhew, Jill and many others. I'm definately not smarter then them, but i just want to have my point of view stated as a counter-weight.

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

Stack based class would turn D into only better C++ performance wise. We will have implicitly generated try...finally frames all over, which i would like to avoid.

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

I got used to using them. And there is nothing which makes them "not performant" in principle. And a very nice syntax. But if there are so many people against them, then to hell with them, they're not gonna be missed too much.

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

The strong point of this is added consistency. If we had, say, a larger sized bool, then people would still wish that boolarrays would be packed bitwise. And then we're back to the complexity.

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

Why the heck should it be slower? The compiler groups bits always into bytes. Single bools may even be int-sized - although in the current implementation they are not, Walter said he would like to do that once.

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

Where raw performance is needed, polymorphy has to pass, for some good reasons - one of them is that the space that a class takes on the stack must be known in advance. This also works in C++ this way - polymorphy breaks when you create objects on a stack. So why not use a struct already??? We could make some nice enhancements, like allow a struct to inherit from a class, and vice versa.

There is also a technical problem with destructors. For heap-placed objects, garbage collector is responsible for calling the destructor. For stack-based objects, a try...finally frame has to be arranged. In C++, this has to be arranged in reality almost every function. This makes you say goodbye to small (non-inlinable, e.g. virtual) functions being fast, due to higher call overhead, programs binaries grow faster than without, exceptions propagate more slowly... So, we have our auto objects which place such a frame, but they don't invite to be used frequently. Perhaps if someone proposes a sane extension which could be made to the auto objects, it could be considered.

If you are talking about initial allocation of an object on the stack, this can already be done, but it may not have a distructor called. One of the other strong points of C++ performance is that you can allocate objects from "pools" or other specialised memory managers much faster than a standard allocator would. In D, we have a class new and delete construsts to accomplish that easily.

> 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' ;)

D must have a strong face and resist certain kinds of temptations. :)

-eye

Matthew schrieb:

> 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

Not necessary IMO. Perhaps the implementation can be enhanced or some semantic changes can be brought in.

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

That wouldn't hurt much. However, if your consern is efficiency, it shouldn't be. A compiler could be made check idiomatic cases of successive test and access, and optimize the second test on access out.

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

Hmm... some bit paranoia? ;> I agree that this is a consistency spot which could (should?) be enhanced. But than again, if you mean to protect the programmer against his own stupidity, this spot is too harmless to concentrate on - compared with hundreds of other issues.

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

Hm, perhaps... But it would make an impact on performance, wouldn't it?

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

And to operator overloads, which would be nice for templates, thus thingls like "5.opCmp(6)" would work.

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

I think i'm taking Walter's position here.

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

Perhaps we could develop our own cross-OS binary format for libraries, and embed a loader in Phobos. The task of this should be to provide both interface and object code on the one hand, and allow the library to use the object code from the main executable. It would not only solve the GC problem, but also all of the plug-in writing problems. DLL is not very adequate, i guess.

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

In fact, probably top-level private import works quite OK, but i still don't like the situation of mixing the scopes. Import "as" would be cool.

> Some others I'd also like to see, but which I'm not going to bother arguing for:
> 
> - make bool => int

I think you have been mixing up the principal, design issues, and the implementation issues. It is possible to make a single bit take the same storage as an int.

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

Perhaps they should be, but it's not worth bringing up.

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

Is the library willing to pay the interface casting penalty? How much is it anyway?

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

It is only a consistency issue. When dealing with boolean types, there will always be issues and/or hacks, because everything which looks like a boolean array is expected to be bit-packed.

-eye

Ilya Minkov wrote:
> Matthew schrieb:
>> - 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.
> 
> 
> Perhaps we could develop our own cross-OS binary format for libraries, and embed a loader in Phobos. The task of this should be to provide both interface and object code on the one hand, and allow the library to use the object code from the main executable. It would not only solve the GC problem, but also all of the plug-in writing problems. DLL is not very adequate, i guess.

++this.votes;  // :)

Ilya Minkov wrote:
> Matthew schrieb:
> 
>> 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
> 
> 
> Not necessary IMO. Perhaps the implementation can be enhanced or some semantic changes can be brought in.

I disagree.  bit has always been the black sheep, and it probably always will.  You can't take the address of a bit, nor can you pass one by reference.  Personally, I think the fact that it can easily be implemented within D is the most compelling reason to drop it.

>> - have a serious discussion about dropping the AA built-in type
> 
> That wouldn't hurt much. However, if your consern is efficiency, it shouldn't be. A compiler could be made check idiomatic cases of successive test and access, and optimize the second test on access out.

I think AAs could be removed for the same reason as bit: it's very easy to implement it using D, so why complicate the language by building it in? (further, there's the fact that the implementation requires that Object define opCmp and opEquals)

>> - remove some of the top-heavy hierarchy methods, e.g. opCmp(), opEquals()
> 
> Hm, perhaps... But it would make an impact on performance, wouldn't it?

Only if AAs and array.sort remain as they are.  It would be more than feasable to turn this into a performance /gain/. (more on this below)

>> 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            troublesomeforsome.SinceAAsaregettingincreasingcriticism,aren'twekeeping
>> 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?
> 
> Is the library willing to pay the interface casting penalty? How much is it anyway?

As it stands, array.sort always makes a virtual call to TypeInfo.compare, which itself, in the case of classes, makes a virtual call to Object.opCmp.  A template sort() function could skip the TypeInfo and go straight to Object.opCmp at the very least.  In the best case, even that call could potentially be inlined. (of course, it could always be inlined in the case of primitive types, so there's an instant win there)

>> - 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.
> 
> 
> It is only a consistency issue. When dealing with boolean types, there will always be issues and/or hacks, because everything which looks like a boolean array is expected to be bit-packed.

I would instead say that bit[] needs the axe because D doesn't need it anymore.

It's my understanding that, in the beginning, operator overloading was intentionally omitted from D because it's misused so much in C++.  In this context, bit[] and builtin AAs make perfect sense: they had to be, lest they be second-class citizens like Java containers. (methods for everything, manual boxing because there were no templates either)

Now, though, it's easily possible to implement these as simple, succinct little template classes.  The only change that pre-existing code would need is an import (unless it's done in object.d) and different declaration syntax.

D hasn't even hit 1.0, and it already has language constructs which only exist because of its history. :)

 -- andy

Hear!  Hear!  Well said, Andy.

It's a golden opportunity to clean house, while at the same time showing some exemplary benefits of D templates.


"Andy Friesen" <andy@ikagames.com> wrote in message
news:chfh34$g4i$1@digitaldaemon.com...
Ilya Minkov wrote:
> Matthew schrieb:
>
>> 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
>
>
> Not necessary IMO. Perhaps the implementation can be enhanced or some semantic changes can be brought in.

I disagree.  bit has always been the black sheep, and it probably always will.  You can't take the address of a bit, nor can you pass one by reference.  Personally, I think the fact that it can easily be implemented within D is the most compelling reason to drop it.

>> - have a serious discussion about dropping the AA built-in type
>
> That wouldn't hurt much. However, if your consern is efficiency, it shouldn't be. A compiler could be made check idiomatic cases of successive test and access, and optimize the second test on access out.

I think AAs could be removed for the same reason as bit: it's very easy to implement it using D, so why complicate the language by building it in? (further, there's the fact that the implementation requires that Object define opCmp and opEquals)

>> - remove some of the top-heavy hierarchy methods, e.g. opCmp(),
>> opEquals()
>
> Hm, perhaps... But it would make an impact on performance, wouldn't it?

Only if AAs and array.sort remain as they are.  It would be more than feasable to turn this into a performance /gain/. (more on this below)

>> 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
>> troublesomeforsome.SinceAAsaregettingincreasingcriticism,aren'twekeeping
>> 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?
>
> Is the library willing to pay the interface casting penalty? How much is it anyway?

As it stands, array.sort always makes a virtual call to TypeInfo.compare, which itself, in the case of classes, makes a virtual call to Object.opCmp.  A template sort() function could skip the TypeInfo and go straight to Object.opCmp at the very least.  In the best case, even that call could potentially be inlined. (of course, it could always be inlined in the case of primitive types, so there's an instant win there)

>> - 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.
>
>
> It is only a consistency issue. When dealing with boolean types, there will always be issues and/or hacks, because everything which looks like a boolean array is expected to be bit-packed.

I would instead say that bit[] needs the axe because D doesn't need it anymore.

It's my understanding that, in the beginning, operator overloading was intentionally omitted from D because it's misused so much in C++.  In this context, bit[] and builtin AAs make perfect sense: they had to be, lest they be second-class citizens like Java containers. (methods for everything, manual boxing because there were no templates either)

Now, though, it's easily possible to implement these as simple, succinct little template classes.  The only change that pre-existing code would need is an import (unless it's done in object.d) and different declaration syntax.

D hasn't even hit 1.0, and it already has language constructs which only exist because of its history. :)

  -- andy

In article <chfh34$g4i$1@digitaldaemon.com>, Andy Friesen says...
>
>Ilya Minkov wrote:
>> Matthew schrieb:
>> 
>>> 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
>> 
>> Not necessary IMO. Perhaps the implementation can be enhanced or some semantic changes can be brought in.
>
>I disagree.  bit has always been the black sheep, and it probably always will.  You can't take the address of a bit, nor can you pass one by reference.  Personally, I think the fact that it can easily be implemented within D is the most compelling reason to drop it.

I bet most people don't like bit because of bool. The fact that bits are not addressable is just because bytes are the smallest addressable unit. If bits were addressable I'd have to ask which bit is being addressed - and what about the addresses of the other 7 bits sharing that same address?

>>> - have a serious discussion about dropping the AA built-in type
>> 
>> That wouldn't hurt much. However, if your consern is efficiency, it shouldn't be. A compiler could be made check idiomatic cases of successive test and access, and optimize the second test on access out.
>
>I think AAs could be removed for the same reason as bit: it's very easy to implement it using D, so why complicate the language by building it in? (further, there's the fact that the implementation requires that Object define opCmp and opEquals)
>
>>> - remove some of the top-heavy hierarchy methods, e.g. opCmp(), opEquals()
>> 
>> Hm, perhaps... But it would make an impact on performance, wouldn't it?
>
>Only if AAs and array.sort remain as they are.  It would be more than feasable to turn this into a performance /gain/. (more on this below)
>
>>> 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
>>> troublesomeforsome.SinceAAsaregettingincreasingcriticism,aren'twekeeping
>>> 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?
>> 
>> Is the library willing to pay the interface casting penalty? How much is it anyway?
>
>As it stands, array.sort always makes a virtual call to TypeInfo.compare, which itself, in the case of classes, makes a virtual call to Object.opCmp.  A template sort() function could skip the TypeInfo and go straight to Object.opCmp at the very least.  In the best case, even that call could potentially be inlined. (of course, it could always be inlined in the case of primitive types, so there's an instant win there)

There isn't anything stopping the builtin AA from using templates in the implementation (at least that I can think of). Speaking abstractly anything a library can do the compiler can do, so putting it into the compiler can only improve performance and ease of use. The fact that D's AA's have different declaration syntax than template instantiation means generic programming is impacted but presumably that can be fixed by introducing some names into object.d that are aliases for the AAs.

>>> - 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.
>> 
>> It is only a consistency issue. When dealing with boolean types, there will always be issues and/or hacks, because everything which looks like a boolean array is expected to be bit-packed.
>
>I would instead say that bit[] needs the axe because D doesn't need it anymore.
>
>It's my understanding that, in the beginning, operator overloading was intentionally omitted from D because it's misused so much in C++.  In this context, bit[] and builtin AAs make perfect sense: they had to be, lest they be second-class citizens like Java containers. (methods for everything, manual boxing because there were no templates either)
>
>Now, though, it's easily possible to implement these as simple, succinct little template classes.  The only change that pre-existing code would need is an import (unless it's done in object.d) and different declaration syntax.
>
>D hasn't even hit 1.0, and it already has language constructs which only exist because of its history. :)
>
>  -- andy

Ben Hinkle schrieb:

> I bet most people don't like bit because of bool. The fact that bits are not
> addressable is just because bytes are the smallest addressable unit. If bits
> were addressable I'd have to ask which bit is being addressed - and what about
> the addresses of the other 7 bits sharing that same address?

This simply means that bits requiere a completely separate infrastructure of the following:

* bit as a boolean type. Can be placed in a byte or int or whatever.
* bit pointer type - consisiting of byte pointer and additional 3 bits offset.
* bit array struct - conceptually consisting of 2 bit pointers for beginning and end. This may also be bit pointer and length, perhaps the range of length can even be limited to save space.

This is how it was intended to be implemented. Walter probably just doesn't have enough hands to do so. The latter 2 of these types would not work by the usual DMD types implementation (as now), but simply map separate to corresponding syntaxes. There's probably nothing fancy about it, it just takes some time and power to implement, and the current "implementation" is just a quick hack. The implementation itself can be in the library, the compiler would only have to translate the syntax.

The current implementation may not stay as it is, but discarding the good idea just because the implementation is not there yet would be a great pity. And Andy, please don't place any bets on bits staying crippled: they are not crippled by the spec, and you don't want them to be, do you?

> There isn't anything stopping the builtin AA from using templates in the
> implementation (at least that I can think of). Speaking abstractly anything a
> library can do the compiler can do, so putting it into the compiler can only
> improve performance and ease of use. The fact that D's AA's have different
> declaration syntax than template instantiation means generic programming is
> impacted but presumably that can be fixed by introducing some names into
> object.d that are aliases for the AAs.

Very true. Refining a built-in implementation may ultimately result in less codebloat and/or higher performance than the rigid template library.

-eye