May 16, 2008
Janice Caron wrote:
> On 16/05/2008, BCS <ao@pathlink.com> wrote:
>>>> Bools are bytes, while ints are 4 bytes, so sometimes ints are
>>>> managed faster.
>>>>
>>> So why not just make bool a 4-byte value?  Using an integer to
>>> represent a boolean operation is just silly.
>>  Or pad them to 4 bytes where you can (local variable).
> 
> Honestly, I think I would be happy with a four-byte bool, in almost
> all circumstances.
> 
> For those rare cases where space is an issue, there could be a second
> type, bool8, implicitly castable to and from bool, but you wouldn't
> use that by default; you'd only use it in structs where you needed to
> pack stuff tight.

Instead of having a separate type, why not just use a (u)byte in those cases? That's gotta be rarer than the cases where you'd want to use an int for a bool, so while it's the same problem, the incidence of the problem is reduced while not adding yet another data type that may be unclear for new users
May 16, 2008
On 16/05/2008, Robert Fraser <fraserofthenight@gmail.com> wrote:
>  Instead of having a separate type, why not just use a (u)byte in those
> cases? That's gotta be rarer than the cases where you'd want to use an int
> for a bool, so while it's the same problem, the incidence of the problem is
> reduced

Fair enough.

OK, let's just keep it simple. Let bools be int-sized, and let opEquals return bool.
May 16, 2008
Janice Caron schrieb:

> OK, let's just keep it simple. Let bools be int-sized, and let
> opEquals return bool.

Hehe, changing the size of an existing integral type. That is going to be fun :)

However, i really think opEquals should be bool. int as return type is ugly and simply feels wrong.
1 2
Next ›   Last »