[Nickle]Union values
Keith Packard
nickle@nickle.org
Fri, 26 Jul 2002 14:39:01 -0700
Around 21 o'clock on Jul 26, Carl Worth wrote:
> That's not as obvious to me. Maybe I'm just slow to grasp new syntax,
> but I can't help but reading this as a function call every time I look
> at:
>
> > x = u.i (10)
Hmm. Yes, it does seem a bit ambiguous. However, in one sense, you are
invoking a constructor which takes an argument (10) and returns a value
(the union with i = 10).
What could be legal is:
(u) { i = 10 }
That is more symmetrical with other composite initializers. Unions aren't
currently accepted there as they aren't "composite" datatypes like arrays
or structures.
> It seems potentially confusing to have a "switch" that falls through
> and a "union switch" that does not.
Union switch *does* fall through, but it's an error to fall into a case
block which has a local value for the case variable:
union switch (x) {
case i ivalue:
printf ("%d\n", ivalue);
break;
case r rvalue:
printf ("%d\n", rvalue);
}
This is legal while the same code without the 'break' will generate a
compile error. I've added code to do reachability analysis to perform
this particular check.
> It would be another departure from C, but one option would be to make
> the "switch" not fall through either. In that case, new syntax for an
> explicit fall-through could also be provided. (Some might argue that
> this would be fixing something that is broken in C anyway).
Yes, C is broken. But, I'd like to leave this particular piece of history
alone; you either need a "fallthrough" statement or "break", and
"fallthrough" isn't enough better to be different.
> Yes, unions are looking very appealing now. I don't see any problem
> eliminating NULL pointers in favor of unions with void
> members. Functions that return straight pointers will be so much more
> reliable this way.
Ok, I'll go ahead and make that change as well.
> Thanks for the example list implementation.
That was quite fun.
Keith Packard XFree86 Core Team HP Cambridge Research Lab