Zero should not be exposed to the public

[Yuanwe]

Zero should not be exposed to the public, which will lead to someone being able to modify Zero, it is recommended to adjust

[mwoss]

It's debatable, but probably you are right. At least such constant/variable should not be used in any of decimal methods. Currently, I see a single usage of this const in ExpTaylor method. As making this const/var private would be considered as breaking change, I will probably refactor all places in code where it was used.

[Yuanwe]

It's debatable, but probably you are right. At least such constant/variable should not be used in any of decimal methods. Currently, I see a single usage of this const in ExpTaylor method. As making this const/var private would be considered as breaking change, I will probably refactor all places in code where it was used.

Thanks !

[rickb777]

This really is debatable. In principle I would agree. However, the Go standard library has widespread use of var "constants" (that are not constant) and all sorts of things will go wrong if you meddle with their values. The understanding is that you should not; if you do it's your responsibility.

So exposing Zero seems consistent with most other Go APIs. It might also be helpful to expose One as well.

[rickb777]

(aside: ideally Go would have immutable values that would allow such var expressions to be really constant; however the language does not have this capability)

[mwoss]

Thanks for explaining how it looks like in the std lib Rick! :) Now I wonder what would be the best idea here, as at one point this library would probably have other constants like Pi, E, One, etc as global variables.