On 10/14/21 7:21 AM, Ogi wrote:

> is there any way to access the types defined inside
> in function to get/set their static members?

Possible through instances of those types (not through type names because those type names are not visible from the outside):

auto foo() {
  struct S {
    static int s;
  }

  return S();
}

void main() {
  auto s = foo();
  s.s = 42;

  foo().s++;
  assert(foo().s == 43);
}

Ali

On 19.10.21 10:31, Mike Parker wrote:
> On Tuesday, 19 October 2021 at 08:15:01 UTC, Ogi wrote:
>>
>> What are we talking about is not a game but an engine to be used for making different games, potentially by people other than me. So this is a limitation that the users will have to be aware of and work around it, and failing to do so will result in silent bugs in their code because there’s no way to enforce it at compile time.
> 
> Personally, this isn't something I would expect, nor would I worry about it. Static variables in functions are generally there because they are scoped to that function, to be used within that function over the run time of the program. There shouldn't be any reason whatsoever for them to be accessible outside the function.
> 
> The idea that you are even considering serializing them is just a foreign concept to me. If I wanted to make something available to a serializer, I wouldn't declare it inside a function. I'd put it at module scope, or in an aggregate. I'm not saying no one would ever think of it (you obviously did), but in 25 years of following various online programming communities (C, Java, D, game development, etc.) I can't recall seeing anyone bring it up before now. I can't imagine it would be common enough to be an issue.

The OP has a well-motivated use case. I don't understand at all why you are being this dismissive. The inability to serialize static variables scoped inside functions is clearly an arbitrary limitation that should be lifted.

On 19.10.21 10:15, Ogi wrote:
> 
> What are we talking about is not a game but an engine to be used for making different games, potentially by people other than me. So this is a limitation that the users will have to be aware of and work around it, and failing to do so will result in silent bugs in their code because there’s no way to enforce it at compile time.

Without the necessary language extension, what you could do as a workaround is require all functions in the plugin to be `pure`. Then they can't access static variables. Of course that also rules out accessing globals, so you'd have to pass around global state explicitly within some object.

On 19.10.21 11:19, Kagamin wrote:
> On Tuesday, 19 October 2021 at 08:15:01 UTC, Ogi wrote:
>> On Thursday, 14 October 2021 at 14:32:49 UTC, Paul Backus wrote:
>>> No.
>>
>> Is there any solid reasoning behind this gaping hole in the language reflection capabilities? I understand that in general it is not a good idea to meddle with static variables but serialization/deserialization is a good example where this is required.
> 
> You can't serialize everything.

Why not?

> The standard approach to serialization is to use DTOs - types tailored for serialization.

Clearly the ambition of the OP is to do something that's better than the existing standard.

On Tuesday, 19 October 2021 at 11:12:12 UTC, Timon Gehr wrote:
> The OP has a well-motivated use case. I don't understand at all why you are being this dismissive. The inability to serialize static variables scoped inside functions is clearly an arbitrary limitation that should be lifted.

As an option a virtual machine should be able to serialize everything or at least RAM.