+1For many WebGL functions taking GLfloat, it is actually very important to _not_ throw, because these floats are often the result of nontrivial arithmetic, and nontrivial floating-point arithmetic does produce non-finite values, and good floating-point API design is to handle such non-finite values gracefully. So it's actually very important to make GLfloat unrestricted.
If GLfloat is unrestricted GLclampf should also be.For GLclampf, I don't know. Since GLfloat must be unrestricted, and IIUC current browsers implement unrestricted anyways, it may be simpler to keep it unrestricted. That may also be a good idea as GLclampf's too may be the result of nontrivial floating point operations.
But note that the ES 2.0 spec says using NaN or infinity will
produce unspecified results; it also says that these values should
not result in "GL interruption or termination."
The WebGL spec. does not specify what the results should be
either so I would hardly say that non-finite values are handled
"gracefully." Graceful handling would probably require that the
values be propagated as specified in IEEE 754. But I think
throwing an exception would be akin to "GL interruption" so I come
down on the side of unrestricted.
NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.