Re: [sv-bc] Union assignment patterns

I'd missed that sentence! (About first union member
being its "archetype".)

I think the "packed" vs "unpacked" distinction is
a hold-over from the days before assignment patterns.
Back then union packed {...} foo = {4'b0};  looked
ambiguous, and we would say what we say today: this is
a concatenation being assigned to a packed object, so
the whole thing converts to an integral assignment,
much as it would if foo was a packed struct.

But of course it provides a perfectly fine
arbitrary rule for how to treat a positional
assignment pattern being assigned to a union.
It is almost the same as C1 in my proposal.
So there's a compatibility bias in that direction.

When the union embraces several distinct "strong"
data types, you can do better though. Use the
type of the value to find the matching field(s)
and make that assignment.

This is equally helpful in a LHS assignment pattern.
If V is declared with a type that matches one of
the union alternatives, then '{V} = foo  should have
no problem fetching from the "right" field of
union foo.

It's not that I'm so motivated to get the very
best definition for unions... I'm trying to reduce
the union case to the previously solved problem
of how we handle structs, so that all the complex
code built to treat that case sensibly can be
used more or less directly to treat unions.
The objective is to get the SAME rich complex
treatment for unions as we already specify for
structs, not to come up with some utopian plan
custom designed for unions.  My guess is that
the same traversal works for both, perhaps
with an early exit in the union case.

Greg


Brad Pierce wrote:
>>>What about packed union types?
>>
>>Why the semantics will be different for the packed union types?
> 
> 
> That's exactly what I was asking.  Why does the LRM single out unpacked
> union types in the sentence I quoted, and where does it define the
> initialization of packed union types?
> 
> -- Brad
> 
> 
>