Only now I found that most of my confusions are with D's compile
time grammar or features. As an excuse, my confusions can be
partially attributed to the way D is presented:
1. There are confusing keywords:
For example, there is a "if", there is also a "static if", there
is a "if", and there is an "is()". For new learners like me, they
cause confusion at least uneasiness.
2. Compile time grammar spreads among runtime grammar
Most documents present D's compile time grammar and runtime
grammar in the same time. It made me feel that D's grammar is not
consistent because compile time grammar seem to be exceptions
from runtime grammar. If a document talks exclusively about
runtime grammar first, and
introduces compile time grammar late, I think this will make
readers accept those seemingly conflicting grammar. In fact
without introducing compile time grammar, D is much similar to
other languages, in this way the readers from other languages can
find D more friendly.
With the understanding of D's compile time grammar, I can read D
codes from other projects such as std packages, but I am still
not easy about the way that D's compile time codes are not
clearly distinguished from runtime codes. I am wondering if it is
a good idea to clearly indicate those compile time codes with a
special identifier say "@ct", or prefix "__" as in __traints, if
so then those "inconsistencies" can be resolved as follows:
static if -> @ct if
static assert" -> @ct assert
enum fileName = "list.txt" -> @ct fileName = "list.txt"
is (string[void]) -> @ct is (string[void])
mixin(`writeln("Hello World!");`) -> @ct `writeln("Hello
World!");`
So this post is not quite a question, just a thought in my mind
after I am able to differentiate compile time codes from runtime
codes.
