Implement issue# 16485. Add trait for testing if a member is static. #4834

jmdavis · 2016-10-03T18:59:51Z

isStaticMember tests whether a member of a struct or class is static or
not. It works with both functions and variables.

This has come up several times lately, and it definitely seems like we need something like this in std.traits. Technically, issue# 16485 is for adding a trait for testing for a static variable whereas this works with both functions and variables, but they should be distinguishable via __traits(isStaticFunction, ...). The most recent discussion on this is

http://forum.dlang.org/post/mailman.810.1475501243.2994.digitalmars-d@puremagic.com

The tests are a slightly expanded version of what Manu proposed there.

Temtaime · 2016-10-03T19:43:14Z

template isStaticMember(T, string member) if (__traits(hasMember, T, member))

Seems better

UplinkCoder · 2016-10-03T20:31:18Z

std/traits.d

+
+        static if (__traits(isStaticFunction, sym))
+            enum bool isStaticMember = true;
+        else static if (is(FunctionTypeOf!sym == function) &&


wrap the other checks inside a static if(is(sym == function)) to avoid templates for the most common case.

jmdavis · 2016-10-04T02:55:52Z

Okay. I updated the code per the comments here and in the newsgroup.

TurkeyMan · 2016-10-04T05:19:37Z

std/traits.d

+    static if (is(typeof(sym) == function) || is(FunctionTypeOf!(typeof(&sym)) == function))
+        enum bool isStaticMember = __traits(isStaticFunction, sym);
+    else
+        enum bool isStaticMember = __traits(compiles, &sym);


Why use compiles instead of is(typeof(&sym))?

I'm not sure that it matters in this case, but there are subtle differences between the two, and I've been advised in the past to favor __traits(compiles, ...). If I understand correctly, the main difference is that __traits(compiles, ...) actually checks for compilation, whereas is(typeof(...)) just checks that the type exists (e.g. there was a discussion on it here with Don: https://issues.dlang.org/show_bug.cgi?id=8339 ). __traits(compiles, ...) is also more explicit about what you're doing. So, I generally try to use __traits(compiles, ...) instead of is(typeof(...)). I confess though that I don't understand the subtleties well enough to know when it really matters.

Feels like a weird recommendation. I wonder if there is a compiler workload difference?
I have a very poor feel for what things the compiler does quickly, and which are high-impact on compile time.

Andrei was the one who recommended the traits option to me, so you can probably ask him

@TurkeyMan there is almost no difference.

In cases where this does hit your compile times you need a high n.
In such cases template instanciation cost will shadow everything else.

What does 'accurate' mean? I've seen a bunch of weird recommendations emerging... they're not written anywhere. Are people just supposed to know?

@TurkeyMan It's more or less folk knowledge that's passed around. I don't think it's documented anywhere other than various forum threads. That said, it is definitely better to use __traits(compiles).

It's more or less folk knowledge that's passed around.

Right, and that's absolutely not okay! We're meant to be attracting new users. The meta experience is D's main offering, and new users should be able to get working and feel powerful with as little friction as possible. "Oh, yeah that obvious thing to type isn't actually what you do, you need to do this awkward unintuitive thing instead" is not something that's okay to say to new users.

I'm not claiming it's obvious or ideal 😉 Just letting you know how things are.

isStaticMember tests whether a member of a struct or class is static or not. It works with both functions and variables.

jmdavis · 2016-10-08T11:09:51Z

I figured out how to make FunctionTypeOf unnecessary and make it even shorter (by using __traits(getOverloads, ...)), so I just updated the PR with that change. In spite of the surprising amount of effort required to figure out how to do this right, the actual implementation has gotten to the point that it's quite simple.

PetarKirov

Nice work!

TurkeyMan

LGTM

JackStouffer · 2016-10-26T09:00:52Z

Needs a changelog entry

JackStouffer · 2016-10-26T09:04:27Z

Wait, __gshared functions don't have context pointers but shared functions do? I don't see any hard info in the spec on what __gshared means for member functions so any clarification would be appreciated.

aG0aep6G · 2016-10-26T12:08:58Z

Wait, __gshared functions don't have context pointers but shared functions do? I don't see any hard info in the spec on what __gshared means for member functions so any clarification would be appreciated.

http://dlang.org/spec/attribute.html#gshared: "__gshared may also be applied to member variables and local variables. In these cases, __gshared is equivalent to static, except that the variable is shared by all threads rather than being thread local."

In contrast, shared does not imply static.

JackStouffer · 2016-10-26T12:13:29Z

_gshared may also be applied to member variables and local variables. In these cases, __gshared is equivalent to static, except that the variable is shared by all threads rather than being thread local.

Ok thanks.

Also, what's the reason to use strings to do isStaticMember(S, "g") rather than isStaticMember(S.g)?

jmdavis · 2016-10-27T10:12:11Z

Also, what's the reason to use strings to do isStaticMember(S, "g") rather than isStaticMember(S.g)?

Because that's what you get from __traits(allMembers, T).

JackStouffer · 2016-10-27T10:45:30Z

std/traits.d


+/++
+    Whether the symbol represented by the string, member, is a static member of
+    T.


Needs params and returns

wilzbach · 2016-12-27T12:58:21Z

Needs a changelog entry

This will be automatically generated if it's detected by the Dlang Bot.

@jmdavis if you remove # from the commit message the Dlang Bot can detect it. Also if you use close or other it can do more magic, so instead of:

Implement issue# 16485 ...

this would allow it to do it's magic (auto-linking, closing, adding to the changelog):

Fix issue 16485 ...

wilzbach · 2017-02-17T10:15:23Z

Closing as @sprinkle131313 has "revived" this at #5112

UplinkCoder reviewed Oct 3, 2016

View reviewed changes

jmdavis force-pushed the isStaticMember branch 2 times, most recently from 992dbb8 to 1d9b6b9 Compare October 4, 2016 02:54

jmdavis force-pushed the isStaticMember branch from 1d9b6b9 to 13b3bd3 Compare October 4, 2016 04:29

TurkeyMan reviewed Oct 4, 2016

View reviewed changes

jmdavis force-pushed the isStaticMember branch from 13b3bd3 to 7c81234 Compare October 5, 2016 09:44

Implement issue# 16485. Add trait for testing if a member is static.

e0ab406

isStaticMember tests whether a member of a struct or class is static or not. It works with both functions and variables.

jmdavis force-pushed the isStaticMember branch from 7c81234 to e0ab406 Compare October 8, 2016 11:06

PetarKirov approved these changes Oct 24, 2016

View reviewed changes

TurkeyMan approved these changes Oct 24, 2016

View reviewed changes

JackStouffer added the Severity:Enhancement label Oct 26, 2016

JackStouffer added the @andralex label Oct 26, 2016

JackStouffer reviewed Oct 27, 2016

View reviewed changes

std/traits.d

/++

Whether the symbol represented by the string, member, is a static member of

T.

Copy link

Contributor

JackStouffer Oct 27, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs params and returns

skl131313 mentioned this pull request Feb 10, 2017

Issue 16485 - Add trait for testing if a member is static. #5112

Merged

wilzbach closed this Feb 17, 2017

jmdavis deleted the isStaticMember branch May 5, 2017 10:37

Uh oh!

Implement issue# 16485. Add trait for testing if a member is static. #4834

Implement issue# 16485. Add trait for testing if a member is static. #4834

Uh oh!

Conversation

jmdavis commented Oct 3, 2016

Uh oh!

Temtaime commented Oct 3, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jmdavis commented Oct 4, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jmdavis commented Oct 8, 2016

Uh oh!

PetarKirov left a comment

Choose a reason for hiding this comment

Uh oh!

TurkeyMan left a comment

Choose a reason for hiding this comment

Uh oh!

JackStouffer commented Oct 26, 2016

Uh oh!

JackStouffer commented Oct 26, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

aG0aep6G commented Oct 26, 2016

Uh oh!

JackStouffer commented Oct 26, 2016

Uh oh!

jmdavis commented Oct 27, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wilzbach commented Dec 27, 2016

Uh oh!

wilzbach commented Feb 17, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

Temtaime commented Oct 3, 2016 •

edited

Loading

JackStouffer commented Oct 26, 2016 •

edited

Loading