But that is specifically discussing Framework Design and the reason given is basically "Framework architects designing for a general audience should not expect users to master working with out or ref parameters."

Not sure I agree with that statement but will accept it. However it does not mean, or imply, that there are no valid uses of either 'out' or 'ref' in other contexts.

The .NET TryParse() methods are one example (in which MS ignore their own guidelines :-} )

>I'll argue there's a better way.
>
>From .Net Framework Design Guidelines http://msdn.microsoft.com/en-us/library/ms229015.aspx:
>
>"Out parameters are similar to ref parameters, with some small differences. The parameter is initially considered unassigned and cannot be read in the member body before it is assigned some value. Also, the parameter has to be assigned some value before the member returns.
>
>X AVOID using out or ref parameters.
>
>Using out or ref parameters requires experience with pointers, understanding how value types and reference types differ, and handling methods with multiple return values. Also, the difference between out and ref parameters is not widely understood. Framework architects designing for a general audience should not expect users to master working with out or ref parameters."
>
>Instead of returning out parameters, it may be better to return an object that contains the results.
>
>
>>In that instance - No. But still unnecessary. But if, for example, the parameter is a large object which needs to be marshalled then it is more significant.
>>I'd argue that, just from a best-practice POV, if the called method doesn't require the parameter to be passed in then 'out' is best.