"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:c9oh61$1gat$1@digitaldaemon.com...
> Hey Matthew,
>
> The title says it all, but since you asked for clarification:
>
> "Matthew"  wrote
> > If I understand you correctly, you're arguing that we should be able to
> use a
> > boolean variable in an integral expression. If that's the case, you are contradicting point 2)
> >
> > Please confirm/deny.
>
> My statement tried to be clear about this usage as an arithmetic RValue, rather than an LValue. An LValue is the target of an assignment, whereas an RValue is typically anything on the right-hand side of the '='. This doesn't contradict point 2, which is talking about the bool strictly as an LValue.

It's (mis-)use as an rvalue is, IMO, far more frequent than that of lvalue. I don't see that we buy much in prescribing one, and proscribing the other. And the downside is more confusion.

> BTW I'm not as you say, arguing point 4 per se. I'm just pointing out its history and usage. I am personally comfortable with the boolean RValue style syntax, but wouldn't cry out if it were not supported. In other words, this point is of relatively low value. I hope this clarifies suitably?

Sure.

> > Well, this is a newsgroup that, in part, is about how we will implement
> the new
> > language D. If you think we should not be looking into how things are implemented, you're in the wrong NG. Or maybe it's time for yet another
> group
> > D.users?
>
> Perhaps you are in the wrong newsgroup, good Dr ... I would put it to you that the majority of users on the NG are exactly that.

Majority is not all, and in the absence of another forum, such issues must be dealt with here.

And hey! There's nothing good about me. I've been trying to heal myself for a long time ...

> Users. I mean,
> discussing the language usage, features, limitations, restrictions, or new
> ideas are often quite a world apart from the actual underlying compiler
> implementation issues. This, you already know. Part of the problem in
> combining the two is that it causes unnecessary worry and thrashing within
> the overall group.

A very good point. New NG, big-W?

> Might you consider another group called D.internals, or D.implementation.all.in.mud.wrestling, instead? Yes ~ you've already stated how thick your skin is, so permit me some latitude here please <g>

He he. I think it could be D.implementation.endless.pontification, or D.implementation.ego.joust.

Professor Frederick von Crute

Author: "Imperfect C++", Addison-Wesley, 2004
    (http://www.imperfectcplusplus.com)
Contributing editor, C/C++ Users Journal
    (http://www.synesis.com.au/articles.html#columns)
Director, Synesis Software
    (www.synesis.com.au)
STLSoft moderator
    (http://www.stlsoft.org)

-----------------------------------------------------

> Perhaps you are in the wrong newsgroup, good Dr ... I would put it to you that the majority of users on the NG are exactly that. Users. I mean, discussing the language usage, features, limitations, restrictions, or new ideas are often quite a world apart from the actual underlying compiler implementation issues. This, you already know. Part of the problem in combining the two is that it causes unnecessary worry and thrashing within the overall group.
>
> Might you consider another group called D.internals, or D.implementation.all.in.mud.wrestling, instead? Yes ~ you've already stated how thick your skin is, so permit me some latitude here please <g>

I'm just thinking. Can you imagine when we all meet up at the inaugural ISO/ANSI-D meeting. How many of you will try and take a pop at my <translation actual="ugly mug">august countenance</translation>?

<G>

Spawning a whole new thread on it <g>.

> > Well, I kind of agree, and I kind of don't. I see the current bool
> > definition as
> > flawed, and potentially buggy.
>
> I am having a hard time thinking of a possible bug someone might write. Lets assume 2) above is changed, can you give me an example of where using a bool as an rvalue as in Walters previous examples causes a bug not caught by the compiler.

Easy:

Vector2D!(int) makeVector2D(int a, int c)
{
   void * pv = ....
    bool b = null !== pv;

  return new Vector2D!(int)(a, b); // Big f*ing ouch!!
}

>
> > While it's certainly easier to go along with
> > Walter's vision of bool, you can't exactly say that doing would be an
> > unequivocal
> > kindness to my users. If I supply something that's easier to use, but
> > more prone
> > to misuse, is that really being selfless? If I require them to add a
> > couple of
> > casts here and there in order to do something bad, is that selfish?
>
> http://www.datanation.com/fallacies/ap.htm
> (please don't take offence)

None taken. (Remember, I'm English: taking the piss out of oneself is the national sport. <g>) I'm not sure it's perfectly apposite, but I think it's funny enough to be worth a try. argumentum ad misercordiam - cool!

> > Yet again, and for the last 2 years, I sigh at the apparent preference
> > for ease
> > of coding over maintenance and robustness concerns. Pretty much every
> > master of
> > this industry - Brooks, Glass, Meyers, Sutter, Kernighan, Fowler, Hunt &
> > Thomas,
> > Raymond, etc. etc. etc. etc. ad infinitum - stresses time and again that
> > maintenance/debugging/refactoring costs dwarf the initial coding cost.
> > So leaving
> > a language, or its libraries, open to more errors than necessary for the
> > sake of
> > some dinky little trick / saving a line of code could be said to be ...
> > <searching for as inoffensive word as possible> ... wrong.
>
> Being a C programmer I am probably biased, I have seen Walters examples, I think they are clearer than the others proposed. If it is well known that bool is implicitly castable to int and has a value of 0 or 1 then I cannot see the problem.

See the example above. There are - in principle _and_ in practice - myriad others.

> It doesn't stop you from coding the casts to make your code 'clearer' regardless of whether the compiler requires it.

I'm sorry, but this is just rot. If there is a semantic type conversion
involved - and let's be clear: converting from a bool (truth) to an int (numeric)
*is* a semantic type conversion - then the code is not rendered less clear by
requiring a cast to inform the reader.

Once again, this peurile bias for ease of coding over than ease of maintenance flashes it's cheeky little grin. Casts are ugly, and make your code look messy. Yes, indeed; that's precisely the point. Bjarne Stroustrup indicates that he chose the C++ cast names for that very reason. When you look at code with casts in it, warnings bells *should* ring in your head. With syntax highlighting (whether for C++'s "static_cast" or D's "cast"), this is a significant boon to code maintainers.

You've offered up your C heritage/experience, so I am compelled to ascribe what I see as naivety to that. C programmers are used to all casts being equal, and to casts being a normal part of life. They are not thus viewed in other languages, and for good reason.

> > Or maybe it's just me, and I shouldn't want D to address the abject, and
> > multi-billion-dollar wasteful, failures of other languages, and end up
> > being a
> > roaring success. Let's just have it as a partial, buggy, semi-cool thing
> > for
> > hobbyists and people who want to spend their time in debuggers. :(
>
> http://www.datanation.com/fallacies/conseq.htm
> (please don't take offence)

You're off base here, I'm afraid. But I acknowledge your willingness to try and get two laughs out of the same joke.

Each of the established languages has advantages over the others. For D to score market share, it needs to have new features that others do not have, and at the same time not have sufficient level of existing/new warts that it renders these advantages moot. Given that D does not have a huge corporate backer, it's going to have to try harder than the others. Can anyone really see themselves selling a new, unsponsored, language to a client/boss on the basis of mixins and similarly groovy but inaccessible concepts when it hasn't even got the fundamentals right?

On Fri, 4 Jun 2004 13:33:36 +1000, Matthew <matthew.hat@stlsoft.dot.org> wrote:
>> > Well, I kind of agree, and I kind of don't. I see the current bool
>> > definition as
>> > flawed, and potentially buggy.
>>
>> I am having a hard time thinking of a possible bug someone might write.
>> Lets assume 2) above is changed, can you give me an example of where using
>> a bool as an rvalue as in Walters previous examples causes a bug not
>> caught by the compiler.
>
> Easy:
>
> Vector2D!(int) makeVector2D(int a, int c)
> {
>    void * pv = ....
>     bool b = null !== pv;
>
>   return new Vector2D!(int)(a, b); // Big f*ing ouch!!
> }

Thanks.

I don't think this example would ever occur in a real world application.

I mean.. C doesn't have bool, so I cannot say 'I have or have not ever come accross a bug like this'. BUT. I can say I have *never* accidently passed an int I was using as a bool to a function that required an int.

That is why I am having trouble coming up with a bug, that removing implicit casting from bool to int would have prevented.

>> > While it's certainly easier to go along with
>> > Walter's vision of bool, you can't exactly say that doing would be an
>> > unequivocal
>> > kindness to my users. If I supply something that's easier to use, but
>> > more prone
>> > to misuse, is that really being selfless? If I require them to add a
>> > couple of
>> > casts here and there in order to do something bad, is that selfish?
>>
>> http://www.datanation.com/fallacies/ap.htm
>> (please don't take offence)
>
> None taken. (Remember, I'm English: taking the piss out of oneself is the
> national sport. <g>) I'm not sure it's perfectly apposite, but I think it's funny
> enough to be worth a try. argumentum ad misercordiam - cool!
>
>> > Yet again, and for the last 2 years, I sigh at the apparent preference
>> > for ease
>> > of coding over maintenance and robustness concerns. Pretty much every
>> > master of
>> > this industry - Brooks, Glass, Meyers, Sutter, Kernighan, Fowler, 
>> Hunt &
>> > Thomas,
>> > Raymond, etc. etc. etc. etc. ad infinitum - stresses time and again 
>> that
>> > maintenance/debugging/refactoring costs dwarf the initial coding cost.
>> > So leaving
>> > a language, or its libraries, open to more errors than necessary for 
>> the
>> > sake of
>> > some dinky little trick / saving a line of code could be said to be 
>> ...
>> > <searching for as inoffensive word as possible> ... wrong.
>>
>> Being a C programmer I am probably biased, I have seen Walters examples, I
>> think they are clearer than the others proposed. If it is well known that
>> bool is implicitly castable to int and has a value of 0 or 1 then I cannot
>> see the problem.
>
> See the example above. There are - in principle _and_ in practice - myriad
> others.

I just want 1 real world example, has anyone got one, surely someone has an actual bug they found and fixed that involved implicit casting from bool to int?

>> It doesn't stop you from coding the casts to make your code 'clearer'
>> regardless of whether the compiler requires it.
>
> I'm sorry, but this is just rot.

Why? You can can't you. And it will document your code for others to see. Where's the problem?

> If there is a semantic type conversion
> involved - and let's be clear: converting from a bool (truth) to an int (numeric)
> *is* a semantic type conversion

No-one is arguing this point.

> - then the code is not rendered less clear by
> requiring a cast to inform the reader.

Never said it was.

> Once again, this peurile bias for ease of coding over than ease of maintenance
> flashes it's cheeky little grin. Casts are ugly, and make your code look messy.

Yep. They make code harder to read next time you come back to it.

> Yes, indeed; that's precisely the point. Bjarne Stroustrup indicates that he
> chose the C++ cast names for that very reason. When you look at code with casts
> in it, warnings bells *should* ring in your head. With syntax highlighting
> (whether for C++'s "static_cast" or D's "cast"), this is a significant boon to
> code maintainers.

I dislike them, they're ugly. :)

> You've offered up your C heritage/experience, so I am compelled to ascribe what I
> see as naivety to that. C programmers are used to all casts being equal, and to
> casts being a normal part of life. They are not thus viewed in other languages,
> and for good reason.

There is nothing wrong with casts... I thought you were arguing implicit casting is bad, are all casts bad now?

>> > Or maybe it's just me, and I shouldn't want D to address the abject, 
>> and
>> > multi-billion-dollar wasteful, failures of other languages, and end up
>> > being a
>> > roaring success. Let's just have it as a partial, buggy, semi-cool 
>> thing
>> > for
>> > hobbyists and people who want to spend their time in debuggers. :(
>>
>> http://www.datanation.com/fallacies/conseq.htm
>> (please don't take offence)
>
> You're off base here, I'm afraid.

How? You were arguing *for* something by detailing some supposed consequences and *implying* they would occur if you are ignored.

> But I acknowledge your willingness to try and
> get two laughs out of the same joke.
>
> Each of the established languages has advantages over the others. For D to score
> market share, it needs to have new features that others do not have, and at the
> same time not have sufficient level of existing/new warts that it renders these
> advantages moot. Given that D does not have a huge corporate backer, it's going
> to have to try harder than the others. Can anyone really see themselves selling a
> new, unsponsored, language to a client/boss on the basis of mixins and similarly
> groovy but inaccessible concepts when it hasn't even got the fundamentals right?

So now you're saying D will never survive if it implicitly casts bool to int?
C++ does. it's doing pretty well.

D already has advantages over C++ and has not added any flaws (that do not exist in C++ already)

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

"Walter" <newshound@digitalmars.com> wrote in message news:c9ok5p$1k7i$2@digitaldaemon.com...
>
> Spawning a whole new thread on it <g>.

Maybe the new NG should be called
"D Bool"

I dont care what anyone says, I say that bool
should return one of three values:

"true", "false" and "Im not sure"

Phill.

In article <c9ur8o$1l21$1@digitaldaemon.com>, Phill says...

>I dont care what anyone says, I say that bool
>should return one of three values:
>
>"true", "false" and "Im not sure"

The function Int.isProbablyPrime() does just that, although actually I just returned an int. I keep wondering if I should have invented a three-valued enum.

Arcane Jill

How about defining bool as a float being a probability in range [0.0 ..1.0] :-)

"Phill" <phill@pacific.net.au> wrote in message news:c9ur8o$1l21$1@digitaldaemon.com...
>
> "Walter" <newshound@digitalmars.com> wrote in message news:c9ok5p$1k7i$2@digitaldaemon.com...
> >
> > Spawning a whole new thread on it <g>.
>
> Maybe the new NG should be called
> "D Bool"
>
> I dont care what anyone says, I say that bool
> should return one of three values:
>
> "true", "false" and "Im not sure"
>
> Phill.
>
>

"Arcane Jill" wrote...
> In article <c9ur8o$1l21$1@digitaldaemon.com>, Phill says...
>
> >I dont care what anyone says, I say that bool
> >should return one of three values:
> >
> >"true", "false" and "Im not sure"
>
> The function Int.isProbablyPrime() does just that, although actually I just returned an int. I keep wondering if I should have invented a three-valued enum.
>
> Arcane Jill
>

Have an Int.isPrime() that implements AKS maybe ? That way, you wouldn't
need to invent a three-valued enum :-)

KTC

-- 
Experience is a good school but the fees are high.
    - Heinrich Heine