Fixing C's Biggest Mistake

[H. S. Teoh]

On Fri, Jan 06, 2023 at 01:43:33PM +0000, Patrick Schluter via Digitalmars-d wrote:
> On Thursday, 5 January 2023 at 23:09:43 UTC, H. S. Teoh wrote:
[...]
> > 	int[100] x = [ 2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41,
> > 		43, 47, 53, 59, 61, 67, 71, 73, 79, 83, 89, 97, 101,
> > 		103, 107, 109, 113, 127, 131, 137, 139, 149, 151, 157,
> > 		163, 167, 173, 179, 181, 191, 193, 197, 199, 211, 223,
> > 		227, 229, 233, 239, 241, 251, 257, 263, 269, 271, 277,
> > 		281, 283, 293, 307, 311, 313, 317, 331, 337, 347, 349,
> > 		353, 359, 367, 373, 379, 383, 389, 397, 401, 409, 419,
> > 		421, 431, 433, 439, 443, 449, 457, 461, 463, 467, 479,
> > 		487, 491, 499, 503, 509, 521, 523, 541 ];
[...]
> The annoying and shameful thing about this static array size
> auto-determination is that it is a feature that even K&R C was able to
> provide. We will probably see men on the Moon again before D is able
> to do it ;-)

LOL... it's *really* time to push that DIP through to the end. I vote
for either `int[$]` or `int[auto]`.

Syntactically I prefer the former, but upon more careful consideration
the latter might be more bulletproof, because conceivably, in some
far-fetched scenario where you might construct a static array inside an
index expression where $ may be bound to the length of the outer array,
$ could prove to be ambiguous:

	// REALLY contrived case that probably won't happen in real life
	int[] outerArray = [ 1, 2, 3, 4, 5 ];
	outerArray[{
		// Does $ here refer to outerArray.length (5) or the length
		// of the initializer (3)?
		size_t[$] indices = [ 0, 1, 2 ];
		return indices[1];
	}()] = 0;

I don't remember now whether $ is carried over into a function literal
subexpression, but if it does, the above example would probably cause a
compile error.  Using `auto` eliminates this potential ambiguity.


T

-- 
Маленькие детки - маленькие бедки.