> A proof is a type.
Yes, Curry-Howard and all that.
If I just write a well-typed function which supposedly calculates pi, the rather trivial well-typedness is not informative by itself.
You're talking about adding reams of verbiage requiring expertise in using an advanced type system for executing a proof.
This isn't how static type systems are actually used and advocated in the field, and it is not feasible in general, only for toy, academic examples.
The proof code, which will exceed the size of the original function by at least an order of magnitude, could also be buggy. At the end of the day, it's just more code.
It reminds me of the argument fropm the Lisp camp: "Well, I could just write (supermacro ...) which implements any syntax and semantics whatsoever". (No, in fact you can't, and the proof is that you never actually will.)
If you really wanted, you could derive a proof that pi is equivalent to some sort of corecursive series, which you can then evaluate in a dependently typed language, I guess. A proof is a type.
On the other hand, how would you write a unit test that checks whether something calculates pi without comparing its result to pi itself?