I missed part of this previously.
>>>>>

There are times when a method needs a simple variable such as a
counter or a boolean, and so we then need to add a member variable to
the class definition. I'm proposing that we can do all of this inside
the body of the method -- so long as the body of the method is inline
inside the class definition. I also propose that the variable "record"
would be inaccessible by other methods.

<<<<<

If this is local to this method only it is better but still flawed. Why
limit this to only a "simple variable". Who gets to decide that? A trivial
type? What about a trivial struct? Sounds kind of arbitrary. Rules need to
be consistent across all types, trivial or not.

>" int Foo::record;"
The "foo::" makes it sound/look like it is part of the class. If it is
only accessible by that method shouldn't it be something more like
scope_local, kind of in the jist of thread_local? But where does this data
live? What is your proposed/suggested the implementation mechanism? Not
that the implementation would actually be part of the spec but you need to
have some way to prove that this is somehow workable.
" scope_local int record;"



On Sat, Oct 15, 2022 at 1:58 PM Chris Ryan <chrisr98008_at_[hidden]> wrote:

> Member injection just won't fly.
>
> You did not specify but I am presuming that the injected member would be a
> full member that could be accessed from any other member function.
> Would each member that accessed it need to redeclare/redefine it?
> What would the access-specifier be for this implied/injected member?
> (struct default public? / class default private?)
>
> inline and out-of-line should function the same.
>
> Your: example:
> struct Foo {
> int Method(int arg)
> {
> int Foo::record;
> record = arg;
> return arg + 4u;
> }
> };
>
> but this isn't the same (or valid under your rules):
>
> struct Foo {
> int Method(int arg);
> };
>
> int Foo::Method(int arg)
> {
> int Foo::record;
> record = arg;
> return arg + 4u;
> }
>
> Also your feature would also imply this would be valid:
> struct Foo {
> int Method(int arg)
> {
> int Foo::record(arg);
> return arg + 4u;
> }
> };
>
> However using that inline member injection, this member initialization
> would also imply would be valid
>
> struct Bar
> {
> Bar()=delete;
> Bar(const Bar& lhs)=default;
> Bar(int i){...};
> };
>
> struct Foo {
> Bar& Method(Bar& arg)
> {
> Bar Foo::record(arg);
> return arg;
> }
> };
>
> But you could never construct Foo because Bar can't be constructed without
> a default constructor.
> But if for some reason you allowed to constructed Foo without constructing
> Bar,
> And if Foo::Method(...) was never called, Foo::Bar was never constructed,
> you would be coping an un-initialize Bar,
>
> int main()
> {
> Foo f1;
> Foo f2 = f1;
> }
>
> Also a simpler example/question (int&)
> struct Foo {
> int Method(int& arg)
> {
> int& Foo::record(arg);
> return arg + 4u;
> }
> };
>
> You would be initializing a reference (allowed only once on construction)
> What happens when you call the Foo::Method(...) the second time.
> Would you be re-initializing (re-assigning) the reference (that can never
> be done)
>
> Sorry, there are too many holes with inline member injection.
>
>
> On Sat, Oct 15, 2022 at 12:50 PM Frederick Virchanza Gotham via
> Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>> I propose that the following:
>>
>> struct Foo {
>>
>> int Method(int arg)
>> {
>> int Foo::record;
>>
>> record = arg;
>>
>> return arg + 4u;
>> }
>> };
>>
>> behaves the same as:
>>
>> struct Foo {
>>
>> int record;
>>
>> int Method(int arg)
>> {
>> record = arg;
>>
>> return arg + 4u;
>> }
>> };
>>
>> There are times when a method needs a simple variable such as a
>> counter or a boolean, and so we then need to add a member variable to
>> the class definition. I'm proposing that we can do all of this inside
>> the body of the method -- so long as the body of the method is inline
>> inside the class definition. I also propose that the variable "record"
>> would be inaccessible by other methods.
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>