Re: Release Candidate 2.074.0-rc1
On Monday, 10 April 2017 at 20:53:00 UTC, Joseph Rushton Wakeling wrote: 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. Usually works, but had too much to do to handle another chat client in the past few days. The most reliable contact remains Mail, and in case of urgency phone.
Re: Release vibe.d 0.7.31
Thanks On Monday, 10 April 2017 at 20:48:34 UTC, Sönke Ludwig wrote: - Compiles on the latest DMD version (2.068.x-2.072.0) 2.068.x-2.074.0, that is
DIP 1006 - Preliminary Review Round 1 Begins
DIP 1006 is titled "Providing more selective control over contracts". This announcement kicks off the first round of preliminary reviews. The review thread can be found in the General forum at: http://forum.dlang.org/post/rsafosvkhxddkxpta...@forum.dlang.org
Re: The New CTFE Engine on the Blog
On Wednesday, 12 April 2017 at 05:51:20 UTC, Ali Çehreli wrote:
On 04/10/2017 06:07 AM, Mike Parker wrote:
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/
The first code sample is
private immutable ubyte[128] uri_flags = // indexed by character
({
// ...
})();
and the text says "The ({ starts a function-literal, the })
closes it.". Why the extra parentheses? Just the curly brackets
works, no?
private immutable ubyte[128] uri_flags = // indexed by character
{
// ...
}();
Ali
Yes it would work.
But I like to distinguish function-literals from blocks :)
Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator
On Monday, 10 April 2017 at 08:11:37 UTC, Atila Neves wrote: On Sunday, 9 April 2017 at 13:59:14 UTC, Andrei Alexandrescu wrote: 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. Syntax is not the core of the issue, it's not about just marking a destructor as shared. Making RefCounted itself shared would require implementing some form of synchronization of all the 'dereference' operations, including assignments. I.e. if we have some shared(RefCounted!T) ptr, what should happen when two threads simultaneously attempt to do ptr = shared(RefCounted!T)(someNewValue) ? Should a library implementation even consider this? Or should such synchronization be left to client's care? It seems like in this regard shared(RefCounted!T) would be no different from shared(T*), which brings me to the next point. On Andrei's comment regarding composition: if we're thinking about the design of shared data, IMHO, copying and shared are (or at least, should be) mutually exclusive. The only exception being references (pointers), and even for those care should be taken (which is one of the reasons of even having something like a RefCounted). If you can make a copy, there is no reason to share, or, conversely, if you intend to share, why would you copy? From that follows that a shared object should not ever have a RefCounted field. A Unique field, perhaps, but not a RefCounted. RefCounted's purpose is to be copied, not shared between threads. Unless I'm missing something.
Re: Release vibe.d 0.7.31
On 04/10/2017 04:48 PM, Sönke Ludwig wrote: 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. If a library depends on vibe, but wants to allow its users to use either 0.7.x or 0.8.x, is there a recommended way to do that? Ie: https://github.com/mysql-d/mysql-native/issues/99
