[RFC] Default initialization for out parameters

[setton]

This provides a proposal for allowing out parameters to have a default initialization, which will be evaluated at the point of subprogram calls. The idea is to eliminate a category of access to uninitialized memory.

[sttaft]

Looks interesting. One feature of in-parameter defaults is that you can change them as part of renaming. If that were allowed for out-parameter defaults, then the out parameter would necessarily be passed "in" as well, initialized to the default value at the call site. Unfortunately, that would also mean that you could eliminate them as part of a renaming, thereby getting back the possibility of an uninitialized out parameter. One could restrict renaming to allow you to add or change the default for an out parameter, but not eliminate the default.

Defaults can also be added or removed as part of declaring a generic formal subprogram. It would be important to decide whether the presence of an out-parameter default would affect matching of actual-to-formal subprograms.

You might also need to think about overriding, and whether an override needs to have an out-parameter default if the original did, and whether this depends on whether the subprogram is a dispatching subprogram.

[setton]

Thank you @sttaft for the feedback! I didn't know you could change the defaults of in parameters... For out parameters, it really should be forbidden, since the implementation of the body is strongly dependent on this. Imagine that someone writes a "Frobnize" subprogram with an out parameter "Success", making sure to initialize it to False and only setting it to True in the rare case where Frobnization was successful: we can't have clients change this.

I'll amend the PR to reflect this!

[sttaft]

Perhaps you should only allow it on the body when there is a separate spec. It will be annoying if on renaming you have to always repeat the out-parameter default, with a conforming expression. The default is really just a convenience for the implementor -- it doesn't do much for the caller. So perhaps that would argue for allowing it on a subprogram body that has a separate spec, and not bother to mention it in the visible spec at all.

[setton]

Yes, that's a good point. Also, the caller doesn't need to know the default value, that's not something useful. Will amend in light of this.

[yakobowski]

@setton can you update this proposal according to the last discussion? Also, this idea will be relevant for the WG on initialization.

[setton]

Will do.

…

On Tue, Jan 5, 2021 at 11:50 AM Boris Yakobowski ***@***.***> wrote: @setton <https://github.com/setton> can you update this proposal according to the last discussion? Also, this idea will be relevant for the WG on initialization. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#35 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAXVTPPCPOO5ML2ZEXMW7TSYL4IPANCNFSM4JQWZJ4Q> .

[setton]

Done @yakobowski - proposal updated in light of the discussion with @sttaft.