OT: Leaving Rust gamedev after 3 years

[Bruce Carneal]

On Monday, 29 April 2024 at 19:22:54 UTC, claptrap wrote:
> On Monday, 29 April 2024 at 12:04:00 UTC, Bruce Carneal wrote:
>> 
>>
>> If you live in a world where no one checks for NaN at any 
>> point at any time and/or where a default zero will never hide 
>> an error then yep, you're gonna dislike NaN init.
>
> If you're converting float to int, which is essentially all the 
> time for a software rendering, then NaNs usually end up as 
> 0xFFFFFFFF, which is no better than zero.

Yes, if you transform away from FP you either check beforehand or 
lose any benefit.

>
> And you literally dont want to litter the fast path with NaN 
> checks. You probably could do with asserts but it'd be far more 
> useful to just get a compiler error on uninitialised floats.

Yeah.  I don't think anyone does NaN checks in the fast path 
(unless they're trying to locate the index of some NaN after 
being alerted with a less localized NaN).  NaN being designed to 
be sticky/cumulative helps.

>
> I mean if the whole argument is default init to NaN helps catch 
> uninitialized variables, there's a far more effective solution. 
> That would **actually** be useful.
>
> Default init to NaN is not useful, its not worse than zero, but 
> it's not better. And you might actual want to init to zero 
> sometimes.

It may not be useful to you, sure, but it is useful to others.

I would join the zero-init contingent if I never planned on using 
NaN, not even as a weakened backstop in unit testing; if I exited 
the FP domain before getting any use of it, say, or if all my 
programs worked correctly with zero init (or at least I *thought* 
they did) or ...?

Also, as noted earlier, people weigh the pros and cons 
differently.  As for me, I'm happy that we have NaN init.