Instead of documenting it in the comments N[Pi/180, 50], the constants can be defined within math as

const (
        DegToRad = Pi/180
        ...
)

directly with no loss of precision. But the same can be done in client's code (math.Pi/180 etc.) and IMO constants in math should be restricted to the few fundamental ones only (as it mostly is now).

Agree with @cznic - if getting these constants is so trivial, why should they be included in math? Pi/180 is even shorter than DegToRad.

One thing I like about go is that many thinks are just easy to do without a lot of thinking.

It the same as with constants like time.Minute = 60 * Second. Well everyone knows that a minute has 60 seconds and could declare the constant him self. But it's in the std lib of go and I like it a lot.
It's just that the time lib is build up on Nanosecond and offers conversions from "human readable" values like Minutes. Same with Rad and Deg, it's good to have all implementations build up on Rad for good reasons, but as a user I don't want to bother with it and want to be able to convert this values.

@niondir I think the policy regarding what convenience constants to include in std is directly influenced by how often they would be used. time.Minute is very common. I would assume math.DegToRad wouldn't be.

Perhaps this warrants some investigation, for example to see how often Pi / 180 or 0.01745329... appear in the wild.

I'm against this. Even if I have a constant math.DegToRad it's not necessarily obvious how to use it (do I multiply with it, divide it?). Everybody doing trigonometric operations that require conversions will know that 2*pi corresponds to 360 degrees or 400 gradians. It's trivial to write those conversions. And it's trivial to locally introduce constants if necessary. It's different for the time constants which are used more frequently, and for which it's very clear what they mean.

@griesemer captured my own thinking well.

Sounds like there's not support for this. Marking declined.