Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!pacbell!ptsfa!ames!ucsd!sdcsvax!ucsdhub!hp-sdd!hplabs!hpda!hpcupt1!hpisod2!decot
From: decot@hpisod2.HP.COM (Dave Decot)
Newsgroups: comp.lang.c
Subject: Re: The D Programming Language (was: Still more new operators)
Message-ID: <2550054@hpisod2.HP.COM>
Date: 7 Mar 88 07:32:03 GMT
References: <11702@brl-adm.ARPA>
Organization: Hewlett Packard, Cupertino
Lines: 32

> Dave Decot (decot@hpisod2.HP.COM) writes:
> > The basic ideas are that "a[]" is an array lvalue...
> 
> The a[] syntax isn't needed...
> 
>     int thing(i, a, b)[2]
>     int i, a[2], b[2];
>     {
>        int val[2];
> 	...
>        return val;
>     }
> 
> Since the type to be returned is int[2], the value "val" is left as an
> int[2] type item and not converted to int *.

This sounds great; I like the idea that it's possible for the intuitive
array name to refer to the whole array.

However, the meaning of function calls containing array names would
depend so heavily on the declarations of the arguments,
and the fact that it is unworkable without ANSI strong typing,
makes me still lean toward having an explicit way to request what
I want to happen.  Perhaps this would be desirable for no other
reason than to allow cc or lint to catch misuses.

For instance, I'm not sure how to tell varargs functions whether
I'm talking about an array pointer or a whole array if the name
might mean either.

Dave Decot
hpda!decot