On Tuesday, 9 April 2019 at 14:59:03 UTC, Adam D. Ruppe wrote:
On Tuesday, 9 April 2019 at 14:42:38 UTC, Alex wrote:
It basically proves my point that there are issues with D.
The language is fine in this case, it is a bug in the library.
I didn't say the language. The point with the language is that it
could have built in semantics to do reflection in a inform
way(__traits is somewhat uniform but messy and then one has
std.traits which then makes it not uniform).
Though, I don't think the library can be fixed because the
language doesn't have facilities to express these things
through libraries.... but I also don't see the point in having
a library at all. You incur compile time and run time costs for
stuff you probably don't need and introduce another layer of
bugs.
There is no runtime costs. The library may not be efficient but
it is a better design. It abstracts most of the crap away and
provides a very natural and uniform interface in to reflection.
Ultimately the compiler itself should provide this information
directly. It has all the information when it compiles and it can
lazily instantiate whatever information it has to calculate when
it is requested. It could be very efficient, it is just doing
what __traits does but more naturally.
Reflection should be a first class semantic in D given D's heavy
meta programming capabilities.
Some of the lower level features are a little weird to see*,
but they are easy to use once you get to know them.
* for example
static if(is(typeof(overload) Params == __parameters))
to get the function parameter list (as the Params variable
there). It is a little weird looking, but it isn't really hard
to use.
The problem is that there is a semantic that supposedly exists to
dot he same but fails. So it is not about weirdness but about
non-uniformity. Why does it have to be that way? There is no
reason, it is also a hack in the compiler. WHy not just wrap that
code with something sane like
Type.Reflect!Parameters
?
This is exactly what my library does and it is a more sane
looking solution. It's that simple. You can't disagree, you know
it looks better(we could argue about the precise syntax but it is
much better and more informative than what you posted).
Also, your snippet is meant to be used, later on, such as in a
for each loop,
when we could do
static foreach(p; Type.Reflect!Parameters)
vs
static if(is(typeof(overload) Params == __parameters))
static foreach(p; Params)
It's 50% savings in both line space and character space, it's
much faster to understand, it is uniform and natural while the
second case is ugly, confusing, and bloated.
My point is that THERE IS NO NEED for such things. It is ALL
about syntax. It's just wrappers. There is no new functionality.
I'm just trying to make things "look" better because things that
"look" better are easier to comprehend. Look better means that
they are more uniform with common practices and experiences and
allow for easier navigation in memory space.
You may be ok with having to remember special cases here and
their... but it is a defect. Suppose you program in 10 languages
regularly, those special cases then are an order of magnitude
more to remember... suppose you do other things with your life.
If you don't and all you do is program D then you don't feel it
as bad, if you do lots of other things then these are speed bumps
that slows one down for no good reason at all(if you have one,
besides, "some one has to code the new syntax and it takes work
to make it better" then I'd like to hear it).
What I see if you justifying bad syntax just to justify it
because it exists. If I'm wrong you just have to give me
meaningful reasons why that is not the case.
I'm not looking to be confrontational, I'm looking to make things
better. If you are right about what you claim then you can back
it up, if not you can't except with fallacious arguments. My mind
is willing to be changed as long as the change is provably good,
else there is no point in going backwards.
I think the only argument you have is "It already exists and
works and is not too bad"... which may be a good enough argument
for you but isn't for me. That type of argument can be used to
prevent progress on anything. "The cave is already exists and
works to keep us sheltered and is not that bad so we don't need
to build a nice house with AC that takes work to do". If all you
have ever lived in is a cave then you can't possibly know if the
house is better. It has to be built first to compare and
contrast. The secret is that there is always something better
than something else and it always should be sought after, at
least theoretically(sure there is the practical issue of time, I
accept that, but I don't accept denial that their isn't something
better).
Hell, as much time that we have spent arguing over this shit we
could have probably created a language feature that we both can
agree is much better and is fast and really has no cons compared
to what exists now.
