[robot_no_421]

"As it master, I should be able to force my machine into giving me access of private fields."

If you're writing the code then you can do whatever you want with it. But if I'm writing the code you're using, I want the power to express "the end user cannot use this private field".

You trying to access the private fields in the library I or someone else wrote would be like trying to change a book someone wrote or a painting someone made. It's not the computer restricting you, it's the author of the code.

EDIT: This response was not my finest take.

[alkonaut]

I think the agreement is rather “if you change the private field then there are no longer any guarantees of anything”. Which is fine, I think. And obviously with or without reflection anyone can already modify the private field.

[Quekid5]

It's the shortest path to Hyrum's Law, certainly.

> And obviously with or without reflection anyone can already modify the private field.

This bit, I don't understand. Wouldn't that require unsafe?

EDIT: Just to say: Abstract data types usually require upholding some invariants which all the operations on those data types must uphold at entry/exit. If anyone can do whatever, then what's left othen than just a bag of bytes?

[alkonaut]

Yes. I’m 100% talking about unsafe Rust now (for private fields).

That is: I see reflection only as a way of making unsafe bytemucking a bit more ergonomic. Its nothing you can’t already do. It’s a well behaved object with invariants 99% of the time, then for some edge case/cheat it’s not. Much like the difference between safe and unsafe already is. Most of the time you rely on the guarantees, but occasionally you throw the guarantees out. And again: this IS already in an unsafe context by necessity. This has been the case in every language with encapsulation and reflection (C#, Java, …) since forever. And it’s a super useful thing. I can’t see why the encapsulation in (unsafe) Rust is more important? Is it because it has no runtime to provide guard rails where the JVM/CLR would still throw exceptions when I use my tampered object with broken invariants?

[Quekid5]

Oh, I see...

I think I was thinking about reflection in an entirely different way. When I think Reflection I think mostly static and generative reflection -- so you can introspect on data structures, derive [whatever] from that, generate code, whatever... but you still cannot do [whatever] to the thing you reflected on. (Other than whatever the language says you can do as a public consumer of that API/structure)

So you can, say, add serialization code, generate property test instances, whatever.

What you cannot do is do anything to "invade" the thing being reflected on and change its meaning.

[alkonaut]

This sort of thing seems you should be able to do already at compile time instead of using reflection?

[cryptonector]

But sometimes you might writing a debugger. Reflection is essentially including all the "debug symbols" that you need in order to build a debugger into your application.