[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