Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

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

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

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

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

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...

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

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,

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

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

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

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

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

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

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

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

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

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

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On 09/04/2016 05:51 AM, Andrei Alexandrescu wrote: * Tracing how and when a member mutates. Ali

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

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

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On 9/5/16 10:38 AM, Jacob Carlborg wrote: On 2016-09-04 14:36, 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 Yes: module foo; struct Foo {

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On 2016-09-04 14:51, Andrei Alexandrescu wrote: Of course the more important applications are those I can't yet imagine. The way I see it introspection must have full power and unfettered access. So definitely it must be able to pass through regular protection. * Linking up GUI controls to

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On 2016-09-04 14:36, 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 Yes: module foo; struct Foo { private int a; } module main; import

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Monday, 5 September 2016 at 07:48:11 UTC, Johannes Pfau wrote: Am Sun, 4 Sep 2016 14:54:33 +0200 schrieb Andrei Alexandrescu : On 9/4/16 2:37 PM, David Nadlinger wrote: > [...] Static introspection is by far the most powerful feature of D. The last thing to

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

Am Sun, 4 Sep 2016 14:54:33 +0200 schrieb Andrei Alexandrescu : > On 9/4/16 2:37 PM, 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 > >>

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Sunday, 4 September 2016 at 12:51:05 UTC, Andrei Alexandrescu wrote: See http://forum.dlang.org/post/ymkehalxcigswvltl...@forum.dlang.org There are a few cases I can think of: The classical ones, but again the question was for introspection without access (b/c named access through

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On 9/4/16 2:37 PM, 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

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On 9/4/16 5:45 AM, Martin Nowak wrote: A public setter for private members is weird How do you mean that? It's an absolute classic. Please elaborate, thanks. -- Andrei

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

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

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

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.

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

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

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

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

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

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

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

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

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

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.

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

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

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

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

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

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

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

Am Sun, 04 Sep 2016 03:29:59 + schrieb Martin Nowak : > On Sunday, 4 September 2016 at 03:21:05 UTC, Stefan Koch wrote: > > While I do understand, that there could be a potential > > performance when private members could be changed around > > because they are not visible

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Sunday, 4 September 2016 at 03:45:50 UTC, Martin Nowak wrote: On Saturday, 3 September 2016 at 17:23:53 UTC, Basile B. wrote: 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

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

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

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Saturday, 3 September 2016 at 18:56:33 UTC, Dicebot wrote: Obviously serialization libraries come to mind, especially important for binary serialization because private members still affect the layout of the struct. Let me repeat that another time, private members have never been

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Saturday, 3 September 2016 at 17:23:53 UTC, Basile B. wrote: 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

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Sunday, 4 September 2016 at 03:21:05 UTC, Stefan Koch wrote: While I do understand, that there could be a potential performance when private members could be changed around because they are not visible form outside. I fail to see how we would take advantage of that without breaking our

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Saturday, 3 September 2016 at 17:57:08 UTC, Jonathan M Davis wrote: I do get the feeling that too much of what we do with features like this is ad-hoc without really designing things up front, and then we keep having to tweak stuff as we go along in ways that aren't always particularly

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Sunday, 4 September 2016 at 03:14:18 UTC, Martin Nowak wrote: It didn't slip, but I wish Walter had at least stated his opinion on the PR before merging. My thinking is that the plebes should be able to access things via the object.member syntax by obeying the usual visibility rules.

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Saturday, 3 September 2016 at 20:40:57 UTC, Andrei Alexandrescu wrote: On 9/3/16 7:57 PM, Jonathan M Davis via Digitalmars-d wrote: Previously __traits(allMembers, T) listed _all_ members, whereas now it wil only list the ones that are accessible. The same for __traits(derivedMembers, T).

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On 9/3/16 11: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 Thanks. -- Andrei

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Saturday, 3 September 2016 at 21:54:24 UTC, Jacob Carlborg wrote: Here's the PR that introduced the change: https://github.com/dlang/dmd/pull/6078 I'm certainly not going to upgrade to the next DMD if this change is retained. allMembers not returning all members makes introspection

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

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 -- /Jacob Carlborg

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Saturday, 3 September 2016 at 20:54:19 UTC, Andrei Alexandrescu wrote: On 9/3/16 10:50 PM, Basile B. wrote: On Saturday, 3 September 2016 at 20:40:57 UTC, Andrei Alexandrescu wrote: Martin, any chance we can undo this change to the language? The problem is deeper. If he undoes the change

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On 9/3/16 10:50 PM, Basile B. wrote: On Saturday, 3 September 2016 at 20:40:57 UTC, Andrei Alexandrescu wrote: Martin, any chance we can undo this change to the language? The problem is deeper. If he undoes the change then what will happen again is that the results of allMembers won't be

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Saturday, 3 September 2016 at 20:40:57 UTC, Andrei Alexandrescu wrote: Martin, any chance we can undo this change to the language? The problem is deeper. If he undoes the change then what will happen again is that the results of allMembers won't be usable by the other traits, e.g

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On 9/3/16 7:57 PM, Jonathan M Davis via Digitalmars-d wrote: Previously __traits(allMembers, T) listed _all_ members, whereas now it wil only list the ones that are accessible. The same for __traits(derivedMembers, T). So, they'll still give you the private members if you use them inside the

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On 2016-09-03 20:56, Dicebot wrote: Obviously serialization libraries come to mind, especially important for binary serialization because private members still affect the layout of the struct. That can usually be solved using .tupleof[i], but I agree. -- /Jacob Carlborg

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On 2016-09-03 17:50, Martin Nowak wrote: It will, e.g. having getMember bypass protection means vibe.d would now serialize private members https://github.com/rejectedsoftware/vibe.d/blob/c1180791de61d0f8c9bfb584c2551a5b64627e32/source/vibe/internal/meta/traits.d#L146. Until now getMember was

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On 09/03/2016 07:52 PM, 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

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Saturday, September 03, 2016 19:30:54 Andrei Alexandrescu via Digitalmars-d wrote: > On 9/3/16 6:39 PM, Andrej Mitrovic via Digitalmars-d wrote: > > On 9/3/16, Martin Nowak via Digitalmars-d wrote: > >> On Wednesday, 31 August 2016 at 13:12:30 UTC, Adam D. Ruppe

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On 9/3/16 6:39 PM, Andrej Mitrovic via Digitalmars-d wrote: On 9/3/16, Martin Nowak via Digitalmars-d wrote: On Wednesday, 31 August 2016 at 13:12:30 UTC, Adam D. Ruppe wrote: Ugh, it really should just give everything and have getMember bypass it. That won't even

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

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

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

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.

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On 9/3/16, Martin Nowak via Digitalmars-d wrote: > On Wednesday, 31 August 2016 at 13:12:30 UTC, Adam D. Ruppe wrote: >> Ugh, it really should just give everything and have getMember >> bypass it. That won't even break any code! > > It will, e.g. having getMember

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Wednesday, 31 August 2016 at 21:12:54 UTC, Ali Çehreli wrote: On 08/30/2016 03:24 PM, Ali Çehreli wrote: > v2.071.2-b3 is bringing a change for this bug: > > https://issues.dlang.org/show_bug.cgi?id=15907 > > I don't agree with the current solution: > >

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Saturday, 3 September 2016 at 15:48:24 UTC, ketmar wrote: just a wrapper class, which will hold the actual instantiation and a scope. most of the code should "pass thru" the wrapper (i thing that `alias this` can be used for that, but have to check it), yet `__traits` can use additional

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Thursday, 1 September 2016 at 19:30:41 UTC, Basile B. wrote: https://github.com/dlang/DIPs/pull/39 Co-authors welcome. Slow down a bit until we've finally decided out how to resolve the problems.

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Wednesday, 31 August 2016 at 13:12:30 UTC, Adam D. Ruppe wrote: Ugh, it really should just give everything and have getMember bypass it. That won't even break any code! It will, e.g. having getMember bypass protection means vibe.d would now serialize private members

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Saturday, 3 September 2016 at 14:48:54 UTC, Martin Nowak wrote: On Wednesday, 31 August 2016 at 05:33:50 UTC, ketmar wrote: all this mess should be resolved in compiler by assigning template *two* visibility scopes: one is template's "normal" scope (so it can see symbols from it's

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Tuesday, 30 August 2016 at 22:24:12 UTC, Ali Çehreli wrote: I can't wrap my head around the fact that a library template called by my module cannot see my private members. Well, it was never possible to access them either, didn't seem to cause much confusion. Also getSymbolsByUDA is built

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Wednesday, 31 August 2016 at 05:33:50 UTC, ketmar wrote: all this mess should be resolved in compiler by assigning template *two* visibility scopes: one is template's "normal" scope (so it can see symbols from it's originating module), and second is it's "instantiation" scope. after all,

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Wednesday, 31 August 2016 at 13:29:52 UTC, Basile B. wrote: On Wednesday, 31 August 2016 at 13:12:30 UTC, Adam D. Ruppe wrote: Ugh, it really should just give everything and have getMember bypass it. That won't even break any code! you're right. "allMembers" means "all" after all. Another

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On 08/30/2016 03:24 PM, Ali Çehreli wrote: > v2.071.2-b3 is bringing a change for this bug: > > https://issues.dlang.org/show_bug.cgi?id=15907 > > I don't agree with the current solution: > > http://dlang.org/changelog/2.071.2.html#traits-members-visibility > > Modules should be able to use

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Tuesday, August 30, 2016 15:24:12 Ali Çehreli via Digitalmars-d wrote: > v2.071.2-b3 is bringing a change for this bug: > >https://issues.dlang.org/show_bug.cgi?id=15907 > > I don't agree with the current solution: > >http://dlang.org/changelog/2.071.2.html#traits-members-visibility > >

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Wednesday, 31 August 2016 at 13:12:30 UTC, Adam D. Ruppe wrote: Ugh, it really should just give everything and have getMember bypass it. That won't even break any code! you're right. "allMembers" means "all" after all. Another reason why the idea of "allVisibleMembers" is good. Puristes

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Wednesday, 31 August 2016 at 08:33:28 UTC, Ethan Watson wrote: That's how it used to work, but getProtection would fail if the symbol wasn't public. Which led to me using a workaround to something of this effect: Yeah, I kinda regret the design of getProtection (which is basically 100% my

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

Ugh, it really should just give everything and have getMember bypass it. That won't even break any code!

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Wednesday, 31 August 2016 at 09:30:43 UTC, Ethan Watson wrote: I'm okay with this. My PrivacyLevel workaround does exactly this in fact. I keep forgetting that I'm all open sourced now and can just link directly to the full example.

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Wednesday, 31 August 2016 at 09:25:52 UTC, Basile B. wrote: nice idea, but this doesn't change the fact that the traits that access the results of the "omniscient" allMember must be tweaked to access everything. I'm okay with this. My PrivacyLevel workaround does exactly this in fact.

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Wednesday, 31 August 2016 at 08:36:37 UTC, Ethan Watson wrote: On Tuesday, 30 August 2016 at 22:24:12 UTC, Ali Çehreli wrote: I don't agree with the current solution: I'm somewhat surprised myself that "allMembers doesn't return all members" needs highlighting. Why not have a new trait

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Tuesday, 30 August 2016 at 22:24:12 UTC, Ali Çehreli wrote: I don't agree with the current solution: I'm somewhat surprised myself that "allMembers doesn't return all members" needs highlighting. Why not have a new trait "allVisibleMembers" and just fix the privacy issues?

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Wednesday, 31 August 2016 at 08:06:05 UTC, Basile B. wrote: allow them to see everything, then use "getProtection" if you wanna be conform with the protection attributes. That's how it used to work, but getProtection would fail if the symbol wasn't public. Which led to me using a

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Tuesday, 30 August 2016 at 22:46:58 UTC, Basile B. wrote: On Tuesday, 30 August 2016 at 22:24:12 UTC, Ali Çehreli wrote: v2.071.2-b3 is bringing a change for this bug: Yes I agree, a change of the specifications in a dot release seems a bit extreme, especially since there was a deeper

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On 2016-08-31 02:16, Andrej Mitrovic via Digitalmars-d wrote: PSA: If all one cares about are UDAs for fields and not functions then .tupleof is still a viable workaround. Working example: - import getSymbols; enum UDA; struct S { @UDA float visible; float dont_care;

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On 2016-08-31 01:01, Andrej Mitrovic via Digitalmars-d wrote: This is such a bizarre workaround to be listed in the changelog since mixing in non-mixin templates is not an official feature (am I wrong?). Yes. Originally one could not use the "mixin" keyword in front of a template. There was

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Tuesday, 30 August 2016 at 22:24:12 UTC, Ali Çehreli wrote: yeah, the whole feature smells for me. the sole need of mixin hack indicates that something is very wrong here. i never ever needed that for normal D code. and now suddenly i have to remember that some thing is a template, that it

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On 8/31/16, Ali Çehreli via Digitalmars-d wrote: > v2.071.2-b3 is bringing a change for this bug: > >https://issues.dlang.org/show_bug.cgi?id=15907 PSA: If all one cares about are UDAs for fields and not functions then .tupleof is still a viable workaround.

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On 8/31/16, Ali Çehreli via Digitalmars-d wrote: > mixin getSymbolsByUDA!(S, UDA) symbols; This is such a bizarre workaround to be listed in the changelog since mixing in non-mixin templates is not an official feature (am I wrong?). getSymbolsByUDA is a template, not

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Tuesday, 30 August 2016 at 22:24:12 UTC, Ali Çehreli wrote: v2.071.2-b3 is bringing a change for this bug: https://issues.dlang.org/show_bug.cgi?id=15907 I don't agree with the current solution: http://dlang.org/changelog/2.071.2.html#traits-members-visibility Modules should be able

Usability of "allMembers and derivedMembers traits now only return visible symbols"

v2.071.2-b3 is bringing a change for this bug: https://issues.dlang.org/show_bug.cgi?id=15907 I don't agree with the current solution: http://dlang.org/changelog/2.071.2.html#traits-members-visibility Modules should be able to use library templates without needing to mix them in first.