Background

I had previously mentioned in this issue:

An error on a function like Cylinder3D can only be handled one way really: correcting the argument to it in the source code as one generates the shape! This is even implied with the implementation of the ErrMsg function: it includes the line number of the function that yielded the error. panic already does that and saves us having to formally handle the error message.

@deadsy has mentioned the reason for this

It was done this way because: [...]
I wanted to support the programmatic generation of shapes (E.g. evolutionary algorithms) and that implied bad parameter values needed a non-panic response.

I initially agreed it was desirable that functions do not panic but I have now rolled back on this opinion. The reason being most users (+99% I'd guess) will suffer from this decision needlessly. My argument in this issue is that we can get the best of both worlds without compromising on robustness of an SDF program which requires this strict error handling. Let me explain.

Proposal

I propose changing

func Cylinder(radius, round float64) (SDF3, error)

to

func Cylinder(radius, round float64) SDF3 // panic on error

It is proposed that:

• incomplete/impossible geometry parameters cause a panic.
• No parameter correcting be done under the covers

I argue most users today do not make use of error handling of sdfx errors and this will be a welcome change.

Impact

Pros

• Will positively impact the sdfx user developer experience
• Simplify internal implementations greatly.
• More familiar usage for people coming from simpler languages

Cons

• Eliminate sdf error handling

Impact mitigation

If error handling were required then wrapper functions can be declared in the future with little effort. See this example:
https://go.dev/play/p/lMZnaJV7o4Y