[LLVMdev] [PATCH] - Union types, attempt 2

[Dustin Laurence]

On 01/15/2010 09:44 PM, Nick Lewycky wrote:
> Dustin Laurence wrote:

>> ...Isn't a union basically just a convenient alternate
>> interface to the various other conversion operators like bitcast,
>> inttoptr, trunc, zext, and the rest?
>
> Almost, but you're forgetting one important attribute: you can 'alloca'
> a union type and get something the size of the largest entry. This way,
> you can allocate a union of {i32, i8} and i8* without knowing in your
> frontend whether your system has 32 or 64-bit pointers. This is
> important to people who want to write fully platform neutral code in LLVM.

OK, but how does ordering an unordered "bag of alternatives" help that? 
  I wasn't trying to imply that union wasn't useful because you could 
just use the other conversions, though I see I worded it so it sounds 
that way.  I just meant that the instructions for conversions seemed 
like a better model for manipulating unions than structures.  I suspect 
it is C syntax that makes us think of structs and unions together, and I 
was trying to defeat my own tendency to do that by using a different model.

The last time I felt like checking my little lisp code with it's numbers 
stuffed into pairs of pointer-sized words would build on either 32 or 
64-bit x86.  But I commited some sins to more or less eliminate word 
size dependence, at least sins against taste.  Reducing the temptation 
to such sin seems worthwhile. :-)

Dustin