Walter Bright wrote:

> I think the basic type bit has been a failure. It's a substantial increase in the compiler and runtime complexity to support it. Nobody seems happy about bit being a boolean type. There's no reasonable way to take a pointer to a bit, meaning that out and inout bit parameters are inconsistent and kludgy.

You could always rename bit to _Bool instead... :-)

--anders

Walter Bright wrote:

>>Yes! But I have one question: what will happen to bool, will it now be an alias to int? Will we get a real bool type? (Will if and while still expect int or will they expect bool?)
> 
> I was thinking of making bool a keyword and basic type along the lines of bool in C++. 

I thought not having a boolean type was part of D's "personality".

Wonder what will be next ??? A std.string library class perhaps... :-O

--anders

"John Stoneham" <captnjameskirk@moc.oohay> wrote in message news:dt6rqj$1rk1$1@digitaldaemon.com...
> This is one thing I really like about Ada. The compiler will just not let you do ANYTHING with a type that requires any kind of implied cast.

I have no experience with Ada, but Pascal requires this too. After programming in it for a while, it just became really annoying to not have at least some implicit conversions.

One significant problem with requiring casting all over the place is that casting is a crude cudgel, and can actually reduce typesafety because it'll attempt to bash anything into anything else.

Walter Bright wrote:
> Should bit and bit[] be removed before 1.0?
+1

Walter Bright wrote:
> "John Stoneham" <captnjameskirk@moc.oohay> wrote in message news:dt6rqj$1rk1$1@digitaldaemon.com...
>> This is one thing I really like about Ada. The compiler will just not let you do ANYTHING with a type that requires any kind of implied cast.
> 
> I have no experience with Ada, but Pascal requires this too. After programming in it for a while, it just became really annoying to not have at least some implicit conversions.
> 
> One significant problem with requiring casting all over the place is that casting is a crude cudgel, and can actually reduce typesafety because it'll attempt to bash anything into anything else. 
> 
> 

Well, with Ada the solution is to allow a wide range of user-defined types and subtypes. I rarely find it necessary to cast, despite the fact that Ada is *extremely* type-safe (in fact, type safety was the main point of the language design). If you've got a type-safe language, you design your program around and with it.

For example, you can define your own type of Integer that has a range of 2 .. 11, and attempting to assign a value of 12 to a variable of your type raises an error. There is no implicit cast, even though they may both integer-based. If you attempt to assign a variable of type Integer to a variable of your new type, you get a compile error, and vise-versa. If you explicitly cast the Integer variable to your new type, you will get a runtime error is the value is outside your defined range, or a compile error if the compiler can deduce the value at compile-time.

Subtypes are a little different and allow some implicit casts. It is possible to use a subtype anywhere the type from which it is derived is used (since the subtype is by definition within the range of the base type). But trying it the other way around *does* raise an error.

I know that sounds like a complicated description (and it's not complete by any means). And at first glance it sounds limiting in what you can do. But it's really very flexible, and I can't tell you how many bugs it saved me from.

"John Stoneham" <captnjameskirk@moc.oohay> wrote in message news:dt7rj2$2lgj$1@digitaldaemon.com...
> I know that sounds like a complicated description (and it's not complete by any means). And at first glance it sounds limiting in what you can do. But it's really very flexible, and I can't tell you how many bugs it saved me from.

I believe you. My main concern, though, is that Ada has failed to gain traction in the general programming community. I don't know why this is so, but it makes me very cautious about adopting Ada style.

"Anders F Björklund" <afb@algonet.se> wrote in message news:dt75m2$243m$2@digitaldaemon.com...
> Walter Bright wrote:
>> I was thinking of making bool a keyword and basic type along the lines of bool in C++.
> I thought not having a boolean type was part of D's "personality".

Boolean was redundant to the bit type.

On Sun, 19 Feb 2006 07:39:18 +1100, Walter Bright <newshound@digitalmars.com> wrote:

>
> "Anders F Björklund" <afb@algonet.se> wrote in message
> news:dt75m2$243m$2@digitaldaemon.com...
>> Walter Bright wrote:
>>> I was thinking of making bool a keyword and basic type along the lines of
>>> bool in C++.
>> I thought not having a boolean type was part of D's "personality".
>
> Boolean was redundant to the bit type.

Wrong! That statement implies that the entire requirements of a correct 'boolean' type is met by the behaviour of the 'bit' type. And that is demonstrably incorrect.

-- 
Derek Parnell
Melbourne, Australia

Walter Bright wrote:

>>I thought not having a boolean type was part of D's "personality".
> 
> Boolean was redundant to the bit type. 

I meant the part where sometimes a "byte" was the best boolean type,
and sometimes an "int" was the best match (for speed, for instance).
Where "bit" just happened to be a default match, for the bool alias.

But I will just go with the flow, as I'm not using "raw" bit or bit[].

--anders

"Derek Parnell" <derek@psych.ward> wrote in message news:op.s46t2hmc6b8z09@ginger.vic.bigpond.net.au...
> Wrong! That statement implies that the entire requirements of a correct 'boolean' type is met by the behaviour of the 'bit' type. And that is demonstrably incorrect.

Woah, woah, woah, take it _down_ a notch, Derek!  This is a _boolean data type_ we're talking about here, not world politics!  ;)