If one knows how, it's perfectly fine to pass a Nil to a reference parameter:
I wouldn't go as far as saying it's "perfectly fine", I'd say it's definitely possible but, IMO, it should be strongly discouraged because it is completely reasonable for a procedure/function that uses "var" parameters to presume the parameters are _not_ nil. Using any of the var parameters that got passed a nil value will cause an access violation.
Sven saved me the trouble of digging out the message of a couple of weeks ago where he showed me how to do this.
I'd suggest that the bottom line is that (a) Pascal was designed when programs were basically still the expression of mathematical or logical formulae where (of course) there is no such thing as an optional parameter, and (b) the scope of software is now much wider so we have to admit that additional syntax and semantics are needed.
I have no problem with a var parameter being nullable (is that the right term?) provided it can be checked and/or an error caused by a reference can be caught.
Arguably, the same applies to both const and out parameters.
Let's face it, at least some of the above could be handled by procedure/function overloads which quite simply omit the relevant parameter, but Wirth didn't think of those either.
Finally, pragmatism dictates that modern Pascal's parameter conventions need to be compatible with C. Broadly speaking, var parameters are superior to pointers since they don't have to be explicitly dereferenced and aren't at risk from pointer arithmetic, and not allowing a var parameter to be nulled is a major omission.
MarkMLl