Compiler patch for runtime reflection

[Robert Jacques]

On Tue, 25 Oct 2011 12:38:18 -0400, Jacob Carlborg <doob at 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.