On Tue, 25 Oct 2011 12:38:18 -0400, Jacob Carlborg <d...@me.com> wrote:
On 2011-10-25 16:21, Robert Jacques wrote:
[snip]
Both are protection attributes. The problem of taking the delegate of a
mutable member on a const object, is the exact same problem as taking
the delegate of a private member.
I don't agree.
[snip]
Bypassing the protection type system and delegate escape are very
different things. The escape of a delegate is fully controlled by the
coder of the class/module; with bypass mechanisms, the library writer
has no control.
So how should this be fixed? Make it a compile error to create a
delegate from a private method?
I think we are taking about different things. Today in D, due to a bug, for
example
foo.bar()
won't compile because it's private/not-const/etc. But
(&foo.bar)()
will compile. That 'feature' is what I thought you were referring to. If the
writer of a class wants to let a delegate of a private member function escape,
I don't have a fundamental problem with it. But I do have a problem with
someone who isn't the writer of the class doing so.
[snip]
Still, __traits is still the full fledged compile-time reflection
feature and doesn't bypass protection attributes.
Yeah, but for a serialization library I want to be able to serialize
private fields. This is known issue that this breaks encapsulation.
I understand that at times when serialization has to break encapsulation. My
opinion though, is that classes should have to opt in, before the serializer
goes ahead and breaks their carefully designed encapsulation. i.e. someone
should have to code review the class to make sure everything is kosher. For
code you are developing, this is as simple and straightforward as adding a
single mixin statement to the class.
