Question about D's quantum-esque type system

[nobody]

Sean Kelly wrote:
> nobody wrote:
>> It is my understanding that only structs guarantee you an order of the 
>> fields you define while not allowing constructors. Which means whether 
>> you want to initialize the fields via static struct building functions 
>> or member functions you have no assurance the struct fields hold 
>> meaningful data unless by happenstance you have a situation in which 
>> the default values of the fields can be creatively used to get a 
>> freshly initialized struct to be meaningful.
> 
> For what it's worth, you can specify a default value for struct members, 
> you just can't supply a this() function:

Thanks for your reply. D's default initialization was part of what I had in mind 
when I suggested structs might sometimes be given sensible default values. I do 
appreciate that you pointed that out in case I had missed it. The most frequent 
case of grief on my part is getting arrays initialized in structs. Changing 
default valued member fields is no problem. Allocating arrays twice is not 
generally the sort of thing you want to have to do twice. The only sane default 
seems to be null.

So now no matter how many functions you have to test for initialization in each. 
The ones that really hurt are opIndex and opIndexAssign which are almost 
certainly going to be down in the deepest loops.

>> However, classes allow a constructor but at the loss of any guarantee 
>> of the order of the fields. So you can be sure your initialized class 
>> starts out with meaningful values but you cannot map the class 
>> instance directly onto some data structure in memory nor can a class 
>> instance imitate a data structure.
> 
> I'll admit I'm a bit disappointed that my .isizeof proposal was ignored, 
> as it would have been nice to be able to construct class instances into 
> static buffers.  I would be surprised if member order were not 
> guaranteed (though a more compact layout may be possible if the compiler 
> could rearrange data), but offset is obviously affected by data in any 
> parent classes.
> 

http://www.digitalmars.com/d/class.html fields section says

   "The D compiler is free to rearrange the order of fields in a class to
   optimally pack them in an implementation-defined manner."

Implementation-defined seems to be more about aligning everything for fast acess 
instead of compaction. The first 8 bytes of a TGA file represent 6 fields with 
sizes (in order) <1, 1, 1, 2, 2, 1>. Even structs are 8 byte aligned by default 
and so will move fields around for maximal alignment without specifically using 
align.

However, I take your point that even with order guaranteed it would be difficult 
to get a class instance's fields mapped onto a random memory location. Certainly 
.isizeof sounds like it might have helped.