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
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: 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 :)
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: 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: fluent-asserts released
On 04/11/2017 11:01 PM, Szabo Bogdan wrote:
should.not.throwAnyException({
throw new Exception("test");
});
what do you mean, they are not documented? there is a md file fith some
examples here:
https://github.com/gedaiu/fluent-asserts/blob/v0.3.0/api/exceptions.md
What do you think I can do to have the exception asserts to fit the style?
The expression comes first in the other use cases. The following is not
very pretty but seems to work with my proof of concept below:
({
throw new Exception("test");
}()).should.not.throwAnyException();
I checked the syntax with the following code:
struct Should {
Should not() {
return this;
}
Should throwAnyException() {
return this;
}
}
Should should(E)(lazy E expr) {
return Should();
}
void main() {
({
throw new Exception("test");
}()).should.not.throwAnyException();
}
Ali
Re: fluent-asserts released
On Tuesday, 11 April 2017 at 10:40:53 UTC, qznc 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 was looking for testing exceptions. It is not documented, but
the seems to be there. Still, it looks weird, because it does
not fit the style:
should.not.throwAnyException({
throw new Exception("test");
});
what do you mean, they are not documented? there is a md file
fith some examples here:
https://github.com/gedaiu/fluent-asserts/blob/v0.3.0/api/exceptions.md
What do you think I can do to have the exception asserts to fit
the style?
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On 04/11/2017 02:22 AM, qznc wrote: On Tuesday, 11 April 2017 at 06:08:16 UTC, Ali Çehreli wrote: I will be presenting D as a time-saving tool at C++Now: http://cppnow.org/ Looks like C++Now has two keynotes. One keynote on D and one keynote on Rust. Maybe they should change their name. ;) I *think* the third one will be related to Haskell but don't quote me on that. I applaud the organizers for inviting other languages. Their keynote theme for this year is "What can C++ learn from other languages?" Ali
