Re: Release D 2.074.0
On 4/10/2017 4:56 PM, Ivan Kazmenko wrote: I noticed that the backend license in this release (at least the Windows .7z version) is still the same, as well as the license.txt file at its root. Is it that there was simply not enough time to reflect the recent changes? And after the changes are incorporated, do you plan to alter the license texts in the previous releases as well? The announcement of the license change came too late for the release. However, the license change does retroactively apply to previous releases. The next update to the release will incorporate the new license.
Re: Release D 2.074.0
On Monday, 10 April 2017 at 20:09:40 UTC, Martin Nowak wrote: Glad to announce D 2.074.0. [...] http://dlang.org/download.html http://dlang.org/changelog/2.074.0.html Thank you for producing the releases! I noticed that the backend license in this release (at least the Windows .7z version) is still the same, as well as the license.txt file at its root. Is it that there was simply not enough time to reflect the recent changes? And after the changes are incorporated, do you plan to alter the license texts in the previous releases as well? Ivan Kazmenko.
Re: Release Candidate 2.074.0-rc1
On Monday, 10 April 2017 at 20:16:29 UTC, Martin Nowak wrote: Unfortunately too late. As usual, just make sure that changes end up in stable before the release. We do check all PRs that target stable or are in a milestone. You didn't get my messages on slack about the backend license, then :-( I'd assumed that was the fastest way to reach you -- I should have filed an issue sooner.
Release vibe.d 0.7.31
This release is a backport release of the smaller changes that go into 0.8.0. The 0.7.x branch will continue to be maintained for a short while, but only bug fixes will be included from now on. Applications should switch to the 0.8.x branch as soon as possible. Main changes over 0.7.30: - Compiles on the latest DMD version (2.068.x-2.072.0) - Introduces a number of forward compatibility declarations for the 0.8.0 branch and vibe-core - The HTTP server received various improvements - All changes: https://vibed.org/blog/posts/vibe-release-0.7.31 DUB package: https://code.dlang.org/packages/vibe-d/0.7.31
Re: fluent-asserts released
On Monday, 10 April 2017 at 14:15:45 UTC, Szabo Bogdan wrote: On Monday, 10 April 2017 at 12:54:43 UTC, Jacob Carlborg wrote: On 2017-04-09 15:30, Szabo Bogdan wrote: Hi! I just made an update to my fluent assert library. This is a library that allows you to write asserts in a BDD style. Right now, it contains only asserts that I needed in my projects and I promise that I will add more in the future. I would really appreciate any feedback that you can give me. https://code.dlang.org/packages/fluent-asserts This looks awesome. Why haven't I seen that before. Can it be used with unit-threaded? I did not tested it with unit-threaded, but when an assert fails it throws an exception so it should work with any test runner It'll work, but it won't end up reporting it the same way. If you'd like that to work seamlessly it's a question of having `version(Have_unit_threaded)` (or however it is it's spelled) that imports and throws `unit_threaded.should.UnitTestException`. Then Bob's your uncle. Atila
Re: D support for the Meson build system
On 04/10/2017 02:41 PM, Matthias Klumpp wrote: > On Monday, 10 April 2017 at 12:10:41 UTC, Russel Winder wrote: >> On Mon, 2017-04-10 at 08:39 +, Atila Neves via Digitalmars-d- >> announce wrote: >>> […] >>> >>> As far as I know the only build system that does this by default for >>> D is reggae. >> >> I will be adding a new builder to the SCons D tools to do whole source >> and per package compiling – to add to the module at a time compiling. >> It would be good to add this for CMake-D and the D support in Meson. > > I am not buying the necessity of not-splitbuilding for optimizations > yet. If that would be the case, how do optimizations work with projects > using GCC/Clang where splitbuilding is the default and often only option > (like Mesa, Linux, lots of scientific stuff). The argument is not so much about optimization (which can be obtained via LTO as well), but primarily about build speed. Turns out that recompiling 10 modules at once (a whole package) is often faster than doing 3 single-module compilations when each of the 3 modules imports the same 4 modules. 10 < 3 + 3 * 4 Sure the latter is parallelizable, but a lot of computation is wasted repeating the same work. dmd has another build mode `-c` with multiple source files producing multiple object files, but that mode is fundamentally broken, b/c template instances are only emitted to one of the object files, leading to funny linker errors when rebuilding only some modules. We kinda know how to fix this (without resorting to `-allinst`), but it's a lot of work, and splitting into subpackages simply works, is fast, and can be parallelized as well. -Martin
Re: fluent-asserts released
On Monday, 10 April 2017 at 17:38:14 UTC, jmh530 wrote: On Sunday, 9 April 2017 at 13:30:54 UTC, Szabo Bogdan wrote: Hi! I just made an update to my fluent assert library. This is a library that allows you to write asserts in a BDD style. Right now, it contains only asserts that I needed in my projects and I promise that I will add more in the future. I would really appreciate any feedback that you can give me. https://code.dlang.org/packages/fluent-asserts Thanks! I got really confused looking at the examples until I realized that should returns a struct. You might add an approxEqual for ShouldNumeric. If you have floating point numbers, it's usually more helpful than equal is. thanks! I added 2 issues for your sugestion. I also found some bugs that I will fix in the next release.
Re: Release Candidate 2.074.0-rc1
On 04/10/2017 09:42 PM, Joseph Rushton Wakeling wrote: > Reported at https://issues.dlang.org/show_bug.cgi?id=17317 but I'm also > highlighting it here since I think it's important: > > The backend license change has not yet been applied to the 2.074.0 > branch. It would seem like a very, very good idea to make sure this > happens. Unfortunately too late. As usual, just make sure that changes end up in stable before the release. We do check all PRs that target stable or are in a milestone. Feel free to cherry-pick this to stable for 2.074.1. -Martin
Release D 2.074.0
Glad to announce D 2.074.0. This release comes with a compile-time-checked writefln/formattedWrite, plenty of phobos additions, and a new std.experimental.checkedint module. See the changelog for more details. http://dlang.org/download.html http://dlang.org/changelog/2.074.0.html -Martin
Re: Release Candidate 2.074.0-rc1
On Saturday, 8 April 2017 at 13:16:44 UTC, Martin Nowak wrote: First release candidate for 2.074.0. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.074.0.html Please report any bugs at https://issues.dlang.org Reported at https://issues.dlang.org/show_bug.cgi?id=17317 but I'm also highlighting it here since I think it's important: The backend license change has not yet been applied to the 2.074.0 branch. It would seem like a very, very good idea to make sure this happens.
Re: InfoWorld article on the open sourcing of dmd
On Mon, Apr 10, 2017 at 11:15:41AM -0700, Jonathan M Davis via Digitalmars-d-announce wrote: > On Monday, April 10, 2017 09:24:16 Andrei Alexandrescu via Digitalmars-d- > announce wrote: > > http://www.infoworld.com/article/3188427/application-development/free-at-l > > ast-d-languages-official-compiler-is-open-source.html > > Hmmm. This article makes it sound like all of dmd was closed-source > rather than just the backend, and it would be easy to come away > thinking that Symantec created D. :| > > Well, at least it's helping get the word out that dmd is fully > open-source now. [...] Typical news source oversimplifying the issue. But at least it's getting the word out. No coverage is bad coverage, after all. T -- Valentine's Day: an occasion for florists to reach into the wallets of nominal lovers in dire need of being reminded to profess their hypothetical love for their long-forgotten.
Re: D support for the Meson build system
On Mon, Apr 10, 2017 at 05:56:38PM +, Matthias Klumpp via Digitalmars-d-announce wrote: > On Monday, 10 April 2017 at 15:27:25 UTC, Russel Winder wrote: [...] > > My thought for SCons was to delegate the package fetching to Dub as > > a subprocess or write some Python to use the Dub API. I'm not clear > > on that as yet, the issue is whether the Dub local source repo is > > the right way forward – using Dub for preparing the compiled > > artefact is likely not the right way forward for SCons. This would > > then make it easy to do something for Rust/Cargo – except that SCons > > doesn't really support Rust yet, and with Cargo are there any Rust > > users not using Cargo. > > > > Having said all this SCons stuff, if there was Meson support for > > this "get the source from the Dub repository, compile it and make it > > a dependency" I'd likely stay with Meson for my codes. > > SCons is considered evil, last time I checked ^^ => > https://wiki.debian.org/UpstreamGuide#line867 > (unless it's used right, which seems to be hard) - I have no idea > though on whether the issues with it were fixed, the entry on SCons > hasn't been updated in a while. I use SCons exclusively for my D projects, and haven't faced any major problems. I understand, however, that from a distro's POV, it can be annoying to work with if you're not familiar with how to patch SConstruct scripts to do what is needed. It's true that unless upstream explicitly supports installation targets, SCons won't do it for you. I do actually maintain a Debian package that uses SCons (well, written by yours truly, so perhaps that's cheating), and I did find that I have to write rules explicitly for supporting installation targets just so it will work properly with Debian's packaging scripts. As for SONAME support (mentioned by the wiki), I'm not sure what the big deal is... isn't it just a matter of passing the right linker flags to the compile command? So either adding something to CFLAGS or LDFLAGS in the construction environment should do the trick. SCons refusing to pick up settings from the user's environment can be annoying to distros, but in return for that, it gives you 100% reproducible (incremental!) builds by default, whereas most Makefiles require you to `make clean` just to be sure, to the point that it has become accepted practice to always "build from clean" because otherwise you just never know. Even Debian's packaging scripts have a `clean` target because of this. But in an SCons-based package, the `clean` target is a one-liner `scons -c`, since SCons knows what targets it has produced and practically guarantees you're back to a clean slate. Even though that's actually unnecessary to produce a good build! (Ironically, leaving the `clean` rule blank causes the packaging scripts to complain because they notice stray files lying around, obviously a feature written with a Makefile mindset because stray files are problematic in Makefile-based projects, but hardly worth attention in an SCons-based project!) T -- Curiosity kills the cat. Moral: don't be the cat.
Re: InfoWorld article on the open sourcing of dmd
On Monday, April 10, 2017 09:24:16 Andrei Alexandrescu via Digitalmars-d- announce wrote: > http://www.infoworld.com/article/3188427/application-development/free-at-l > ast-d-languages-official-compiler-is-open-source.html Hmmm. This article makes it sound like all of dmd was closed-source rather than just the backend, and it would be easy to come away thinking that Symantec created D. :| Well, at least it's helping get the word out that dmd is fully open-source now. - Jonathan M Davis
Re: D support for the Meson build system
On Monday, 10 April 2017 at 18:11:44 UTC, Russel Winder wrote: [...] I'll look to ensuring my facts are correct, and then find out where to put an issue about this – I am assuming a GitHub repository with issues . Just file one at https://github.com/mesonbuild/meson/issues - it might even be that Meson supports this already, the project is moving so fast it's really hard to keep up with all the changes (Mesa and X investigating using it boosted it's development quite a bit, and it was really fast even before).
Re: D support for the Meson build system
On Mon, 2017-04-10 at 17:56 +, Matthias Klumpp via Digitalmars-d- announce wrote: > […] > > That's pretty cool! One way to do this with Meson is to spawn a > shell script as custom target, but that obviously sucks. It might > be worth reporting this as issue upstream, with a concrete > usecase like this, the Meson maintainers will highly likely add > support for it. > One could also always write a plugin as a last resort. > > > […] I'll look to ensuring my facts are correct, and then find out where to put an issue about this – I am assuming a GitHub repository with issues . -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: D support for the Meson build system
On Mon, 2017-04-10 at 17:56 +, Matthias Klumpp via Digitalmars-d- announce wrote: > […] > SCons is considered evil, last time I checked ^^ => > https://wiki.debian.org/UpstreamGuide#line867 > (unless it's used right, which seems to be hard) - I have no idea > though on whether the issues with it were fixed, the entry on > SCons hasn't been updated in a while. Given that some of the "facts" there are actually wrong, I think we can infer Debian people assume Autotools is all that is needed and are uninterested in new things. SCons has supported sonames for a while, for example. Prejudice in these things, as in all things, tends to get reified and become unalterable fact. This no longer worries me. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
The Strange Loop Call for Presentations
https://thestrangeloop.com/cfp.html Track of interest: Languages - functional programming, logic programming, dynamic/scripting languages, new or emerging languages (and of course others depending on domain). Andrei
InfoWorld: Free at last! D language's official compiler is open source
http://www.infoworld.com/article/3188427/application-development/free-at-last-d-languages-official-compiler-is-open-source.html
Re: D support for the Meson build system
On Monday, 10 April 2017 at 15:27:25 UTC, Russel Winder wrote: On Mon, 2017-04-10 at 12:41 +, Matthias Klumpp via Digitalmars-d- announce wrote: […]. I am not buying the necessity of not-splitbuilding for optimizations yet. If that would be the case, how do optimizations work with projects using GCC/Clang where splitbuilding is the default and often only option (like Mesa, Linux, lots of scientific stuff). I am investigating this architecture because Chapel code cannot really be compiled separately as far as I can see. cf. http://chapel.cray.com/ Chapel is a PGAS language (like X10) for use with Big Computation™ on serious computers and also any computer. I'm interested as a way of connecting Python visualisation to computation that NumPy can't really handle. That's pretty cool! One way to do this with Meson is to spawn a shell script as custom target, but that obviously sucks. It might be worth reporting this as issue upstream, with a concrete usecase like this, the Meson maintainers will highly likely add support for it. One could also always write a plugin as a last resort. It seems sensible therefore to offer this way of working for D since whether there is actually any optimisation benefit or not some people think there is and use it as a stick to beat you with if it isn't there. Having some level of dub integration is Meson would be neat indeed - maybe one could make a small helper binary Meson can call to fetch things from the dub registry. I wonder though how that would jive with Meson's own subprojects/wrap system. Probably worth investigating. My thought for SCons was to delegate the package fetching to Dub as a subprocess or write some Python to use the Dub API. I'm not clear on that as yet, the issue is whether the Dub local source repo is the right way forward – using Dub for preparing the compiled artefact is likely not the right way forward for SCons. This would then make it easy to do something for Rust/Cargo – except that SCons doesn't really support Rust yet, and with Cargo are there any Rust users not using Cargo. Having said all this SCons stuff, if there was Meson support for this "get the source from the Dub repository, compile it and make it a dependency" I'd likely stay with Meson for my codes. SCons is considered evil, last time I checked ^^ => https://wiki.debian.org/UpstreamGuide#line867 (unless it's used right, which seems to be hard) - I have no idea though on whether the issues with it were fixed, the entry on SCons hasn't been updated in a while.
Programmiersprache D: Referenzcompiler DMD unter freier Lizenz
https://www.heise.de/newsticker/meldung/Programmiersprache-D-Referenzcompiler-DMD-unter-freier-Lizenz-3678894.html Google translation: https://translate.google.com/translate?sl=de=en=y=_t=en=UTF-8=https%3A%2F%2Fwww.heise.de%2Fnewsticker%2Fmeldung%2FProgrammiersprache-D-Referenzcompiler-DMD-unter-freier-Lizenz-3678894.html==url Hmm, Google translate is doing a much better job these days!
Re: fluent-asserts released
On Sunday, 9 April 2017 at 13:30:54 UTC, Szabo Bogdan wrote: Hi! I just made an update to my fluent assert library. This is a library that allows you to write asserts in a BDD style. Right now, it contains only asserts that I needed in my projects and I promise that I will add more in the future. I would really appreciate any feedback that you can give me. https://code.dlang.org/packages/fluent-asserts Thanks! I got really confused looking at the examples until I realized that should returns a struct. You might add an approxEqual for ShouldNumeric. If you have floating point numbers, it's usually more helpful than equal is.
Re: D support for the Meson build system
On Mon, 2017-04-10 at 12:41 +, Matthias Klumpp via Digitalmars-d- announce wrote: > […]. > > I am not buying the necessity of not-splitbuilding for > optimizations yet. If that would be the case, how do > optimizations work with projects using GCC/Clang where > splitbuilding is the default and often only option (like Mesa, > Linux, lots of scientific stuff). I am investigating this architecture because Chapel code cannot really be compiled separately as far as I can see. cf. http://chapel.cray.com/ Chapel is a PGAS language (like X10) for use with Big Computation™ on serious computers and also any computer. I'm interested as a way of connecting Python visualisation to computation that NumPy can't really handle. It seems sensible therefore to offer this way of working for D since whether there is actually any optimisation benefit or not some people think there is and use it as a stick to beat you with if it isn't there. > Having some level of dub integration is Meson would be neat > indeed - maybe one could make a small helper binary Meson can > call to fetch things from the dub registry. > I wonder though how that would jive with Meson's own > subprojects/wrap system. Probably worth investigating. My thought for SCons was to delegate the package fetching to Dub as a subprocess or write some Python to use the Dub API. I'm not clear on that as yet, the issue is whether the Dub local source repo is the right way forward – using Dub for preparing the compiled artefact is likely not the right way forward for SCons. This would then make it easy to do something for Rust/Cargo – except that SCons doesn't really support Rust yet, and with Cargo are there any Rust users not using Cargo. Having said all this SCons stuff, if there was Meson support for this "get the source from the Dub repository, compile it and make it a dependency" I'd likely stay with Meson for my codes. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: fluent-asserts released
On Monday, 10 April 2017 at 12:54:43 UTC, Jacob Carlborg wrote: On 2017-04-09 15:30, Szabo Bogdan wrote: Hi! I just made an update to my fluent assert library. This is a library that allows you to write asserts in a BDD style. Right now, it contains only asserts that I needed in my projects and I promise that I will add more in the future. I would really appreciate any feedback that you can give me. https://code.dlang.org/packages/fluent-asserts This looks awesome. Why haven't I seen that before. Can it be used with unit-threaded? I did not tested it with unit-threaded, but when an assert fails it throws an exception so it should work with any test runner
InfoWorld article on the open sourcing of dmd
http://www.infoworld.com/article/3188427/application-development/free-at-last-d-languages-official-compiler-is-open-source.html Andrei
The New CTFE Engine on the Blog
Stefan has been diligently keeping us all updated on NewCTFE here in the forums. Now, he's gone to the blog to say something to tell the world about it. The blog: https://dlang.org/blog/2017/04/10/the-new-ctfe-engine/ Reddit: https://www.reddit.com/r/programming/comments/64jfes/an_introduction_to_ds_new_engine_for_compiletime/
Re: fluent-asserts released
On 2017-04-09 15:30, Szabo Bogdan wrote: Hi! I just made an update to my fluent assert library. This is a library that allows you to write asserts in a BDD style. Right now, it contains only asserts that I needed in my projects and I promise that I will add more in the future. I would really appreciate any feedback that you can give me. https://code.dlang.org/packages/fluent-asserts This looks awesome. Why haven't I seen that before. Can it be used with unit-threaded? -- /Jacob Carlborg
Re: D support for the Meson build system
On Monday, 10 April 2017 at 12:10:41 UTC, Russel Winder wrote: On Mon, 2017-04-10 at 08:39 +, Atila Neves via Digitalmars-d- announce wrote: […] As far as I know the only build system that does this by default for D is reggae. I will be adding a new builder to the SCons D tools to do whole source and per package compiling – to add to the module at a time compiling. It would be good to add this for CMake-D and the D support in Meson. I am not buying the necessity of not-splitbuilding for optimizations yet. If that would be the case, how do optimizations work with projects using GCC/Clang where splitbuilding is the default and often only option (like Mesa, Linux, lots of scientific stuff). Having some level of dub integration is Meson would be neat indeed - maybe one could make a small helper binary Meson can call to fetch things from the dub registry. I wonder though how that would jive with Meson's own subprojects/wrap system. Probably worth investigating.
Re: D support for the Meson build system
On Mon, 2017-04-10 at 08:39 +, Atila Neves via Digitalmars-d- announce wrote: > […] > > As far as I know the only build system that does this by default > for D is reggae. I will be adding a new builder to the SCons D tools to do whole source and per package compiling – to add to the module at a time compiling. It would be good to add this for CMake-D and the D support in Meson. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: D support for the Meson build system
On Saturday, 8 April 2017 at 19:11:35 UTC, Martin Nowak wrote: On Friday, 7 April 2017 at 07:57:02 UTC, kinke wrote: So while compiling each file separately in parallel is potentially much much faster, the produced release binary may be slower due to less/no cross-module inlining (e.g., LDC's option is still experimental and known to have issues). In fact single-module compilation is slower than package compilation most of the time due to the redundant parsing of common imports. As an extreme example, last time I tried, single-module compilation for gtkd was ~10x slower than compiling the library at once. Savings on recompilation hardly make up for this huge overhead. Overall I'd recommend organizing and building subpackages when a project becomes too big. Per package is significantly faster. As far as I know the only build system that does this by default for D is reggae. Atila
Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator
On Sunday, 9 April 2017 at 19:04:22 UTC, mogu wrote: On Sunday, 9 April 2017 at 08:56:52 UTC, Atila Neves wrote: Using std.experimental.allocator? Tired of writing `scope(exit) allocator.dispose(foo);` in a language with RAII? Me too: [...] Nice! Should UniqueArray be implemented as a overloaded version of Unique? Unique!(Object[]) instead of UniqueArray!(Object). I started like that, but after many a `static if` realised they had very little in common. Atila
Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator
On Sunday, 9 April 2017 at 15:52:50 UTC, Basile B. wrote: On Sunday, 9 April 2017 at 08:56:52 UTC, Atila Neves wrote: Using std.experimental.allocator? Tired of writing `scope(exit) allocator.dispose(foo);` in a language with RAII? Me too: http://code.dlang.org/packages/automem I think that the Array misses - a reservation strategy, something like reserve() and allocBy(). - dup / idup that return new distinct and deep copies. - maybe .ptr at least for reading with pointer arithmetic. - opBinary for "~" . Also you have bugs with operators: Thanks for the suggestions. ```d import std.experimental.allocator.mallocator; UniqueArray!(int, Mallocator) a; a ~= [0,1]; ``` crashes directly. Fixed now, thanks. Atila
Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator
On Sunday, 9 April 2017 at 13:59:14 UTC, Andrei Alexandrescu wrote: On 4/9/17 4:56 AM, Atila Neves wrote: Using std.experimental.allocator? Tired of writing `scope(exit) allocator.dispose(foo);` in a language with RAII? Me too: http://code.dlang.org/packages/automem Example: I think the code in the README should be enough to understand what's going on. Alpha stuff here but I think the main things missing are weak pointers and a ref counted array. Given that I've never had to use std::weak_ptr in C++, I'm not in a hurry to implement the former. Nice work! Notable design decisions / features: . The smart pointers are responsible for allocating the memory for the container object using the allocator of choice. This is to guarantee that one can't allocate and deallocate using different allocators. Nice! . The allocator has to be specified as part of the type: this means the user can choose how to store it in the smart pointer, which for singletons (e.g. Mallocator) or stateless allocators means they can take up zero space. If a singleton (or the default theAllocator), the allocator doesn't need to be passed in to the constructor, otherwise it does. Specifying, e.g. Mallocator also means the relevant code can be marked @nogc. After extensively studying how C++ allocator framework works, I got to the notion that making the allocator part of the type is an antipattern. I was aware of this, but here we have a crucial workaround - theAllocator, which is the default anyway. It's probably the best of both worlds, since you can still specify the type if needed, which also means the guarantee of @nogc if needed. . RefCounted only increments/decrements the ref count atomically if the contained type is `shared` Great. Can RefCounted itself be shared? I learned this is important for composition, i.e. you want to make a RefCounted a field in another object that is itself shared, immutable etc. Since it has a destructor, no: http://forum.dlang.org/post/sqazguejrcdtjimtj...@forum.dlang.org The only way to do that would be to split it into two. Which I guess I could with a template mixin implementing the guts. . RefCounted!(shared T) can be sent to other threads. Awes. . UniqueArray behaves nearly like a normal array. You can even append to it, but it won't use GC memory (unless, of course, you chose to use GCAllocator)! This may be a great candidate for the standard library. I think this needs to be used in production first, and having it as a dub package makes it easy for people to do so. Atila
