On 08/19/2012 06:16 PM, Walter Bright wrote:
On 8/19/2012 1:43 PM, Chad J wrote:
So instead of writing
float f;
if (condition1)
f = 7;
... code ...
if (condition2)
++f;
is there any way we can make it easier to write
void someCode() {
... code ...
}
float f;
if ( condition )
{
f = 7;
someCode();
++f;
}
else
someCode();
assuming that condition2 is true when condition1 is true?
Yes, you can do that.
I feel like NaNs are a step forward, but better can be done. They
allow error
detection, but it's still merely runtime error detection, and worse
yet, it's
/non-local/ error detection. NaNs can spread from function to function
and end
up in completely different parts of a program than the place they
originated.
This causes debugging hell, just like null values.
I'm sorry, it's not debugging hell. I've done an awful lot of "figure
out where this null came from" and it's a bit tedious, but not hell. You
go step by step, such as "it's null in this function, so put an assert
on the callers of the function", rinse, repeat.
Yes, I also know this is more of a problem if you've got a program
that's not so easy to rerun.
Most of the programs I've worked on, be it hobby games or business apps
for pay, have been interactive stuff. Rerunning sucks. Debuggers also
interact very poorly with these things, or just plain have crappy
interfaces that make using them a legitimate pain. My productivity is
greatly improved by NOT having to do tedious busywork.
This is why I have a very low tolerance for non-local bugs and a lack of
good stacktrace info when crashing.
I'd feel /a lot/ better if corrupt data like NaNs or nulls would create
some kind of a crash or compiler error /before/ leaving the function
that created them.
IMO, this would be a huge step forward for programmer productivity. No
longer does every nan/null take like 15-30 minutes to debug, it takes 1
minute instead.
It makes me think that
non-nan-able floating point types would be very useful, at least as
function
arguments, so that calling code doesn't have to introduce extra checks
for NaNs
that are either lost cycles or forgotten entirely and bug-ridden.
You can use signalling NaNs, if you like.
How? I remember reading a lot of material on NaNs in D, but I don't
recall these.
I really wish we had a way of catching NaNs in the function or line
where they
happen, and not in completely distant parts of the code.
Nobody has even mentioned this until I brought it up, so I have a hard
time believing the current state of affairs is a terrible problem that
requires a major redesign to fix.
I doubt that preventing non-local bug propagation would require any kind
of major redesign at this point. D seems very close already.
Some kind of convenient notation for optional non-nullable (and maybe
non-nan-able?) types combined with strictly simple branching
initializations and some kind of easy-to-use sentinel values would
probably go a long way.
There seems to be a push to try and get this functionality from
user-defined types. I am skeptical that it will ever work for these
things because something like
NotNull!MyType foo( NotNull!MyType a, NotNan!float b ) { ... }
is going to be very daunting to write and read compared to something like
MyType@ foo( MyType@ a, float@ b )
which is just a notation I've seen in previous posts. Initialization
becomes a huge pain for the user-defined types too.
Not only are proxy types like "NotNull!X" far more difficult to write in
D than I would have expected, but things like non-null types and
possibly non-nan types would be so common that things will probably look
very nasty if people start using proxy types for this. I'm willing to
wait and see if these proxy types can be made though, and if they get
used a lot. I just hope their clumsiness doesn't inhibit their use. I
understand it's easier to add things in demand than it is to remove
things that are used infrequently.
I know that nobody wants to see NaNs in their results, but be assured
that that is far, far better than corrupted results that are off in
subtle ways. NaNs are also one hell of a lot easier to track backwards
than the other.
I agree that NaNs are really cool. They are definitely much better than
"f=0;". Thank you for doing this.
