Nim should allow getField(someObj, someField) to access private fields; use case: custom serialization/deserialization

[timotheecour]

proposal

• normal access someObj.someField would still be disallowed under this proposal
• getField(someObj, someField) would allow accessing any field (including private) from an object

notes

• repr(a) already allows showing private fields

• nothing else I tried allows accessing (read or write) private fields, including fields and fieldPais, eg:

# mymod.nim:
type Foo* = object
  a1*:int
  a2*:int
  a_hidden:int

# main.nim
import mymod
for value in Foo().fields:
 echo value #Error: undeclared field: 'a_hidden'

• in D, this "escape hatch" is explicitly allowed:

// mymod:d:
struct A{
  int a1 = 10;
  private int a2 = 11;
}

// main.d
import mymod.d
void main(){
  A a;
  foreach(i, ai; a.tupleof){
    ai+=100; // read/write access
    writeln(i," ", ai, " ", typeof(ai).stringof);
  }
}

rationale

writing custom serialization/deserialization (and custom pretty printing, eg for debugging, display etc) requires access to all object fields, not just public ones. Without this we're limited to what a 3rd party library exposes, which makes it impossible to support custom serializers on types imported form those 3rd party libs, eg:
msgpack
protobuf
captain'proto
Bson (for mongo)
etc

in D, custom serialization/deserialization was the reason to allow this escape hatch.
(eg for D, I forked d-msgpack to allow serializing/deserializing arbitrary data, even in presence of subclasses, references with cycles etc; it'd be even easier in Nim once this private field access issue is resolved

but what about safety / preventing access to secret data?

• repr already allows peeking into private fields anyways (but is not usable / practical / efficient for serialization purpose)
• private should not be about security / preventing client libraries to peek into secret data kept private; there are other ways for that and relying on that wouldn't be robust anyways (eg repr allows that, or casting to another object, or using a hex editor / gdb etc
• once user writes private data, he's on his own ; but Nim shouldn't prevent useful use cases on the basis these features could be misused (that's why we have cast etc)

[Araq]

It's not about "preventing access to secret data", many objects with hidden fields or that contain sockets etc cannot be serialized and so if the library doesn't allow for it explicitly, it's foolish to assume that you can just go ahead as long as Nim lets you access private fields.

[mratsim]

Note that objects with private fields cannot be hash-ed for use in Tables.

For example Duration in the times module.

[andreaferretti]

Unless they declare their hash, of course. It is usually good practice in many programming languages to declare equality and hashing together (to ensure they are consistent), and if you have some hidden fields you probably have some custom notion of equality

[Araq]

Rejected, you may as well cast it to a blob type for "serialization" that doesn't work reliably.

[timotheecour]

fixed via scopable privateAccess in nim-lang/Nim#17706