I don't think this is the only way the compiler has. If px was not initialized with a value, it is nil by default if declared as a global variable, or it holds some random value if declared as a local variable. The compiler could issue a hint or warning for the first case, and error for the second case.
The problem is as follows, for the compiler to use the value assigned to px or any pointer for that matter, it has to dereference px at compile time. dereferencing a pointer is a runtime operation, not a compile time one.
No, the compiler does not need to do any dereferentiation for this.
Consider the following code:
var
x: Real;
const
px: PReal = @x;
arr: array[0..1] of PReal = (@x, px);
Right now the compiler treats
px like a variable and it doesn't know about its value. However
if the compiler would treat typed constants more like their untyped counter parts(*)
then it would know the value of
px at compiletime and thus would be able to propagate that to the initialization of
arr. Any changes at
runtime to
px would not be reflected in
arr however as this constant propagation would only happen at
compiletime.
(*) Right now the initialiser value (here the
@x) is a completely separate symbol (
tabstractnormalvarsym.defaultconstsym), to achieve the constant propagation the compiler would instead need to store a constant node (in this case a
tpointerconstnode) with
px.