On Fri, Sep 3, 2021 at 11:16 AM Rick C. Hodgin via Std-Discussion
<std-discussion_at_[hidden]> wrote:
>
> The 1) and 2) options outlined in the initial post (for referencing
> the passed in counts in code and being able to make logic decisions
> with that information, and for conditional compilation).

That's not a motivation; that's an *example*. A motivation is when you
say "here's a thing that we have a significant need to be able to do,
but we can't do it right now". You explain *what* you want to be able
to do, but you haven't explained why it is important.

> IMO though, and most importantly, it completes the set of features
> related to default parameter assignments.

The core of your feature is the notion that a function's default
parameters are an intrinsic aspect of the function itself, much like
its parameter list. But that's *not* how default parameters work in
C++ as it currently exists. They're currently just syntactic sugar at
the call site, and *nothing* more.

So this would not "complete" the default parameter feature; it would
*change* it to mean it currently does not.

On Fri, Sep 3, 2021 at 12:08 PM Rick C. Hodgin via Std-Discussion
<std-discussion_at_[hidden]> wrote:
>
> On 9/3/21, Andrew Schepler <aschepler_at_[hidden]> wrote:
> > Even the "simple" solution of adding a little data in the stack requires a
> > breaking ABI change, which would be a big deal. It's also a violation of
> > the C++ principle "you don't pay for what you don't use." I could see a
> > compiler extension providing this for only functions specifically tagged
> > with some attribute, if it were considered useful enough. From there to the
> > Standard would be a harder step.
> >
> > But you can also get this behavior without extreme trouble just in the
> > existing language. Define functions with that extra parameter, and use a
> > callable class template object to wrap each with the wanted usage. A few
> > preprocessor macros might help reduce the code for defining such a
> > function.
> >
> > -- Andrew Schepler
>
> Hi Andrew. I could do this with a stand-alone pre-processor. It
> would just have to know enough C++ syntax to look for function
> definitions and bodies, and then auto-inject those parameters.
>
> As for existing C++, the ABI wouldn't break for functions that don't
> reference the explicit and implicit parameters, meaning the entire
> existing code base. For those, the ABI would generate as it always
> has.
>
> For new code that uses __ARGS_EXPLICIT__ and __ARGS_IMPLICIT__
> references, only those would change the ABI.

That's not how ABIs work. A function's ABI is defined *only* by the
function declaration. An ABI needs to be able to work *without* seeing
the function definition. As such, what gets referenced inside of the
function definition is ABI-irrelevant.

> And they wouldn't
> actually change the ABI. They would just inject two additional
> parameters into the function calls, which are the explicit and
> implicit counts, which are known at each instance where they are
> issued.
>
> If it were a new feature enabled in a specific version ... wouldn't it
> work from that point forward?

We don't want C++23 code to be unable to talk to C++20 code.