Walter,

is there a reason why
`char[][] myFunc( out bit eol );` or `char[][] myFunc( inout bit eol );`
are not allowed ?
`builder.d(30): cannot have out parameter of type bit`

Mike.

It seems to me that the compiler could automatically generate the glue code needed to support out, and even inout if you're willing to bend the semantics a little bit in the case of packed bits.  (other threads wouldn't see the updates until the function returns).  Some care would have to be taken to disallow storing of references to the temporary bit proxy.

I totally fail to see the rationale behind not allowing isolated bits to be referenced with out.  Bit is the closest thing we have in D to a C++ bool type, and references to bool were quite handy in C++.

Admittedly the restriction makes a D implementation a bit easier to write, but that shouldn't be the sole criteria for a language feature.  I hate special cases.

At very least I would like to see support in D for out and inout parameters of type bit, but disallow passing of a packed bit into such a parameter.

Sean

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:at0bfg$5v0$1@digitaldaemon.com...
> Walter,
>
> is there a reason why
> `char[][] myFunc( out bit eol );` or `char[][] myFunc( inout bit eol );`
> are not allowed ?
> `builder.d(30): cannot have out parameter of type bit`
>
> Mike.
>
>

It's because a pointer can't point to a bit. A bit pointer would have to be a two word quantity (address + bit number), meaning it's a lot of work to implement. There's no reason it can't be done, it just isn't at the moment.

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:at0bfg$5v0$1@digitaldaemon.com...
> Walter,
>
> is there a reason why
> `char[][] myFunc( out bit eol );` or `char[][] myFunc( inout bit eol );`
> are not allowed ?
> `builder.d(30): cannot have out parameter of type bit`
>
> Mike.
>
>

can we have a boolean type then which is implemented as an int (well single
stack slot) so it can be passed by reference.
== 0 false, !=0 true.
and can be automatically converted to a bit.

does this mean a bit only uses one bit and can be packed when passed as params or delared as locals ?

Mike.

"Walter" <walter@digitalmars.com> wrote in message news:at3jh1$1fj4$1@digitaldaemon.com...
> It's because a pointer can't point to a bit. A bit pointer would have to
be
> a two word quantity (address + bit number), meaning it's a lot of work to implement. There's no reason it can't be done, it just isn't at the
moment.
>
> "Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:at0bfg$5v0$1@digitaldaemon.com...
> > Walter,
> >
> > is there a reason why
> > `char[][] myFunc( out bit eol );` or `char[][] myFunc( inout bit eol );`
> > are not allowed ?
> > `builder.d(30): cannot have out parameter of type bit`
> >
> > Mike.
> >
> >
>
>

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:at4g56$2ec2$1@digitaldaemon.com...
> can we have a boolean type then which is implemented as an int (well
single
> stack slot) so it can be passed by reference.
> == 0 false, !=0 true.
> and can be automatically converted to a bit.

It could be done but the utility of it seems marginal.

> does this mean a bit only uses one bit and can be packed when passed as params or delared as locals ?

That would be up to the implementation.

I may not be familiar enough with the D bool stuff, but
the issue is generic anyway. Bit and bool are two different
concepts. Bit is a numerical entity which is sometimes
good to represent bools, which is a logical entity. But
sometimes not. Sometimes int is better for that purpose.
Either way, I see it a big mistake to blur bit and bool.
Blurring int and bool is an equally big mistake -- in C++
they have fixed that eventually, but as coding is translating
concepts and ideas to a formal language, coding anomalies
have been there in most languages that don't treat bool
as it should be treated: as a concept (type) on its own.

(Sorry if I'm knocking on open doors... I need a goooood
sleep now...)

Cheers,
Sab


"Walter" <walter@digitalmars.com> wrote in message news:ataf99$2uh7$1@digitaldaemon.com...
>
> "Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:at4g56$2ec2$1@digitaldaemon.com...
> > can we have a boolean type then which is implemented as an int (well
> single
> > stack slot) so it can be passed by reference.
> > == 0 false, !=0 true.
> > and can be automatically converted to a bit.
>
> It could be done but the utility of it seems marginal.
>
> > does this mean a bit only uses one bit and can be packed when passed as params or delared as locals ?
>
> That would be up to the implementation.
>
>

"Sab" <sab@neuropolis.org> wrote...
> I may not be familiar enough with the D bool stuff, but
> the issue is generic anyway. Bit and bool are two different
> concepts. Bit is a numerical entity which is sometimes
> good to represent bools, which is a logical entity. But
> sometimes not. Sometimes int is better for that purpose.
> Either way, I see it a big mistake to blur bit and bool.
> Blurring int and bool is an equally big mistake -- in C++
> they have fixed that eventually, but as coding is translating
> concepts and ideas to a formal language, coding anomalies
> have been there in most languages that don't treat bool
> as it should be treated: as a concept (type) on its own.

There were a big discussion about this, and I agree you. But Walter seems to not agre with us, so I think we won't have a boolean type in D.

What a pity.

Ciao

In article <atk0q6$sng$1@digitaldaemon.com>, Roberto Mariottini says...
>
>"Sab" <sab@neuropolis.org> wrote...
>> I may not be familiar enough with the D bool stuff, but
>> the issue is generic anyway. Bit and bool are two different
>> concepts. Bit is a numerical entity which is sometimes
>> good to represent bools, which is a logical entity. But
>> sometimes not. Sometimes int is better for that purpose.
>> Either way, I see it a big mistake to blur bit and bool.
>> Blurring int and bool is an equally big mistake -- in C++
>> they have fixed that eventually, but as coding is translating
>> concepts and ideas to a formal language, coding anomalies
>> have been there in most languages that don't treat bool
>> as it should be treated: as a concept (type) on its own.
>
>There were a big discussion about this, and I agree you. But Walter seems to not agre with us, so I think we won't have a boolean type in D.
>
>What a pity.
>
>Ciao

I agree with you. I took part in that previous discussion. Seems that Walter don't want implement new types which has the same asm level implementation as some other type. Because users don't need it? Who are we if not the users of the language?

Sandor Hojtsy

My main fear is that everyone will make their very own typedef for bool and enum for true and false, and the conflicts could cause a world of grief.

Even if there's no special low level type, at least the language should have the typedef and enums be part of the standard.  But once you have that, what makes bool powerful is when the comparison operators return bool, and bool is not implicitly convertible to int, and the if (), while (), clauses take bool.

If you ask me, having a bool type actually aids the implementor because it's the only type that can fit into a flags register bit.  While it's in the flags register it can be negated etc "for free" by changing the sense of the tests.

Sean

"hojtsy AT NOSPAM index.hu" <hojtsy_member@pathlink.com> wrote in message news:atkksj$1igt$1@digitaldaemon.com...
> I agree with you. I took part in that previous discussion. Seems that
Walter
> don't want implement new types which has the same asm level implementation
as
> some other type. Because users don't need it? Who are we if not the users
of the
> language?
>
> Sandor Hojtsy

hojtsy AT NOSPAM index.hu wrote:
> In article <atk0q6$sng$1@digitaldaemon.com>, Roberto Mariottini says...
> 
>>"Sab" <sab@neuropolis.org> wrote...
>>
>>>I may not be familiar enough with the D bool stuff, but
>>>the issue is generic anyway. Bit and bool are two different
>>>concepts. Bit is a numerical entity which is sometimes
>>>good to represent bools, which is a logical entity. But
>>>sometimes not. Sometimes int is better for that purpose.
>>>Either way, I see it a big mistake to blur bit and bool.
>>>Blurring int and bool is an equally big mistake -- in C++
>>>they have fixed that eventually, but as coding is translating
>>>concepts and ideas to a formal language, coding anomalies
>>>have been there in most languages that don't treat bool
>>>as it should be treated: as a concept (type) on its own.
>>
>>There were a big discussion about this, and I agree you.
>>But Walter seems to not agre with us, so I think we won't
>>have a boolean type in D.
> 
> I agree with you. I took part in that previous discussion. Seems that Walter
> don't want implement new types which has the same asm level implementation as
> some other type. Because users don't need it? Who are we if not the users of the
> language?

I don't want it, as it's completely redundant.  Bit is misnamed. Implicit casting to bit is disallowed; explicit casting to bit results in a logical cast, not a bitwise (this was a very recent change).  So it is, in every way but name, boolean.  We should probably change the name.

Back to the original discussion in this thread, I'd be willing to put bit pointers in DLI if Walter is willing to put them in DMD.  What current complexities exist in the frontend with dealing with that is a result of incomplete abstraction.  It'll be illegal to cast from a bit pointer to any other pointer type, of course.

Oh, this brings up something I've been needing to know a long time. Walter, what's the result of:

    bit [] x = new bit [400];
    bit [] y = x [2 .. 100];

Does y still refer to the same memory or a copied slice?