I'd wondered about this, at least as far as mutable between byte and processor-sized-int, and I like it conceptually - though only for bool type - but would bet a lot of cash that Walter will suggest it is too hard for implementation to be worth it.

The offsetof() seems interesting, but then I wonder if we'll end up like the feature-bloated .NET languages where there are compiler layouts and various other attribute-based layout schemes. (Maybe we're there already ??)


"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bek61g$29q2$1@digitaldaemon.com...
> bool is one of those types (like int) that should be defined by its semantics and not by its implementation details.  You won't get any guarantees about how big a bool is.  It could be a bit, a byte, or an int. It could in fact not live in memory but in a processor flags register.
But
> it seems important to be able to have pointers to them, send them as inout parameters, etc.  To do that, the compiler may need to temporarily move
the
> value somewhere that can be referenced easier (a byte in memory) and then move it back when the reference is no longer necessary.  Since you can
pass
> addresses around willy-nilly in D, this can get a programmer in big
trouble,
> and means the compiler is severely constrained in what it is allowed to do without breaking language semantics.
>
> bit is more like int32; it is saying exactly the storage requirement for
the
> value.  A cheap D compiler could use a byte to hold a bit if it wants to, though.  It also seems pretty important to be able to have pointers to
bits.
> A bit pointer however is unlike a normal pointer in that it must specify which bit in the containing byte it is actually pointing to.  This would need special compiler support, and Walter doesn't seem interested in
making
> this effort at this time.  Has many more important things that need doing, apparently.  ;)
>
> One thing that could be done to alleviate the problem somewhat would be
that
> local, class, and global scope variables have *no* defined ordering or
size,
> and thus you can't determine the address of a variable merely by looking
at
> the class declaration and knowing a pointer to the class,  you'd have to
use
> offsetof(x).  With the language semantics so altered, it would be possible to take the address of a local variable bit or bool, which would let the compiler store it as a byte instead of a bit.  Taking the address of bits stored in structs or arrays could wait until Walter makes fat bit
pointers.
>
> Sean
>
> "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:beid7m$jh2$1@digitaldaemon.com...
> > Sorry, your explanation makes no sense. Can you expound?
> >
> > btw, am now wondering whether int is better than byte. It's a trade off
of
> > efficiencies, whether storage (as in arrays/containers of bool) vs
> function
> > returns and the painful/wasteful testing against 0 to convert to
> true/false.
> >
> > "Ilya Minkov" <midiclub@8ung.at> wrote in message news:bei0i5$6ur$1@digitaldaemon.com...
> > > Matthew Wilson wrote:
> > > > typedef
> > >
> > > no, alias. or just get used to thinking in bits, which i prefer.
typedef
> > > would make lots of trouble.
> > >
> > > -i.
>
>