On 9/3/2016 2:54 PM, Jacob Carlborg wrote:
> On 2016-09-03 22:40, Andrei Alexandrescu wrote:
>
>> That... doesn't sound good. I wonder how such important changes slip by
>> Walter and myself unnoticed.
>
> Here's the PR that introduced the change: https://github.com/dlang/dmd/pull/6078
>

Looks like I'm to blame as I pulled it.

On Sunday, 4 September 2016 at 07:24:42 UTC, Basile B. wrote:
> The introspection creates a special structure for each property annotated with @Set, @Get, or @SetGet. This is a kind of interface for serialization/binding/object inspector (a bit like "published" in Object Pascal).

But you can't access private fields outside of the current module, so you need to mixin sth. to set/get the value anyhow.

>> Defining de-/serialize methods in the class/struct, e.g. with a mixin template would be the cleaner and more obvious approach IMO.
>
> I see your strategy...each time someone will find an argument to make the traits omniscients you'll say, "no because it's cleaner to do like that" ?

No, I'm just trying to understand the requirement for introspection without access.

On Sunday, 4 September 2016 at 08:42:43 UTC, Martin Nowak wrote:
> On Sunday, 4 September 2016 at 07:24:42 UTC, Basile B. wrote:
>> The introspection creates a special structure for each property annotated with @Set, @Get, or @SetGet. This is a kind of interface for serialization/binding/object inspector (a bit like "published" in Object Pascal).
>
> But you can't access private fields outside of the current module, so you need to mixin sth. to set/get the value anyhow.
>

But that's the point ! We are many willing to see this restriction removed for the traits because they are special., i.e they should allow to implement, using meta programming, features that less powerful languages do in intern. That's also why I propose to add a 3rd optional bool parameter to the allMembers trait:

enum RespectProtection = false;
enum IgnoreProtection = true;

__traits(allMembers, T, RespectProtection)
__traits(allMembers, T, IgnoreProtection)

The 3rd optional parameter, when not specified, would be set a default value of false (equivalent to __traits(allMembers, T, RespectProtection), to prevent breakage.

Because allMembers would act as a filter for getMember, getOverload...the protection check in getMember, getOverload... would be removed.

This will be obviously more complex than that but that's the idea.

On Saturday, 3 September 2016 at 16:52:50 UTC, Martin Nowak wrote:
> On Tuesday, 30 August 2016 at 22:24:12 UTC, Ali Çehreli wrote:
> Well let's come up with a better solution then.
> Let's start by finding some proper use-cases that require introspection on private members w/o having access to them.

Still haven't heard really good use cases for the above, but the trade-offs for also allowing access to private members aren't that bad, thus it seems like the better path forward.
See http://forum.dlang.org/post/ymkehalxcigswvltlfjj@forum.dlang.org

On 2016-09-04 09:39, Johannes Pfau wrote:

> Allowing access to private fields / functions also means that
> those members are part of the public API/ABI of a library. So changing
> private members can break dependent libraries...

They've always been accessible using .tupleof and taking the address of a member, before the recent lookup rule changes.

-- 
/Jacob Carlborg

On 2016-09-04 05:45, Martin Nowak wrote:

> A public setter for private members is weird, but well.

The setter can do validations, manipulation and other kinds of calculations based on the given value.

-- 
/Jacob Carlborg

On 9/4/16 5:14 AM, Martin Nowak wrote:
> If we really need introspection of private members than we might need to
> go back to the drawing board and modify the visibility concept
> introduced with DIP22.

Thanks for answering. Yes, we really need introspection of private members. One way or another we need to support that. -- Andrei

On 9/4/16 5:56 AM, Martin Nowak wrote:
> On Saturday, 3 September 2016 at 19:31:12 UTC, Jacob Carlborg wrote:
>> That can usually be solved using .tupleof[i], but I agree.
>
> Well, .tupleof gives you a typed representation of the memory layout, to
> me it's something different than qualified access of fields, just a
> safer mean to access memory. And sure you can always memcpy data.
> Also introspection works on .tupleof, so it's not affected by the
> allMembers change and it's awkward to mix them b/c names and layout
> don't have a simple 1-to-1 relation.

Yah, .tupleof is great to have. I think that should be enough for most introspection needs. Only the field names are missing, can those be accessed somehow? -- Andrei

On Sunday, 4 September 2016 at 12:33:07 UTC, Andrei Alexandrescu wrote:
> Thanks for answering. Yes, we really need introspection of private members. One way or another we need to support that.

Do we, though? It's easy to state a general claim like this, but I find it hard to actually justify.

 — David

On Sunday, 4 September 2016 at 12:37:47 UTC, David Nadlinger wrote:
> Do we, though? It's easy to state a general claim like this, but I find it hard to actually justify.

(And to pre-empt the collective freak-out, note that this statement is coming from somebody who has done quite a bit of pioneering serialisation/meta-programming work. — David)