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@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. >