Forbid Inversion of Integers and similar operations

[X.]

LabVIEW is well-known for being a safe yet powerful programming environment (no pointer violation, no crash for failure to allocate memory, no need for a 64 bit version, etc), but unfortunately, it still allows the careless programmer to perform invalid operations.

I suggest that, in the same way that taking the absolute value of an unsigned integer is forbidden (as well, of course as its negative value), taking the inverse of an integer (be it unsigned or not) be forbidden.

In short, we should be warned like this:

Considering that there are very few perfect squares among integers (not mentioning I32 for which this should be totally forbidden), I would also suggest preventing taking the square root of integers (and completely banning integer from all special functions), like this:

This (and many similar interdictions), would force a careful attitude from the programmer, who would need to write proper code such as this:

 

Edit: In fact, after reflection, I think the invert function is way too dangerous and should be banned altogether, considering that its argument can be equal to zero. Same thing for the square root function, since there is about a 50% chance that its argument will be negative.

[AristosQueue (NI)]

The reason that inversion is forbidden on unsigned integers is that there is no way to modify the type to handle all the integer cases and stay with its current size. The change of integer types is easy to miss.

But the change to double is much harder to miss because of the color change. The math operations are hardly "invalid". They're well-defined, and just because the integer isn't a perfect square doesn't mean it doesn't have a square root. Same for inversion.

The code today includes a coercion dot:

It also changes the output to double. I don't think anyone is going to miss that this is an operation on the double value. And VI Analyzer tests check for coercion dots.

I think this idea is just creating barriers to getting work done with very little safety added, if any.

[TomOrr0W]

AristosQueue, I don't think this is a serious idea to improve LabVIEW (my apologies to X if it actually is).

It instead appears to be a sarcastic complaint against certain operations (such as absolute value and negate) with unsigned integers breaking wires - see the forum thread X linked to in the idea post.

[X.]

This IS an extremely serious suggestion. Moreover red coercion dots are probably invisible for a significant fraction of programmers.

BTW, what is this rounded-corner-with-cheezy-shadow-effect sqrt operator? Is this what you guys have spent your time working on for LV 2016!?

[CMal]

How would you deal with the fact that this would break an enormous amount of existing user code? I also see no reason to prevent someone from taking the inverse of a number just because it's an integer. Even if you can't see the coercion dot, it is obvious that there is a conversion from integer to floating point because of the color of the output wire.

[AristosQueue (NI)]

CMal: To be fair to X's idea, the mutation is straightforward -- we'd just insert a coercion bullet "To Double" into the wire during upgrade. But just because the mutation is possible doesn't make this a good idea. It's still a pretty silly limitation on valid mathematics.

[CMal]

Ah, that's right. I always forget about mutation.

[RnDMonkey]

I, for one, would decline this feature request. I have NEVER had any issue with mistaking the coersion of an integer type for functions that necessarily have floating-point outputs. As said before, the drastic color change of the wire, even for my colorblind eyes, is a clear enough indicator. I see no reason, fundamentally, to force the user to explicitly perform the coercion themselves (possibly to a poor choice of type anyway) just to un-break a wire that should intuitively work. The math is valid, so there's no reason to be so legalistic about typing. Better, IMHO, to force the programmer to figure out how to get that double back into an integer type - something they'd have to do anyway if they were forced to do a manual coercion themselves. Bottom line, I think, is that this just makes more work for EVERY LabVIEW programmer, while possibly saving a very few, VERY colorblind programmers from shooting themselves in the foot.

[JÞB]

There have been many ideas about changing the coersion glyph dependant upon the possibility of changes to data.  Still, I use a grotesque color for those coersion dots to make sure I see them!  And, I let the coersions happen when desired.  I see no bug here that the IDE options can't address.

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.

[X.]

Of course, this was tongue in cheek...

I am glad it is declined, because indeed it makes little sense.

Such as does breaking wires when the absolute value of an unsigned integer is taken (the link I included in the OP).

This is still something that happens in NextGen Preview, BTW.