June 27

Let function and template parameters carry optionally a visibility attribute. For example:

void log(
    string message,
    private int line = __LINE__,
    private string func = __FILE_FULL_PATH__
);

In another module, log can be called, but the line parameter cannot be set explicitly as it’s not visible. That way, the author or a library can ensure that magic default values for some parameters are indeed applied. The user has the advantage that it is harder to use such a function incorrectly, e.g. log("current step: ", i) accidentally passes something entirely unrelated to line.

Another example would be to alleviate the need for a private overload that has more parameters and is called by the public one.

June 28
On 28/06/2024 5:26 AM, Quirin Schroll wrote:
> Let function and template parameters carry optionally a visibility attribute. For example:
> ```d
> void log(
>      string message,
>      private int line = __LINE__,
>      private string func = __FILE_FULL_PATH__
> );
> ```
> 
> In another module, `log` can be called, but the `line` parameter cannot be set explicitly as it’s not visible. That way, the author or a library can ensure that magic default values for some parameters are indeed applied. The user has the advantage that it is harder to use such a function incorrectly, e.g. `log("current step: ", i)` accidentally passes something entirely unrelated to `line`.
> 
> Another example would be to alleviate the need for a `private` overload that has more parameters and is called by the `public` one.

It can be really useful to forward such arguments from one function to another.

I'm not convinced that this is what we need.

We could instead introduce named parameters which can only be set via a named argument that would archive the prevention of accidental passing of values, whilst keeping it explicitly settable.