observation: D getting a bit complex

[Sergey Korshunoff via Digitalmars-d-learn]

Hi!
I completely agree. D1 is much better :-) I removed a threading
support from my variant  because program don't start if OS don't have
a POSIX threading (LInux 2.4.37 for example). A garbage colllector can
be disabled (as I understand). May be a compiler support (warnings) is
needed if gc will be used (needed) in the code

With such changes D1 can be used for Linux kernel modules. But I don't
done this yet. I nice stuff: libc written in D (a small part of the
uCLibc, not finished)

PS: trying to understand a D backend I removed all stuff related to
the C++ and win32
PPS: what is the rigth way to connect a backed to the frontend? I
studied only d-to-js, d-to-c, d-to-c#, tdc and some version of the D0
compiler with custom asm generator (GDC and LDC are not studied)


2015-08-30 5:42 GMT+03:00, Spacen Jasset via Digitalmars-d-learn
<digitalmars-d-learn at puremagic.com>:
> The following reminds me of the good old C++ template errors the
> C++ compiler spits out.
>
> Whilst D has fixed that problem, some things have gotten more
> complex. I just wanted to find a replacement for D1 path join,
> and found this, but it doesn't seem very easy to wade though this
> stuff.
>
>
> immutable(ElementEncodingType!(ElementType!Range))[]
> buildPath(Range)(Range segments) if (isInputRange!Range &&
> isSomeString!(ElementType!Range));
> pure nothrow @safe immutable(C)[] buildPath(C)(const(C)[][]
> paths...) if (isSomeChar!C);
>
> http://dlang.org/phobos/std_path.html
>
> It would take me a lot of time to appeciate what that all means,
> although I can imagine what it is for.
>
> ...just and observation. The complexity is building.
>