On 09/04/2016 05:51 AM, Andrei Alexandrescu wrote:

* Tracing how and when a member mutates.

Ali

On 09/04/2016 05:37 AM, David Nadlinger wrote:
> 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

Let me flip the question: What harm can there be when I pass my type to a template and that template accesses the private members?

Ali

On Sunday, 4 September 2016 at 12:36:43 UTC, Andrei Alexandrescu wrote:
>
> 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

Note that the spec tells us:
"The .tupleof property returns an ExpressionTuple of all the fields in the class, __excluding__ the hidden fields and __the fields in the base class__." (emphasis mine)
So then you have to do __traits(parent, ) recursively...?

On 09/03/2016 03:13 PM, Ethan Watson wrote:
> On Saturday, 3 September 2016 at 21:54:24 UTC, Jacob Carlborg wrote:

> allMembers not returning all members makes introspection
> entirely useless when it comes to Binderoo.

Same problem with Weka's code base...

> getMember itself, well, I'd honestly prefer if there was a way to get to
> members without having to correlate with .tupleof as it will simplify
> Binderoo code.

Again, same problem at Weka...

Protection attributes are for protecting programmers from implementation changes. If I reach for allMembers or getMember, it's an explicit way of saying "I don't care about the consequences."

Ali

On 09/03/2016 09:37 AM, Martin Nowak wrote:
> On Wednesday, 31 August 2016 at 21:12:54 UTC, Ali Çehreli wrote:

>> The recommended solution of mixing in every template instance is not a
>> viable solution because that would effectively remove IFTI from D.
>> What a huge loss that would be. We can't afford that.
>
> Exaggeration won't help us to find good solutions. Remember that private
> fields never were accessible, so only some edge cases will be affected.
> The need for mixin templates will remain rare.

I don't see how the user of a template library can decide whether to mixin or not without knowing the current implementation if of the library.

For that reason, I must mixin. For example, the following program is broken because I don't know whether writeln uses allMembers or not:

    // BROKEN CODE:
    MyStruct s;
    writeln(s);

Do you see the problem? I can't leave that code that way. I have to figure out mixin writeln's instantiation. As you see, mixins will not be rare. Every template use must be mixed in.

Ali

On Wednesday, 7 September 2016 at 15:08:17 UTC, Johan Engelen wrote:
> Note that the spec tells us:
> "The .tupleof property returns an ExpressionTuple of all the fields in the class, __excluding__ the hidden fields and __the fields in the base class__." (emphasis mine)
> So then you have to do __traits(parent, ) recursively...?

or use std.traits.BaseClassesTuple.

On Wed, 07 Sep 2016 12:21:40 -0700, Ali Çehreli wrote:
> Protection attributes are for protecting programmers from implementation changes. If I reach for allMembers or getMember, it's an explicit way of saying "I don't care about the consequences."

If it's just about implementation changes, allMembers / getMember is a way of inspecting types to get what currently exists. It will continue to be correct in the face of changing fields.

On 9/7/16 9:21 PM, Ali Çehreli wrote:
> On 09/03/2016 03:13 PM, Ethan Watson wrote:
>> On Saturday, 3 September 2016 at 21:54:24 UTC, Jacob Carlborg wrote:
>
>> allMembers not returning all members makes introspection
>> entirely useless when it comes to Binderoo.
>
> Same problem with Weka's code base...
>
>> getMember itself, well, I'd honestly prefer if there was a way to get to
>> members without having to correlate with .tupleof as it will simplify
>> Binderoo code.
>
> Again, same problem at Weka...
>
> Protection attributes are for protecting programmers from implementation
> changes. If I reach for allMembers or getMember, it's an explicit way of
> saying "I don't care about the consequences."

Martin has a PR to improve on this, could you all please take a look? I can't really do much until Sunday, I'm on a WiFi connection slower than a herd of turtles, and which only works if I hold my laptop over my head. So I'll click "Send" on this then push the roof with my laptop. -- Andrei

On Wednesday, 7 September 2016 at 19:29:05 UTC, Ali Çehreli wrote:
> On 09/03/2016 09:37 AM, Martin Nowak wrote:
> > On Wednesday, 31 August 2016 at 21:12:54 UTC, Ali Çehreli
> wrote:
>
> >> The recommended solution of mixing in every template
> instance is not a
> >> viable solution because that would effectively remove IFTI
> from D.
> >> What a huge loss that would be. We can't afford that.
> >
> > Exaggeration won't help us to find good solutions. Remember
> that private
> > fields never were accessible, so only some edge cases will be
> affected.
> > The need for mixin templates will remain rare.
>
> I don't see how the user of a template library can decide whether to mixin or not without knowing the current implementation if of the library.
>
> For that reason, I must mixin. For example, the following program is broken because I don't know whether writeln uses allMembers or not:
>
>     // BROKEN CODE:
>     MyStruct s;
>     writeln(s);
>
> Do you see the problem? I can't leave that code that way. I have to figure out mixin writeln's instantiation. As you see, mixins will not be rare. Every template use must be mixed in.

Well, I can only repeat what I stated several times before, private members were never accessible by name (via getMember or .name). So either writeln uses .tupleof (unnamed) or ignores private members.

This is the pre 2.071 state.

method    | visible | accessible
--------------------------------
.name     |    y    |    n
getMember |    y    |    n
.tupleof  |    y    |    y

This was the 2.071.1 state (for which the allMembers fix was a valid solution).

method    | visible | accessible
--------------------------------
.name     |    n    |    n
getMember |    n    |    n
.tupleof  |    y    |    y

This is what we're now doing in 2.071.2 (see https://github.com/dlang/dmd/pull/6111),

method    | visible | accessible
--------------------------------
.name     |    n    |    n
getMember |    y    |    n
.tupleof  |    y    |    y

and what we plan to do with 2.072 or 2.073.

method    | visible | accessible
--------------------------------
.name     |    n    |    n
getMember |    y    |    y
.tupleof  |    y    |    y

In fact access checks will get removed soon.

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:
>> I don't agree with the current solution:
>
> 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.

Use case that I think is pretty durn important: using Allocator.make and forwarding a call to the private constructor on a class.

This does not work now:
---
class A
{ int b; private this(int a){b=a;} }

  auto ptr = make!A(Mallocator.instance, 42); // Compile Error!
---

Allocators are second class in this respect compared to GC.

Mixins aren't a good solution to this.