On 05/10/2025 6:28 PM, TwoOfCups wrote:
> I am guessing I'm not the first person to think of this.
> 
> But allowing ref to be applied to the hidden this on member functions would be nice.
> could be used for lazy init of objects, reassigning the lvalue and stuff.
> 
> Seem like a very easy thing technically so idk if there is some ideological reason not to?
> 
> right now we can do
> ```
> class C{}
> void foo(ref C c){...}
> C c;
> c.foo();
> 
> ```
> 
> Which is pretty good, but an un-attached floating function can often get lost from the type they are meant to be attached to during certain import scenarios or certain template  scenarios so its actually not a robust solution.

This cannot work.

Methods are stored in the vtable which is accessed from the this pointer.

You would be jumping to a function pointer which is acquired after a null dereference.

On Sunday, 5 October 2025 at 05:35:24 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 05/10/2025 6:28 PM, TwoOfCups wrote:
> This cannot work.
>
> Methods are stored in the vtable which is accessed from the this pointer.
>
> You would be jumping to a function pointer which is acquired after a null dereference.

ok so mark it final, still i think such a thing would be useful

On 05/10/2025 6:39 PM, TwoOfCups wrote:
> On Sunday, 5 October 2025 at 05:35:24 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> On 05/10/2025 6:28 PM, TwoOfCups wrote:
>> This cannot work.
>>
>> Methods are stored in the vtable which is accessed from the this pointer.
>>
>> You would be jumping to a function pointer which is acquired after a null dereference.
> 
> ok so mark it final, still i think such a thing would be useful

This is indeed possible.

Walter would like to make the this pointer optionally explicit.

However to support ref on it, there should be reasoning beyond "it could be useful".

On Sunday, 5 October 2025 at 05:45:19 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 05/10/2025 6:39 PM, TwoOfCups wrote:
>> On Sunday, 5 October 2025 at 05:35:24 UTC, Richard (Rikki) Andrew Cattermole wrote:
>>> On 05/10/2025 6:28 PM, TwoOfCups wrote:
>>> This cannot work.
>>>
>>> Methods are stored in the vtable which is accessed from the this pointer.
>>>
>>> You would be jumping to a function pointer which is acquired after a null dereference.
>> 
>> ok so mark it final, still i think such a thing would be useful
>
> This is indeed possible.
>
> Walter would like to make the this pointer optionally explicit.
>
> However to support ref on it, there should be reasoning beyond "it could be useful".

Well in my case I am wanting it for a specific templated serialization scenario where the serializer has the ability to use a proxy type to serialize as a proxy type instead of serializing it directly. And i was wanting to serialize objects as a uuid and on deserialization do a look up to find it but would need to reassign the lvalue to make it work..

i will probably figure out some other way to do it but it will just make my serialization code more complicated and its already very complicated..

so "it could be useful" is all i got for you cus its what prompted me to make this thread.

On 05/10/2025 6:55 PM, TwoOfCups wrote:
> Well in my case I am wanting it for a specific templated serialization scenario where the serializer has the ability to use a proxy type to serialize as a proxy type instead of serializing it directly. And i was wanting to serialize objects as a uuid and on deserialization do a look up to find it but would need to reassign the lvalue to make it work..

A small example of this, where the proposed feature is used would be very welcome.

I'm having trouble picturing the types and their interaction to each other.

On 05/10/2025 7:49 PM, TwoOfCups wrote:
> On Sunday, 5 October 2025 at 05:58:10 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> On 05/10/2025 6:55 PM, TwoOfCups wrote:
>>> Well in my case I am wanting it for a specific templated serialization scenario where the serializer has the ability to use a proxy type to serialize as a proxy type instead of serializing it directly. And i was wanting to serialize objects as a uuid and on deserialization do a look up to find it but would need to reassign the lvalue to make it work..
>>
>> A small example of this, where the proposed feature is used would be very welcome.
>>
>> I'm having trouble picturing the types and their interaction to each other.
> 
> ```
> class C {
>          int uuid;
>      int toSerial(){ // int is the proxy type
>          return uuid;
>      }
>      void fromSerial(int i){
>              // do uuid lookup and assign this if this could be ref
>      }
> }
> 
> ...
> 
> during serialization check if type has a toSerial and call that instead of serialized directly, in this case uuid will be written instead of the class contents. the actual class contents will be serialized else where
> ```

Okay so the class is memorized (somehow, doesn't matter).

You have the ability to access and reflect upon the class at compile time.

Why not use a static method instead?

```d
class C {
	...

	static C fromSerial(int i) {
		C self = ...; // lookup i for C
		return self;
	}
}
```

On Sunday, 5 October 2025 at 06:56:27 UTC, Richard (Rikki) Andrew Cattermole wrote:
>
> Why not use a static method instead?


yeah i was thinking about doing that but like i said the serialization code is already a fucking mess of weird little special cases. so now i have to add checks for if the proxy functions are static and handle in a different way.