Re: Escaping the Tyranny of the GC: std.rcstring, first blood

2014-09-27 Thread Foo via Digitalmars-d
Consider: struct MyRefCounted void opInc(); void opDec(); int x; } MyRefCounted a; a.x = 42; MyRefCounted b = a; b.x = 43; What is a.x after this? Andrei a.x == 42 a.ref_count == 1 (1 for init, +1 for copy, -1 for destruction) b.x == 43 b.ref_count == 1 (only init)

Re: Escaping the Tyranny of the GC: std.rcstring, first blood

2014-09-27 Thread Foo via Digitalmars-d
On Saturday, 27 September 2014 at 19:11:08 UTC, Andrei Alexandrescu wrote: On 9/27/14, 1:11 AM, Foo wrote: Consider: struct MyRefCounted void opInc(); void opDec(); int x; } MyRefCounted a; a.x = 42; MyRefCounted b = a; b.x = 43; What is a.x after this? Andrei a.x == 42 a.ref_cou

Re: RFC: moving forward with @nogc Phobos

2014-09-30 Thread Foo via Digitalmars-d
On Tuesday, 30 September 2014 at 13:38:43 UTC, Foo wrote: I hate the fact that this will produce template bloat for each function/method. I'm also in favor of "let the user pick", but I would use a global variable: enum MemoryManagementPolicy { gc, rc, mrc } immutable gc = ResourceMan

Re: RFC: moving forward with @nogc Phobos

2014-09-30 Thread Foo via Digitalmars-d
I hate the fact that this will produce template bloat for each function/method. I'm also in favor of "let the user pick", but I would use a global variable: enum MemoryManagementPolicy { gc, rc, mrc } immutable gc = ResourceManagementPolicy.gc, rc = ResourceManagementPolicy.rc,

Re: RFC: moving forward with @nogc Phobos

2014-09-30 Thread Foo via Digitalmars-d
On Tuesday, 30 September 2014 at 13:59:23 UTC, Andrei Alexandrescu wrote: On 9/30/14, 6:38 AM, Foo wrote: I hate the fact that this will produce template bloat for each function/method. I'm also in favor of "let the user pick", but I would use a global variable: enum MemoryManagementPoli

Re: Scope and Ref and Borrowing

2014-11-14 Thread Foo via Digitalmars-d
Remembers me a bit of http://wiki.dlang.org/DIP36

Re: accept @pure @nothrow @return attributes

2015-01-26 Thread Foo via Digitalmars-d
On Monday, 26 January 2015 at 16:10:53 UTC, Jonathan Marler wrote: I agree with Jonathan's points, this solution doesn't seem like an improvement. If I understand the problem, we don't want to make every attribute use the '@' symbol because it looks bad and would cause a lot of code changes f

Re: accept @pure @nothrow @return attributes

2015-01-26 Thread Foo via Digitalmars-d
On Monday, 26 January 2015 at 21:25:57 UTC, Jonathan Marler wrote: On Monday, 26 January 2015 at 21:12:50 UTC, Walter Bright wrote: On 1/26/2015 12:45 PM, Jonathan Marler wrote: Just because they are function attributes does not mean they were tokenized as "keywords". The lexer has no idea wh

Re: accept @pure @nothrow @return attributes

2015-01-26 Thread Foo via Digitalmars-d
On Monday, 26 January 2015 at 21:41:31 UTC, Jonathan Marler wrote: On Monday, 26 January 2015 at 21:28:14 UTC, Foo wrote: On Monday, 26 January 2015 at 21:25:57 UTC, Jonathan Marler wrote: On Monday, 26 January 2015 at 21:12:50 UTC, Walter Bright wrote: On 1/26/2015 12:45 PM, Jonathan Marler w

Re: Arrays, garbage collection

2015-01-30 Thread Foo via Digitalmars-d
On Friday, 30 January 2015 at 01:08:31 UTC, bearophile wrote: The D type inference for array literals is now more flexible: void main() { auto[$][$] m1 = [[1, 2], [3, 4], [5, 6]]; pragma(msg, typeof(m1)); // int[2][3] const auto[string] aa1 = ["red": 1, "blue": 2]; pragma(msg, t

Re: Should we remove int[$] before 2.067?

2015-01-30 Thread Foo via Digitalmars-d
On Friday, 30 January 2015 at 17:37:44 UTC, Nick Treleaven wrote: On 30/01/2015 16:53, Nick Treleaven wrote: This version of staticArray allows the user to (optionally) specify the element type. Actually, I'm having trouble implementing staticArray like that, perhaps there are compiler issue

Re: Should we remove int[$] before 2.067?

2015-01-30 Thread Foo via Digitalmars-d
On Friday, 30 January 2015 at 19:07:53 UTC, Andrei Alexandrescu wrote: On 1/30/15 10:40 AM, Foo wrote: On Friday, 30 January 2015 at 17:37:44 UTC, Nick Treleaven wrote: On 30/01/2015 16:53, Nick Treleaven wrote: This version of staticArray allows the user to (optionally) specify the element t

Module for manual memory management

2015-01-30 Thread Foo via Digitalmars-d
Is there interest in such a thing? I'm currently working on something for my own use and I'm curious if anyone else would be interested in something like that. I'm aware of Unique, RefCounted, Scoped, emplace and so on, but I'm not a big fan of some implementations (in my opinion not much of it

Re: Module for manual memory management

2015-01-31 Thread Foo via Digitalmars-d
On Saturday, 31 January 2015 at 01:07:21 UTC, Andrei Alexandrescu wrote: On 1/30/15 3:49 PM, Foo wrote: Is there interest in such a thing? I'm currently working on something for my own use and I'm curious if anyone else would be interested in something like that. I'm aware of Unique, RefCounte

Re: Module for manual memory management

2015-01-31 Thread Foo via Digitalmars-d
On Saturday, 31 January 2015 at 01:07:21 UTC, Andrei Alexandrescu wrote: On 1/30/15 3:49 PM, Foo wrote: Is there interest in such a thing? I'm currently working on something for my own use and I'm curious if anyone else would be interested in something like that. I'm aware of Unique, RefCounte

Re: Module for manual memory management

2015-02-04 Thread Foo via Digitalmars-d
For what it's worth, today I finished the current work. Now we will start working with it. If someone has critique, improvement suggestions or want to take some ideas, he is free to do so. To repeat myself: we rewrote some functionality which already existed in D, but were improvable. For exampl

Re: Module for manual memory management

2015-02-04 Thread Foo via Digitalmars-d
On Wednesday, 4 February 2015 at 20:15:37 UTC, Andrei Alexandrescu wrote: On 2/4/15 9:13 AM, Foo wrote: For what it's worth, today I finished the current work. Now we will start working with it. If someone has critique, improvement suggestions or want to take some ideas, he is free to do so. T

Re: Module for manual memory management

2015-02-04 Thread Foo via Digitalmars-d
On Wednesday, 4 February 2015 at 20:55:59 UTC, Walter Bright wrote: On 2/4/2015 12:42 PM, Foo wrote: On Wednesday, 4 February 2015 at 20:15:37 UTC, Andrei Alexandrescu wrote: @trusted @nogc char[] read(const string filename) nothrow { Yes that is correct, currently there is no error checking,

Re: Module for manual memory management

2015-02-04 Thread Foo via Digitalmars-d
On Wednesday, 4 February 2015 at 20:55:59 UTC, Walter Bright wrote: On 2/4/2015 12:42 PM, Foo wrote: On Wednesday, 4 February 2015 at 20:15:37 UTC, Andrei Alexandrescu wrote: @trusted @nogc char[] read(const string filename) nothrow { Yes that is correct, currently there is no error checking,

Re: Improving reviewing and scrutiny

2015-02-04 Thread Foo via Digitalmars-d
On Wednesday, 4 February 2015 at 23:01:48 UTC, Andrei Alexandrescu wrote: I just stepped into a disaster zone in std.file and submitted https://issues.dlang.org/show_bug.cgi?id=14125. This reveals the merits of reviewing pull requests carefully, and the issues that can crop in when that doesn'

Re: Module for manual memory management

2015-02-04 Thread Foo via Digitalmars-d
On Wednesday, 4 February 2015 at 20:15:37 UTC, Andrei Alexandrescu wrote: On 2/4/15 9:13 AM, Foo wrote: For what it's worth, today I finished the current work. Now we will start working with it. If someone has critique, improvement suggestions or want to take some ideas, he is free to do so. T

Re: Module for manual memory management

2015-02-05 Thread Foo via Digitalmars-d
On Thursday, 5 February 2015 at 07:53:34 UTC, Andrei Alexandrescu wrote: On 2/4/15 11:48 PM, Foo wrote: I would be glad if you or Walter could review the other parts as well. I'm very sure that your review will be very helpful and I'm convinced that the modules Array or Smart Pointer could be u

Re: Module for manual memory management

2015-02-07 Thread Foo via Digitalmars-d
On Saturday, 7 February 2015 at 11:29:51 UTC, Jacob Carlborg wrote: On 2015-02-04 21:55, Walter Bright wrote: No need to reinvent this: https://github.com/D-Programming-Language/phobos/blob/master/std/file.d line 194 Just for the record, you can get a link to the exact line by clickin

Re: Should we remove int[$] before 2.067?

2015-02-07 Thread Foo via Digitalmars-d
Maybe someone should remove this from the Changelog? http://dlang.org/changelog.html#partial-type