I've just noticed that the keyword "bool" is accepted by the compiler. Turns out this is because it's defined in "object.d" as an alias for bit.

At the very least, this enables us to document our code, by having appropriate functions return bool instead of bit.

Walter, pending the implementation of a real non-arithmetic bool type, is there
any chance you could change this alias from bit to int? Then at least opEquals()
could return a bool. (Or better still, have opEquals() return bool).

Arcane Jill

agree...unless you're passing bools in bit vectors (in which case you'd probably want to document it as such esp with these bit-slicing quirks) the bool should be an int or at worst a byte on reasonably modern platforms.

Arcane Jill wrote:

> I've just noticed that the keyword "bool" is accepted by the compiler. Turns out
> this is because it's defined in "object.d" as an alias for bit.
> 
> At the very least, this enables us to document our code, by having appropriate
> functions return bool instead of bit.
> 
> Walter, pending the implementation of a real non-arithmetic bool type, is there
> any chance you could change this alias from bit to int? Then at least opEquals()
> could return a bool. (Or better still, have opEquals() return bool).
> 
> Arcane Jill
> 
> 

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:c9itp0$2dpn$1@digitaldaemon.com...
> I've just noticed that the keyword "bool" is accepted by the compiler.
Turns out
> this is because it's defined in "object.d" as an alias for bit.
>
> At the very least, this enables us to document our code, by having
appropriate
> functions return bool instead of bit.
>
> Walter, pending the implementation of a real non-arithmetic bool type, is
there
> any chance you could change this alias from bit to int? Then at least
opEquals()
> could return a bool. (Or better still, have opEquals() return bool).

I've followed the "what are the correct semantics of bool" debate for 15 years (it first reared its controversial head with the C standardization effort). There is no consensus, nobody agrees, and therefore no resolution.

The D options are:

1) use bit which has only 'true' or 'false' values
2) use int which has !0 and 0 values (the C style)
3) use bool for those who don't think that bit is self-documenting <g>

and it's going to stay that way. There's a lot of very cool stuff coming for D, and I can't wait to get it implemented. I've had as much as I can take on the whole 15 years of bool business, I've got the scars to prove it <g>.

Hear, hear. Where bool is concerned, it's more constructive to just move on ...


"Walter" <newshound@digitalmars.com> wrote in message news:c9j8jo$2t58$1@digitaldaemon.com...
>
> "Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:c9itp0$2dpn$1@digitaldaemon.com...
> > I've just noticed that the keyword "bool" is accepted by the compiler.
> Turns out
> > this is because it's defined in "object.d" as an alias for bit.
> >
> > At the very least, this enables us to document our code, by having
> appropriate
> > functions return bool instead of bit.
> >
> > Walter, pending the implementation of a real non-arithmetic bool type,
is
> there
> > any chance you could change this alias from bit to int? Then at least
> opEquals()
> > could return a bool. (Or better still, have opEquals() return bool).
>
> I've followed the "what are the correct semantics of bool" debate for 15 years (it first reared its controversial head with the C standardization effort). There is no consensus, nobody agrees, and therefore no
resolution.
>
> The D options are:
>
> 1) use bit which has only 'true' or 'false' values
> 2) use int which has !0 and 0 values (the C style)
> 3) use bool for those who don't think that bit is self-documenting <g>
>
> and it's going to stay that way. There's a lot of very cool stuff coming
for
> D, and I can't wait to get it implemented. I've had as much as I can take
on
> the whole 15 years of bool business, I've got the scars to prove it <g>.
>
>

On Tue, 1 Jun 2004 17:47:13 -0700
"Walter" <newshound@digitalmars.com> wrote:

> I've had as much as I can take on the whole 15 years of bool business, I've got the scars to prove it <g>.

Yeah, but do you have photos to prove that you've got the scars to prove it?

:o)

Dennis

>Yeah, but do you have photos to prove that you've got the scars to prove it?


Some of the scars are on his backside, I don't want to see them.

In article <c9j8jo$2t58$1@digitaldaemon.com>, Walter says...
>
>I've followed the "what are the correct semantics of bool" debate for 15 years (it first reared its controversial head with the C standardization effort). There is no consensus, nobody agrees, and therefore no resolution.
>
>The D options are:
>
>1) use bit which has only 'true' or 'false' values
>2) use int which has !0 and 0 values (the C style)
>3) use bool for those who don't think that bit is self-documenting <g>
>
>and it's going to stay that way. There's a lot of very cool stuff coming for D, and I can't wait to get it implemented. I've had as much as I can take on the whole 15 years of bool business, I've got the scars to prove it <g>.


opEquals() should return bool. Pure and simple. There is *NO* disagreement on this. Apart from yours, anyway.

I don't care what bool is aliased to. But whatever it is, opEquals should return it. The current situation where opEquals returns int, but bool is aliased to bit, is just silly. Overrides of opEquals are (currently) not allowed to return bool, and that just sucks. Particularly when both parts of this inconsistency originate from the same file (object.d).

Jill

In article <c9j8jo$2t58$1@digitaldaemon.com>, Walter says...
>
> There is no consensus, nobody agrees

This is not true. There is almost unanimous consensus on this forum, with yourself being pretty much the only dissenter.

There have been many different suggestions regarding *implementation* - and if you want to call that "no consensus" then that's your viewpoint - but regarding the principle that a bool is not arithmetic, if you have been following this forum, you'll know you are in a very small minority here.

If we have to wait until someone implements the SECOND D-compiler before we see a bool type, then so be it. But I'll bet you any amount of money you like it will be in the ISO/ANSI standard which eventually supercedes the original implementation.

I think it's a shame that you don't like the bool type, but I think it's a bigger shame that you don't see a consensus when it's staring you in the face. Unless you are defining "consensus" as "unanimous opinion" - in which case your comment "and therefore no resolution" is absurd.

Arcane Jill

Dude ... I sincerely hope you're just venting. You do make a valid point about opEquals() in your prior post but I doubt this, whatever it is, helps your cause in the slightest.

My 2 pence worth.

BTW: according to your 'handle', you appear to claim some heritage to the proverbial "Arc Angel". If so, perhaps you might consider setting a higher standard? These personal attacks are just so boring ...


"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:c9k035$v8g$1@digitaldaemon.com...
> In article <c9j8jo$2t58$1@digitaldaemon.com>, Walter says...
> >
> > There is no consensus, nobody agrees
>
> This is not true. There is almost unanimous consensus on this forum, with yourself being pretty much the only dissenter.
>
> There have been many different suggestions regarding *implementation* -
and if
> you want to call that "no consensus" then that's your viewpoint - but
regarding
> the principle that a bool is not arithmetic, if you have been following
this
> forum, you'll know you are in a very small minority here.
>
> If we have to wait until someone implements the SECOND D-compiler before
we see
> a bool type, then so be it. But I'll bet you any amount of money you like
it
> will be in the ISO/ANSI standard which eventually supercedes the original implementation.
>
> I think it's a shame that you don't like the bool type, but I think it's a bigger shame that you don't see a consensus when it's staring you in the
face.
> Unless you are defining "consensus" as "unanimous opinion" - in which case
your
> comment "and therefore no resolution" is absurd.
>
> Arcane Jill
>
>

Now I'm known to have a big mouth and thick skin, but even trying out a permeable skin for a moment I fail to see where Arcane Jill has resorted to any low tactics.

The fact is that Walter is in an almost solitary minority on the bool issue, in terms of the opinions expressed in this forum. Also, the bit/int opEquals() point is well made.

Now, Walter's been umoveable for as long as I can remember on this issue, and while I still hope that he will see the (or, at least, our) light, I don't think that's the case.

That's fair enough, it's his party after all, even though it does rankle considerably. One's choice is to stay involved, and either live with it or endeavour to change it eventually, or to find a better language. I can tell you that Walter would prefer that people with diverse opinions and experience should stay around, even if, as I'm sure we've done with "bool", it it happens to irritate the hell out of him.

For the record, I completely disagree with Walter's apparent opinion that other,
presumably more complex things, are more important. Now that doesn't mean I'm
making personal attacks or anything, just that AJ's prophecy of standards
committees needlessly raking over old ground is likely to come true, to all our
detriments. It's a shame, because I've personally had reactions from experienced
C++ (and other languages) exponents, and pretty much the first things they say
are
    - get rid of C's evil implicit conversions - which Walter's ruled out
    - make typedefs strong - which D has done. Hurrah!
    - stop bool being an integral type - which Walter's ruled out
    - make an ABI - which has so far been ignored
    - has it got libraries - which I would suggest more of us would be doing if
there was not still such fertile ground for language debates at a very
low/fundamental level
    - give me decent templates - which we're certainly working towards

So, we in our out? I'm still in. ;)



"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:c9k3ah$13fo$1@digitaldaemon.com...
> Dude ... I sincerely hope you're just venting. You do make a valid point about opEquals() in your prior post but I doubt this, whatever it is, helps your cause in the slightest.
>
> My 2 pence worth.
>
> BTW: according to your 'handle', you appear to claim some heritage to the proverbial "Arc Angel". If so, perhaps you might consider setting a higher standard? These personal attacks are just so boring ...
>
>
> "Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:c9k035$v8g$1@digitaldaemon.com...
> > In article <c9j8jo$2t58$1@digitaldaemon.com>, Walter says...
> > >
> > > There is no consensus, nobody agrees
> >
> > This is not true. There is almost unanimous consensus on this forum, with yourself being pretty much the only dissenter.
> >
> > There have been many different suggestions regarding *implementation* -
> and if
> > you want to call that "no consensus" then that's your viewpoint - but
> regarding
> > the principle that a bool is not arithmetic, if you have been following
> this
> > forum, you'll know you are in a very small minority here.
> >
> > If we have to wait until someone implements the SECOND D-compiler before
> we see
> > a bool type, then so be it. But I'll bet you any amount of money you like
> it
> > will be in the ISO/ANSI standard which eventually supercedes the original implementation.
> >
> > I think it's a shame that you don't like the bool type, but I think it's a bigger shame that you don't see a consensus when it's staring you in the
> face.
> > Unless you are defining "consensus" as "unanimous opinion" - in which case
> your
> > comment "and therefore no resolution" is absurd.
> >
> > Arcane Jill
> >
> >
>
>