On Thursday, 5 January 2023 at 23:09:43 UTC, H. S. Teoh wrote:
>
> It's not so much about counting, it's about maintainability / mutability of the code.  For example, if you had a long static array like this:
>
> 	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 ];
>

I'd write that like this ;-)

int[0] 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 ];

>Error: mismatched array lengths, 0 and 100

..let the compiler count them ;-)

On Thursday, 5 January 2023 at 20:53:55 UTC, Dibyendu Majumdar wrote:
> Dennis Ritchie proposed fat pointers for C in 1990.
>
> https://github.com/kenmartin-unix/UnixDocs/blob/master/VaribleSized_Arrays_in_C.pdf

As per his proposal, I too like using the question mark for this: [?]

I'd be happy if C had this now (and I'm a 'big fan' of NOT changing the standard).

But if Dennis (RIP) could not get it into the Standard, then that tells you just how resistant to change, the C language is (and a good thing IMO, for the C language anyway).

Surely D could use int[?] also. I mean, it's 'contexually obvious' what is intended here, despite the ? being used for other purposes in the language.

It's not the dual use of ?, but the context in which its being used that matters.

int[?] arr = [0,1,2];  // perfect! IMO

On Friday, 6 January 2023 at 02:51:07 UTC, areYouSureAboutThat wrote:
> int[?] arr = [0,1,2];  // perfect! IMO

int[auto] = [0,1,2];

On Friday, 6 January 2023 at 11:35:46 UTC, RTM wrote:
> On Friday, 6 January 2023 at 02:51:07 UTC, areYouSureAboutThat wrote:
>> int[?] arr = [0,1,2];  // perfect! IMO
> int[auto] = [0,1,2];

Sorry)

int[auto] arr = [0,1,2];

On Thursday, 5 January 2023 at 23:09:43 UTC, H. S. Teoh wrote:
> On Thu, Jan 05, 2023 at 10:35:37PM +0000, areYouSureAboutThat via Digitalmars-d wrote: [...]
>> to be honest, I've never needed a static array in D.
>
> :-D  I haven't really used static arrays very much myself, but occasionally they're useful.  E.g. in one project where I use a lot of 4-element int arrays, using static arrays for them reduces a lot of GC pressure, and also gives me nice by-value semantics (useful in certain contexts).
>
>
> [...]
>> in the meantime.. this is hardly .. hard:
>> 
>> auto myStaticArray = [0, 1].staticArray;
>> 
>> int[2] myStaticArray = [0, 1].staticArray;
>> 
>> people can still count.. can't they?
>
> It's not so much about counting, it's about maintainability / mutability of the code.  For example, if you had a long static array like this:
>
> 	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 ];
>
> if one day you decide that some elements have to be added/removed from this array (based on some arbitrary criteria), then you have to recount and update the length, which, for a long array, isn't a trivial effort. It's also not very DRY; the compiler can already figure this out for you, so why make the programmer repeat the same work?
>
> Note that static arrays isn't just arrays of numbers, it could potentially be an array of some aggregate type with complex initializers that makes it annoying to have to recount every time you update it.

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 ;-)

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

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

On 1/5/2023 2:25 PM, cc wrote:
> On Sunday, 1 January 2023 at 20:04:13 UTC, Walter Bright wrote:
>> On 12/31/2022 10:33 AM, monkyyy wrote:
>>> When adr is making a video game on stream and defines a vec2 with default initialized floats; it's a video game it should be fail-safe and init to 0 rather than have him take 10 minutes on stage debugging it. Different situations can call for different solutions, why is safety within computer science universally without context?
>>
>> You're right that a video game need not care about correctness or corruption.
> 
> I don't think that's a very apt take *at all*.  Frankly it's insulting.  You do realize video games are a *business*, right? They absolutely care about correctness and corruption.

Sorry I made it sound that way. Nobody is going to die if the display is a bit off. And the reason video game developers asked for D to support half-floats is because of speed, not accuracy. (It's in the Sargon library now.)

John Carmack famously used the fast inverse square root algorithm that was faster, but less accurate, than the usual method.

https://en.wikipedia.org/wiki/Fast_inverse_square_root

That said, I believe you when you say you care about this. I believe you want very much to have your programs be correct. Which is great! I'm certainly not going to try and talk you out of that. I posit that NaN initialization is a good path to get there. It's the whole reason for it. I'm not even sure why we're debating it!


> On this specific issue, it so happens that developers also tend to find it very useful and common for numeric types to initialize to zero (when they are initialized at all).  Which is why they find it very *surprising* and *confusing* when they suddenly don't.  This should not be interpreted to mean that their industry is lazy and "doesn't care" about the financial viability of releasing sound code.

1.0 is also a popular initial value. The compiler is never going to reliably guess it right.

Suppose 1.3 was what it was supposed to be. Does initialization to 0.0 make the program more or less likely to be correct than if it was initialized with NaN? I think we can agree that the program is wrong under both scenarios. But which program is more *likely* to produce an error in the output that cannot be ignored?

I propose the NaN initialization would make the error much more obvious, and so fixable before release.

On Friday, 30 December 2022 at 20:38:52 UTC, Walter Bright wrote:
> Fast forward to today. LastPass, which is what he was relying on, failed. Now all his hundreds of passwords are compromised.

Nope. That's not how LastPass (and password managers in general) work.

-Steve

On Sunday, 8 January 2023 at 21:53:32 UTC, Steven Schveighoffer wrote:
> Nope. That's not how LastPass (and password managers in general) work.

https://en.m.wikipedia.org/wiki/LastPass#2022_security_incidents

It’s serious.