On Tuesday, 9 April 2019 at 21:00:55 UTC, H. S. Teoh wrote:
> On Tue, Apr 09, 2019 at 08:49:17PM +0000, Alex via Digitalmars-d-learn wrote:
>> On Tuesday, 9 April 2019 at 18:56:58 UTC, H. S. Teoh wrote:
> [...]
>> My point has been and is that there is a better way that is more natural.  I make no claims about anything else. It may be a cop out to say something that is a tautology but I make the claim as an emphasis that I believe that it is more true in this case than others. i.e., D's traits are PITA. Ok, they are not as bad as some things but I know they can be better since I have used other languages that have far more logical reflection(such as C#) than D.
>
> As I said, __traits was never designed to be user-friendly, or even "logical".  It was supposed to be a quick-and-easy way to tap into compiler internals, and std.traits was supposed to be the proper API to introspection.  But std.traits, as it stands, is far, far from what it ought to be, and so we have today's sorry situation.

That's unfortunate... but at least they are generally pretty functional. I remember trying to do basic type comparisons in C#'s reflection and didn't have the capability(I think it got it later but I believe that was the time I left for D).

I can understanding adding traits int he way it was, but at some point it has to be brought to the same standard as the rest of the language. It's just far too important to neglect. After all, Even most of phobos is using meta programming.

> (And on a side note: don't even get me started on is(...) expressions.)
>
> Anyway, since you seem to be passionate about this, this could be your chance of making std.traits what it ought to have been all along, or making a sensible reflection library that can for all practical purposes replace std.traits.
>

The problem is, I believe to do it right, it should be done in the compiler(at least some changes) and I know virtually nothing about the design and internals, so it would be much more time consuming than I'd like). I feel if I were going to go down that route I'd rather spend time writing a compiler or getting better as functional programming.

> I, for one thing, would appreciate a nicer API to introspection than what we currently have.  One of the main things that drew me to D was its metaprogramming capabilities, and while overall it has been a positive experience, there *are* flies in the ointment like __traits, is(...) expressions, etc..  If you or somebody else could come up with a saner way to do introspection in D, it'd be very much appreciated.

Basically same here. D is one of those love/hate relationships ;/ Meta programming is the next stage of evolution of programming. It is necessary for simplifying the complex problems of the modern computing world. D does have quite a nice syntax for most of this and does reasonably well(Although I believe functional programming blows D's type system out the water since it deals with structural mapping directly without "special cases").

On Wednesday, 10 April 2019 at 19:29:13 UTC, Alex wrote:
> I wonder if there are some interesting patterns of nesting is's?
>
> is(...is(...is(...)...)...)

No, at least not like that. You'd get nothing out of it, even if you made it work.

But, I have in the past nested static ifs with different is things in order to handle very complex patterns that are difficult to express in one.

I can't remember what those are right now though... but if one level fails, you might do

static if(is( something ))
  static if(is( details )) {

  }

to drill down. But while I know I have done this before, it is rare enough that I cannot recall it!

On Wed, Apr 10, 2019 at 11:05:27PM +0000, Adam D. Ruppe via Digitalmars-d-learn wrote:
> On Wednesday, 10 April 2019 at 19:29:13 UTC, Alex wrote:
> > I wonder if there are some interesting patterns of nesting is's?
> > 
> > is(...is(...is(...)...)...)
> 
> No, at least not like that. You'd get nothing out of it, even if you made it work.
> 
> But, I have in the past nested static ifs with different is things in order to handle very complex patterns that are difficult to express in one.
> 
> I can't remember what those are right now though... but if one level fails, you might do
> 
> static if(is( something ))
>   static if(is( details )) {
> 
>   }
> 
> to drill down. But while I know I have done this before, it is rare enough that I cannot recall it!

It happens when your static if condition has two or more clauses, and the compilability of one of the later clauses depend on the truth of a previous clause. Static if conditions do respect && short-circuit evaluation, but they do not allow you to bypass compilability, so if you have something like:

	static if (A & B) { ... }

where B is not compilable unless A is true, then you cannot write it this way, and have to nest it like you wrote above.


T

-- 
We've all heard that a million monkeys banging on a million typewriters will eventually reproduce the entire works of Shakespeare.  Now, thanks to the Internet, we know this is not true. -- Robert Wilensk