On Saturday, 6 April 2019 at 13:03:31 UTC, Adam D. Ruppe wrote:
On Saturday, 6 April 2019 at 12:20:28 UTC, Alex wrote:
static foreach (f; typeof(__traits(getOverloads, T, m)))
Why are you using typeof here?
I don't know, I want to say I copied that code from somewhere but
it might have been a left over or when I was trying to get the
code to work. Since it partially worked(notice that it "works"
and only gives the errors in parameters).
probably 90% of the mixins are of the form
mixin(`Protection = __traits(getProtection,
(`~T.stringof~`).`~name~`);`);
Try following this rule:
NEVER use .stringof.
rules are meant to be broken. As I mentioned in the other post it
doesn't help when writing the mixin as a pragma to inform one of
the actual type being used.
I'd say the rule is actually crap because of this(if debugging
mixins and meta code had more support it might be a good rule but
it's very helpful to know the type. Sure we can add a pragma(msg,
T) but sometimes I just replace mixin( with pragma(msg, and I
want something more than it display T. I want to see the full
string to make sure it is formatted correctly what what is being
used for T.
What you need to tell me is why using .stringof is bad. You have
simply conjured up a rule and are stating it but not giving any
reason why it is not a good idea to follow when, in fact, not
following can be shown to be beneficial.
You can't expect to lead by authority. Give a good reason why I
should avoid it and change my current ways and I will. Just
telling me to do it won't change my mind.
The only reason I can see why it is a good rule is that one
doesn't have to use T.stringof when they can just use T directly,
making the code a little easier to read.
But I've pointed out that T.stringof has it's use when viewing
the mixin as a string, which overrides your rule if the only
reason is it's not technically needed.
See, it might just be your own bias that makes you not like it
when in reality it might not matter either way. So far it seems
it is your bias but I hope you have a good objective reason why
as it would same a few characters in typing. A good reason is "It
breaks the compiler in these cases" or "It causes this problem
here when you do this".
If it's just about code readability then I will keep using them
and maybe when I get the code in to shape I will try to format it
to take them out. But in that case you have to learn to accept
them in prototyping because then they are useful for
mixin->pragma(msg,
Protection = __traits(getProtection, T.name);
But (unless T.name is private; this is a design flaw in
__traits(getProtection)),
__traits(getProtection, __traits(getMember, T, name))
will work.
Ok, so I used it and it got rid of one error where I get the
protection.
I still get a protection issue for a private field using this
code though:
mixin(`static foreach(a; __traits(getAttributes, T.`~name~`))
Attributes ~= sAttributeReflection(to!string(a),
typeof(a).stringof);`);
So it seems like the same design flaw exists? Have any work
arounds for that?
Thanks for your help!
