tupleof seems to break encapsulation

[Jacob Carlborg]

On 2020-09-05 07:14, 60rntogo wrote:

> I wouldn't dispute that it is useful, but that's besides the point. If I 
> declare something private, it's usually because I want to preserve 
> certain invariants and I want the compiler to provide a guarantee that I 
> don't accidentally violate them. As it stands, the compiler cannot 
> guarantee that if I use tupleof.
> 
> I don't really have an issue with read-only access to private fields 
> (but arguments could be made against it) and then serialization would 
> still be possible. However, if my struct is supposed to maintain 
> invariants, then any attempt at deserialization that naively reads from 
> a tuple without establishing these invariants should fail to compile.

I wouldn't mind if `tupleof` was not allowed in @safe code, which Walter 
mentions in one of the linked issues. Although it would be a breaking 
change.

Secondly, my serialization library, Orange [1], uses `tupleof` to read 
and write fields. It also supports before and after hooks for both 
serialization and deserialization. This allows to implement any 
invariants that are not covered by just restoring the fields. It also 
supports implementing a method that allows to take full control of the 
(de)serialization of a specific type.

Thirdly, you can do the same thing with pointer arithmetic. Although 
this is not allowed if @safe code.

[1] https://github.com/jacob-carlborg/orange

-- 
/Jacob Carlborg