Fix inconsistency in result parameter

[OmarShehata]

It sounds like the intention is to force users to supply a result parameter to prevent accidental bad performance (based on the discussion here #1161).

There's still a lot of functions that have an optional result parameter (were these added after that issue was resolved?) For example, all the methods below have an optional result in Cartesian3:

• Cartesian3.fromSpherical
• Cartesian3.fromRadians
• Cartesian3.fromElements
• etc.

Similarly for all the functions here:

https://cesiumjs.org/Cesium/Build/Documentation/Transforms.html

I personally like it when it's optional because I usually just end up throwing an inline new Cesium.Cartesian3() since it's usually something that runs only once, but I think regardless of my personal preference the library should be consistent. It's very annoying to try to remember which methods required a result and which didn't.

[mramato]

• fromXXX elements are almost always used to create new instances so they intentionally do not require a result parameter. This shouldn't change.

• I think Transforms was just missed the first time around and it would be a hassle to update everything to enforce it (since it's a breaking change).

I think everyone would love to get rid of result parameters completely, but they are an unfortunate requirement for writing performant JS. We could probably just close this unless there are lots of other examples of non-fromXXX functions that have it as optional.

[hpinkos]

Yeah, I agree. The API is this way by design.

[OmarShehata]

Thanks for the context. I'm fine with closing. I (or anyone else) can re-open if more functions like that are found that were missed.