phobos

Except defining your types with arbitrary names is still hardware dependent, it's just now something you have to remember or guess. Can you remember the name for a 128 bit integer in your preferred language off the top of your head? I can intuit it in Rust or Zig (and many others). In D it's... oh... it's int128. https://dlang.org/phobos/std_int128.html https://github.com/dlang/phobos/blob/master/std/int128.d

> Good documentation is good as far as it aids understanding. This might be a side effect of tests, but I don't think it's their goal. A good test will catch breaks in behaviour, I'd never trade completeness for readability in tests, in docs it's the reverse. The D language standard library uses both. When you generate the documentation from the comments attached to a declaration, the following unittests (they are identified using a special markup, (that is just triple slashes...) are also included. Example once rendered [0], in the source you see the examples are actually unit tests [1]. [0]: https://dlang.org/phobos/std_algorithm_searching.html#.all [1]: https://github.com/dlang/phobos/blob/master/std/algorithm/se...

This is something I _really_ like about D. Unit-tests are built into the language, as is comment-based documentation—put those two together and you get unit-tests as documentation examples built into the language; all it takes is to put a documentation comment (which can be blank) right before a `unittest` block after a declaration. E.g. the examples for the D standard-library's `curry` function are just unit-tests: the docs: <https://dlang.org/phobos/std_functional.html#quickindex.curr...>; the code: <https://github.com/dlang/phobos/blob/42b8c65ccfd35c863f7cedf...>

I'd take a language that have built in support for tagged union over having to import a module and rely on templates I know of sumtype, and i think it is a mistake for D to rely on this for such important language feature I'm not a language dev, so i can't do much to help, using switch/union/enum is more natural, is cleaner, and is easier to add support for IDEs, everyone on the same page That's in areas like this where the language falls short, and i can see people instead choosing alternatives https://github.com/dlang/phobos/blob/master/std/sumtype.d a mess of templates and imports to std.traits using this will make your compile speed tank.. another reason to avoid it's very sad that people recommend this instead of asking for built-in version, makes me sometimes reconsider my choice to use the language if they expect language improveme

I usually refer to LLVM documentation. You can look at this [1] to begin with. For sample code, etc, I would recommend to read D's atomic primitive implementations [2] instead of C++. C++ standard library is an unreadable monster. Fundamentally C++ atomic types are a flaw as std::atomic<int> is a type by itself, whereas in reality the operations has to be atomic. Also you can't get the value type for the type underneath the std::atomic template. Whereas in D, the operations are atomic and you can operate them on the primitive types. You can see numerous examples in D's standard library implementation (which is readable than C++'s) [3][4] [1] https://llvm.org/docs/Atomics.html [2] https://github.com/dlang/druntime/blob/master/src/core/atomi... [3] https://github.com/dlang/phobos/blob/master/std/concurrency.... [4] https://github.com/dlang/

edit I see I'm too late, Walter already answered this. I'll leave this here anyway. I don't think D's writefln is getting any special treatment from the compiler. It seems to use D's compile-time features to perform the check. https://github.com/dlang/phobos/blob/v2.093.0/std/stdio.d#L4...

$ git init Initialized empty Git repository in /tmp/phobos/.git/ $ git remote add origin https://github.com/dlang/phobos.git $ git fetch --depth=1 origin 6e5cdacfa6ac018c6ef42aa9679893676f293f21 error: no such remote ref 6e5cdacfa6ac018c6ef42aa9679893676f293f21 However, the commit exists: $ git fetch --depth=1000 [... a long time after ...] $ git checkout 6e5cdacfa6ac018c6ef42aa9679893676f293f21 Note: checking out '6e5cdacfa6ac018c6ef42aa9679893676f293f21'. [...] HEAD is now at 6e5cdacf... phobos 0.2

Dealing with timezones and daylight savings time has consumed hundreds of hours of my development time. This seriously should be a standard service of the operating system, not the programming language library. Just look at all the code to deal with it in D (written by Jonathan Davis): https://github.com/dlang/phobos/blob/master/std/datetime.d

Check out https://github.com/D-Programming-Language/phobos/blob/master... at line 33 and on. You'll see: version (Windows) { ... } etc. For the specification on how this works: http://dlang.org/version.html The salient point is that conditional compilation in D is not text based, it is AST based. Furthermore, for 'static if', the conditional expression has access to the full symbol table and power of the D language - it is not a separate preprocessor language with its own rules and separate symbol table.

What a hilarious coincidence. :) I'm guessing you can't go giving out concrete legal advice for free, but could you point us towards languages that are fixing this? I see that Julia's stdlib uses MIT for non-external libraries,[1] and Go uses a BSD-style license that explicitly requires distributing the license with binaries,[2] so they're both in the same boat we are. AFAICT D's stdlib uses the Boost license[3] which explicitly allows one to forgo distributing the license with compiled artifacts, but I don't know if solving this issue entirely would require the entire compiler to be licensed under Boost as well. Presuming that interpreted languages can gracefully ignore this issue, I don't know which other "new" languages we could look at for inspiration. [1] https://github.com/JuliaLang/julia/blob/master/LICENSE.md [2] https://github.co

Have a look at the sourcecode [1]. It is just implemented with an associative array (implemented as hash table) from argument tuples to the return type. This means that keys have to be atomic or provide their to_hash and equality check themselves. Check out the D template system, it is quite impressive what you can express with it. 1: https://github.com/D-Programming-Language/phobos/blob/master...

The standard library (Phobos) is open source. You can find the implementation of memoize at https://github.com/D-Programming-Language/phobos/blob/6cd2e4... memoize is a template (http://dlang.org/template.html). In this case, a template is used to create a "version" of "memoize" with the right parameters and return value (i.e., `fn` and `memoize!fn` are the same type). Each of these "versions" has a hash table from argument tuples to results. I believe the hash is computed by calling a toHash function for each item in the tuple. Tuples and type tuples (http://dlang.org/tuple.html) in D are really quite powerful.

Mixins, at least in D, can be very useful when you want to do some meta-programming (at compile-time, of course). They basically allow you to generate code at compile time. Mixins, together with some other cool D features, like CTFE (compile-time function execution), templates and ability to load external file at compile-time can be used to create DSL compiler which compiles to native code (first to D, than to native, of course). For example, ctRegex from std.regex [1] (standard library regular expressions module) uses mixins to generate D code in compile-time out of regular expression (and D compiler outputs native code for regular expression matching). There is also a PEG parser that works at compile-time (reads external PEG grammar and generates parser code) but I cannot find a link at the moment. Of course, creating DSL parsers is not