On Thursday, 14 November 2013 at 18:23:20 UTC, Andrei
Alexandrescu wrote:
[...]
Natural languages are "humans complete" because they are the
one vehicle we use to describe and manipulate our understanding
of the entire reality. If configurable syntax was something
necessary to model the world, it would have inevitably occurred
in natural languages one way or another. Instead, all human
languages (with no exception I know of) have fixed syntax and
prefer to add modeling power in other ways. There must be
something about this.
Andrei
Not an unreasonable assumption to make, so assuming it's true,
then we need a fixed way to deal with a certain set of problems
that so far cannot be done reasonably (or at all) in current D.
One case, which I also so happen to want to solve, is the
async/await type of problem. There's simply no reasonable
solution available other than through extensions to the language,
which may or may not ever materialize. It's very frustrating when
you want to explore possibilities today rather than wait for an
extension that may never arrive.
Adding in the async/await extensions can help solve only that
specific problem, but how many other types of problems that are
similar to this one will programmers still want to solve? A more
general solution would seem to be far more useful.
The other simple problem I encountered, at first seems like a
mixin can deal with or perhaps a template, but current D simply
cannot do it in a reasonable way that I'm aware of.
I want to be able to pass an argument to an "inspect" function,
that will log or display the symbol name of the top-level
argument and it's corresponding value.
Example:
int a = 300;
inspect( a ); // or inspect!a;
The only way I can do this is through double entry of the item to
inspect
eg
inspect( a.stringof, a ); // error prone and irritatingly
redundant
I can get some success using an alias template parameter, but it
does not work in general, only in a few cases will it work, so
templates are not a solution without some additional enhancements.
May be by adding in something like __ARGS__, or expanding
on__traits can solve this type of problem, but there's no doubt
many other scenarios that will require similar extensions that
users of the language cannot implement. There's no end to this
without much better access to reflection.
--rt
