On 04/03/2015 08:55, Ivan Timokhin wrote:
void main()
{
auto arr = RCArray!int([0]);
foo(arr, arr[0]);
}
void foo(ref RCArray!int arr, ref int val)
{
{
auto copy = arr; //arr's (and copy's) reference counts are both 2
On Thursday, 5 March 2015 at 18:41:31 UTC, deadalnix wrote:
Kind of OT, but your train of thought is very difficult to
follow the way you are communicating (ie by updating on
previous post by answering to yourself).
Could you post some more global overview at some point, so one
does not need
On Wednesday, 4 March 2015 at 08:56:20 UTC, Ivan Timokhin wrote:
Excuse me if I miss something obvious, but:
void main()
{
auto arr = RCArray!int([0]);
foo(arr, arr[0]);
}
void foo(ref RCArray!int arr, ref int val)
{
{
auto copy = arr;
On Thursday, 5 March 2015 at 20:47:55 UTC, Zach the Mystic wrote:
Did you want me to talk about how I would do ownership with my
reference safety system?
I'd like you to expose what is pretty settled down in your mind
so we can have a base to understand the in flux part of the ideas
:)
On Wednesday, 4 March 2015 at 18:05:52 UTC, Zach the Mystic wrote:
On Wednesday, 4 March 2015 at 17:22:15 UTC, Steven
Schveighoffer wrote:
Again, I think this is an issue with the expectation of
RCArray. You cannot *save* a ref to an array element, only a
ref to the array itself, because you
Kind of OT, but your train of thought is very difficult to follow
the way you are communicating (ie by updating on previous post by
answering to yourself).
Could you post some more global overview at some point, so one
does not need to gather various information for various posts
please ?
On 3/4/15 12:55 AM, Ivan Timokhin wrote:
Excuse me if I miss something obvious, but:
void main()
{
auto arr = RCArray!int([0]);
foo(arr, arr[0]);
}
void foo(ref RCArray!int arr, ref int val)
{
{
auto copy = arr; //arr's (and
On 3/4/15 2:03 AM, deadalnix wrote:
A free list does not work as the data can be live. You cannot reuse it
to maintain the free list.
Actually you can, which is a bit surprising. Consider:
RCArray!int arr;
arr.length = 10;
arr[5] = 42;
fun(arr, arr[5]);
...
void fun(ref RCArray!int a, ref int
On Wednesday, 4 March 2015 at 17:13:13 UTC, Zach the Mystic wrote:
(Also, `pure` functions will need no `static` parameter
attributes, and functions both `pure` and `@nogc` will not need
)
...will not need `@noscope` either.
On 3/4/15 10:42 AM, Andrei Alexandrescu wrote:
On 3/4/15 12:55 AM, Ivan Timokhin wrote:
Excuse me if I miss something obvious, but:
void main()
{
auto arr = RCArray!int([0]);
foo(arr, arr[0]);
}
void foo(ref RCArray!int arr, ref int val)
{
{
On Wednesday, 4 March 2015 at 09:06:01 UTC, Walter Bright wrote:
On 3/4/2015 12:13 AM, deadalnix wrote:
The #1 argument for DIP25 compared to alternative proposal was
its simplicity. I
assume at this point that we have empirical evidence that this
is NOT the case.
The complexity of a free
On Wednesday, 4 March 2015 at 07:50:50 UTC, Manu wrote:
Well you can't get to a subcomponent if not through it's owner.
If the question is about passing RC objects members to
functions, then
the solution is the same as above, the stack needs a reference
to the
parent before it can pass a
On Wednesday, 4 March 2015 at 08:13:33 UTC, deadalnix wrote:
On Wednesday, 4 March 2015 at 03:46:36 UTC, Zach the Mystic
wrote:
That's fine. I like DIP25. It's a start towards stronger
safety guarantees. While I'm pretty sure the runtime costs of
my proposal are lower than yours, they do
On Wednesday, 4 March 2015 at 17:06:53 UTC, Walter Bright wrote:
On 3/4/2015 6:27 AM, ponce wrote:
You define a clear owner for everything so that this never
happens.
That's what we do in C++ and shared_ptr is can be avoided as
much as we like.
C++ doesn't have ownership annotations and no
On 3/4/2015 6:27 AM, ponce wrote:
You define a clear owner for everything so that this never happens.
That's what we do in C++ and shared_ptr is can be avoided as much as we like.
C++ doesn't have ownership annotations and no checkable notion of a clear owner.
On Wednesday, 4 March 2015 at 08:13:33 UTC, deadalnix wrote:
On Wednesday, 4 March 2015 at 03:46:36 UTC, Zach the Mystic
wrote:
That's fine. I like DIP25. It's a start towards stronger
safety guarantees. While I'm pretty sure the runtime costs of
my proposal are lower than yours, they do
On Wednesday, 4 March 2015 at 17:22:15 UTC, Steven Schveighoffer
wrote:
Again, I think this is an issue with the expectation of
RCArray. You cannot *save* a ref to an array element, only a
ref to the array itself, because you lose control over the
reference count.
What you need is a special
On Wednesday, 4 March 2015 at 18:05:52 UTC, Zach the Mystic wrote:
On Wednesday, 4 March 2015 at 17:22:15 UTC, Steven
Schveighoffer wrote:
Again, I think this is an issue with the expectation of
RCArray. You cannot *save* a ref to an array element, only a
ref to the array itself, because you
On Wednesday, 4 March 2015 at 18:17:41 UTC, Andrei Alexandrescu
wrote:
Yah, this is a fork in the road: either we solve this with
DIP25 + implementation, or we add stricter static checking
disallowing two lent references to data in the same scope.
The third solution is to keep track of
On Wednesday, 4 March 2015 at 17:13:13 UTC, Zach the Mystic wrote:
Another example:
T* jun(return static T* a) {
static T* t;
t = a;
return a;
}
Again, no ownership, because of the `static` parameter
attribute. In a previous post, you suggested that such an
attribute was unnecessary,
On 3/4/15 6:02 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote:
I hope to finish writing up a proposal in the next days. Really, it is
_much_ simpler than the previous one, and it will require almost no
manual annotations.
Looking forward to it! -- Andrei
On Wednesday, 4 March 2015 at 10:49:06 UTC, Walter Bright wrote:
On 3/4/2015 2:03 AM, deadalnix wrote:
A free list does not work as the data can be live.
It is a to free list.
What I wanted to illustrate is that it is not a free list (which
use the freed storage to maintain its state) as
On Wednesday, 4 March 2015 at 10:50:54 UTC, Walter Bright wrote:
On 3/4/2015 1:16 AM, bearophile wrote:
Walter Bright:
The complexity of a free list doesn't remotely compare to
that of adding an
ownership system.
A sound complete ownership system is the only good enough
solution for D.
On 3/4/15 9:22 AM, Steven Schveighoffer wrote:
On 3/4/15 10:42 AM, Andrei Alexandrescu wrote:
On 3/4/15 12:55 AM, Ivan Timokhin wrote:
Excuse me if I miss something obvious, but:
void main()
{
auto arr = RCArray!int([0]);
foo(arr, arr[0]);
}
void foo(ref
On Wednesday, 4 March 2015 at 19:22:25 UTC, Zach the Mystic wrote:
On Wednesday, 4 March 2015 at 18:17:41 UTC, Andrei Alexandrescu
wrote:
Yah, this is a fork in the road: either we solve this with
DIP25 + implementation, or we add stricter static checking
disallowing two lent references to
On Wednesday, 4 March 2015 at 03:46:36 UTC, Zach the Mystic wrote:
That's fine. I like DIP25. It's a start towards stronger safety
guarantees. While I'm pretty sure the runtime costs of my
proposal are lower than yours, they do require compiler
hacking, which means they can wait.
I don't
Walter Bright:
The complexity of a free list doesn't remotely compare to that
of adding an ownership system.
A sound complete ownership system is the only good enough
solution for D. That's my opinion.
Bye,
bearophile
On Wednesday, 4 March 2015 at 09:16:22 UTC, bearophile wrote:
Walter Bright:
The complexity of a free list doesn't remotely compare to that
of adding an ownership system.
A sound complete ownership system is the only good enough
solution for D. That's my opinion.
Bye,
bearophile
+1
---
On Wednesday, 4 March 2015 at 09:06:01 UTC, Walter Bright wrote:
On 3/4/2015 12:13 AM, deadalnix wrote:
The #1 argument for DIP25 compared to alternative proposal was
its simplicity. I
assume at this point that we have empirical evidence that this
is NOT the case.
The complexity of a free
Excuse me if I miss something obvious, but:
void main()
{
auto arr = RCArray!int([0]);
foo(arr, arr[0]);
}
void foo(ref RCArray!int arr, ref int val)
{
{
auto copy = arr; //arr's (and copy's) reference counts are both 2
arr =
On Wednesday, 4 March 2015 at 09:16:22 UTC, bearophile wrote:
Walter Bright:
The complexity of a free list doesn't remotely compare to that
of adding an ownership system.
A sound complete ownership system is the only good enough
solution for D. That's my opinion.
Bye,
bearophile
+1
On 3/4/2015 12:13 AM, deadalnix wrote:
The #1 argument for DIP25 compared to alternative proposal was its simplicity. I
assume at this point that we have empirical evidence that this is NOT the case.
The complexity of a free list doesn't remotely compare to that of adding an
ownership system.
On Wednesday, 4 March 2015 at 10:03:13 UTC, deadalnix wrote:
On Wednesday, 4 March 2015 at 09:06:01 UTC, Walter Bright wrote:
On 3/4/2015 12:13 AM, deadalnix wrote:
The #1 argument for DIP25 compared to alternative proposal
was its simplicity. I
assume at this point that we have empirical
On 3/4/2015 2:03 AM, deadalnix wrote:
A free list does not work as the data can be live.
It is a to free list.
You need to maintain metadata about allocation in
another structure.
I don't see why.
Also you cannot free anything until all the refcount are to 0.
Right.
This RC system
Walter Bright:
How do you type an an array of pointers with different owners?
Sound doesn't mean it should be able to do everything. It will
be just an approximated model. It means it's going to forbid some
valid code, just like every type system. You use some @system
code to work around
On 3/4/2015 2:06 AM, deadalnix wrote:
And come on, DIP25, DIP69 and DIP74 to get there. Come on, that is not even
simpler than the alternative.
DIP69 has pretty much been abandoned.
On 3/4/2015 1:16 AM, bearophile wrote:
Walter Bright:
The complexity of a free list doesn't remotely compare to that of adding an
ownership system.
A sound complete ownership system is the only good enough solution for D. That's
my opinion.
How do you type an an array of pointers with
On Wednesday, 4 March 2015 at 10:50:54 UTC, Walter Bright wrote:
How do you type an an array of pointers with different owners?
You mean an array of pointers to objects with different owners?
The array is the owner of the objects it points to. Or else it
should be @trusted?
How do you
On Wednesday, 4 March 2015 at 10:50:54 UTC, Walter Bright wrote:
On 3/4/2015 1:16 AM, bearophile wrote:
Walter Bright:
The complexity of a free list doesn't remotely compare to
that of adding an
ownership system.
A sound complete ownership system is the only good enough
solution for D.
On Wednesday, 4 March 2015 at 10:50:54 UTC, Walter Bright wrote:
On 3/4/2015 1:16 AM, bearophile wrote:
Walter Bright:
The complexity of a free list doesn't remotely compare to
that of adding an
ownership system.
A sound complete ownership system is the only good enough
solution for D.
On Wednesday, 4 March 2015 at 09:16:22 UTC, bearophile wrote:
Walter Bright:
The complexity of a free list doesn't remotely compare to that
of adding an ownership system.
A sound complete ownership system is the only good enough
solution for D. That's my opinion.
Bye,
bearophile
For
On Wednesday, 4 March 2015 at 14:21:24 UTC, ponce wrote:
For that matters, I'd be happy with an unsound incomplete
unsafe ownership system :)
You already have that :^)
On 3 March 2015 at 06:37, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 3/1/2015 12:51 PM, Michel Fortin wrote:
That's actually not enough. You'll have to block access to global
variables too:
S s;
void main() {
s.array = RCArray!T([T()]); //
On Tuesday, 3 March 2015 at 05:12:15 UTC, Walter Bright wrote:
On 3/2/2015 6:04 PM, weaselcat wrote:
On Tuesday, 3 March 2015 at 01:56:09 UTC, Walter Bright wrote:
On 3/2/2015 4:40 PM, deadalnix wrote:
After moving resources, the previous owner can no longer be
used.
How does that work with
On Monday, 2 March 2015 at 22:42:44 UTC, weaselcat wrote:
I don't think you were advocating for this but,
+1 for a borrow system similar to Rust.
We're working on it ;-)
On 3/3/15 5:45 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote:
On Tuesday, 3 March 2015 at 09:05:46 UTC, Walter Bright wrote:
On 3/2/2015 9:58 PM, weaselcat wrote:
Borrowing 'a' from a struct would make the parent struct immutable
during the
borrow scope of 'a', I believe.
Right,
On Tuesday, 3 March 2015 at 05:12:15 UTC, Walter Bright wrote:
On 3/2/2015 6:04 PM, weaselcat wrote:
On Tuesday, 3 March 2015 at 01:56:09 UTC, Walter Bright wrote:
On 3/2/2015 4:40 PM, deadalnix wrote:
After moving resources, the previous owner can no longer be
used.
How does that work with
On 3/3/15 5:05 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote:
The object is still accessible after its refcount went to zero, and can
therefore potentially be resurrected. Probably not a problem, but needs
to be taken into account, in particular in with respect to the freelist.
That's
On Tuesday, 3 March 2015 at 08:04:25 UTC, Manu wrote:
My immediate impression on this problem:
s.array[0] is being passed to foo from main. s does not belong
to main
(is global), and main does not hold have a reference to s.array.
Shouldn't main just need to inc/dec array around the call to
On Monday, 2 March 2015 at 22:58:19 UTC, Walter Bright wrote:
Pretty dazz idea, dontcha think? And DIP25 still stands
unscathed :-)
Unless, of course, we missed something obvious.
I was dazzed, but I'm not anymore. I wrote my concern here:
On Tuesday, 3 March 2015 at 08:04:25 UTC, Manu wrote:
So, passing global x to some function; inc/dec x around the
function
call that it's passed to...? Then the stack has its own
reference, and
the global reference can go away safely.
Yes, the sane thing to do is to improve the general type
On 3/3/15 7:38 AM, Zach the Mystic wrote:
On Monday, 2 March 2015 at 22:58:19 UTC, Walter Bright wrote:
Pretty dazz idea, dontcha think? And DIP25 still stands unscathed :-)
Unless, of course, we missed something obvious.
I was dazzed, but I'm not anymore. I wrote my concern here:
On Monday, 2 March 2015 at 22:58:19 UTC, Walter Bright wrote:
On 3/2/2015 1:09 PM, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
I have discovered a marvellous solution, but this post is too
short to describe
it.
Fortunately, Fermat (er, Andrei) was able to pass along his
dazz idea
On Tuesday, 3 March 2015 at 16:31:07 UTC, Andrei Alexandrescu
wrote:
I was dazzed, but I'm not anymore. I wrote my concern here:
http://forum.dlang.org/post/ylpaqhnuiczfgfpqj...@forum.dlang.org
There's a misunderstanding here. The object being assigned
keeps a trailing list of past values
On Tuesday, 3 March 2015 at 09:05:46 UTC, Walter Bright wrote:
On 3/2/2015 9:58 PM, weaselcat wrote:
Borrowing 'a' from a struct would make the parent struct
immutable during the
borrow scope of 'a', I believe.
Right, now consider that struct is a leaf in a complex graph of
data structures.
On Tuesday, 3 March 2015 at 15:03:41 UTC, Andrei Alexandrescu
wrote:
On 3/3/15 5:45 AM, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
On Tuesday, 3 March 2015 at 09:05:46 UTC, Walter Bright wrote:
On 3/2/2015 9:58 PM, weaselcat wrote:
Borrowing 'a' from a struct would make the parent
On Tuesday, 3 March 2015 at 08:59:08 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 3 March 2015 at 08:04:25 UTC, Manu wrote:
So, passing global x to some function; inc/dec x around the
function
call that it's passed to...? Then the stack has its own
reference, and
the global reference can go
On Tuesday, 3 March 2015 at 17:40:59 UTC, Marc Schütz wrote:
All instances need to carry a pointer to refcount anyway, so
the freelist could just be stored next to the refcount. The
idea of creating that list, however, is more worrying, because
it again involves allocations. It can get
On 03/03/2015 13:05, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net
wrote:
The bigger problem is that it's relying on a convention. The RC wrapper
needs to be constructed in a particular way that's easy to get wrong and
that the compiler has no way to check for us.
Maybe the compiler could
On 3/3/2015 9:44 AM, Andrei Alexandrescu wrote:
On 3/3/15 9:40 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote:
All instances need to carry a pointer to refcount anyway, so the
freelist could just be stored next to the refcount. The idea of creating
that list, however, is more
On 3/3/2015 9:19 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote:
Therefore, your reply isn't really valid. In Rust, it is an escape hatch from a
fundamentally safe type system, whereas in D it would be a necessary convention
to make usage of RC safe.
My understanding of Rust is that
On Tuesday, 3 March 2015 at 07:17:11 UTC, Sativa wrote:
On Sunday, 1 March 2015 at 15:44:49 UTC, Marc Schütz wrote:
Walter posted an example implementation of a reference counted
array [1], that utilizes the features introduced in DIP25 [2].
Then, in the threads about reference counted
On 3/3/15 9:00 AM, Zach the Mystic wrote:
On Tuesday, 3 March 2015 at 16:31:07 UTC, Andrei Alexandrescu wrote:
I was dazzed, but I'm not anymore. I wrote my concern here:
http://forum.dlang.org/post/ylpaqhnuiczfgfpqj...@forum.dlang.org
There's a misunderstanding here. The object being
On 3/3/15 10:22 AM, Zach the Mystic wrote:
On Tuesday, 3 March 2015 at 17:40:59 UTC, Marc Schütz wrote:
All instances need to carry a pointer to refcount anyway, so the
freelist could just be stored next to the refcount. The idea of
creating that list, however, is more worrying, because it
Somebody please write the code already. With no code we sit
forever on our testes speculating.
Isn't this testes-driven development?
On Tuesday, 3 March 2015 at 18:49:43 UTC, Andrei Alexandrescu
wrote:
On 3/3/15 10:22 AM, Zach the Mystic wrote:
On Tuesday, 3 March 2015 at 17:40:59 UTC, Marc Schütz wrote:
All instances need to carry a pointer to refcount anyway, so
the
freelist could just be stored next to the refcount. The
On Tuesday, 3 March 2015 at 19:50:46 UTC, Paulo Pinto wrote:
You just reminded me of ParaSail. Here is the latest version of
their pointer free programming paper.
https://drive.google.com/file/d/0B6Vq5QaY4U7ubm5qVkFpMEtmN2s/view?pli=1
Thanks! Section «5. Related Work» was a fun read. :-)
On 3/3/15 12:35 PM, Zach the Mystic wrote:
On Tuesday, 3 March 2015 at 18:48:36 UTC, Andrei Alexandrescu wrote:
On 3/3/15 9:00 AM, Zach the Mystic wrote:
On Tuesday, 3 March 2015 at 16:31:07 UTC, Andrei Alexandrescu wrote:
I was dazzed, but I'm not anymore. I wrote my concern here:
On Tuesday, 3 March 2015 at 18:48:36 UTC, Andrei Alexandrescu
wrote:
On 3/3/15 9:00 AM, Zach the Mystic wrote:
On Tuesday, 3 March 2015 at 16:31:07 UTC, Andrei Alexandrescu
wrote:
I was dazzed, but I'm not anymore. I wrote my concern here:
On 2015-03-02 05:57:12 +, Walter Bright said:
On 3/1/2015 12:51 PM, Michel Fortin wrote:
That's actually not enough. You'll have to block access to global
variables too:
Hmm. That's not so easy to solve.
Let's see. The problem is that 'ref' variables get invalidated by some
On 4 March 2015 at 01:07, Zach the Mystic via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Tuesday, 3 March 2015 at 08:04:25 UTC, Manu wrote:
My immediate impression on this problem:
s.array[0] is being passed to foo from main. s does not belong to main
(is global), and main does not
On Wednesday, 4 March 2015 at 03:46:36 UTC, Zach the Mystic wrote:
Just my own past posts. My suggestion is based on the compiler
doing all the work. I don't know how it could be tested without
hacking the compiler.
I think that part of the fear of my idea is that I want structs
to get some
On 2015-03-03 22:39:12 +, Michel Fortin said:
Let's see. The problem is that 'ref' variables get invalidated by some
operations. Perhaps we could just tell the compiler that doing this or
that will makes 'ref' variables unsafe after that point. Let's try
adding a @refbreaking function
On Tuesday, 3 March 2015 at 21:37:20 UTC, Andrei Alexandrescu
wrote:
On 3/3/15 12:35 PM, Zach the Mystic wrote:
Isn't allocating and collecting a freelist also overhead?
No. I don't have time now for a proof of concept and it seems
everybody wants to hypothesize about code that doesn't exist
On Tuesday, 3 March 2015 at 15:01:02 UTC, Andrei Alexandrescu
wrote:
On 3/3/15 5:05 AM, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
The object is still accessible after its refcount went to
zero, and can
therefore potentially be resurrected. Probably not a problem,
but needs
to be
On 3/3/15 9:30 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote:
On Tuesday, 3 March 2015 at 15:01:02 UTC, Andrei Alexandrescu wrote:
On 3/3/15 5:05 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net
wrote:
The object is still accessible after its refcount went to zero, and can
On 3/3/15 9:40 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote:
On Tuesday, 3 March 2015 at 17:00:17 UTC, Zach the Mystic wrote:
On Tuesday, 3 March 2015 at 16:31:07 UTC, Andrei Alexandrescu wrote:
I was dazzed, but I'm not anymore. I wrote my concern here:
On Tuesday, 3 March 2015 at 17:00:17 UTC, Zach the Mystic wrote:
On Tuesday, 3 March 2015 at 16:31:07 UTC, Andrei Alexandrescu
wrote:
I was dazzed, but I'm not anymore. I wrote my concern here:
http://forum.dlang.org/post/ylpaqhnuiczfgfpqj...@forum.dlang.org
There's a misunderstanding here.
On Tuesday, 3 March 2015 at 09:05:46 UTC, Walter Bright wrote:
On 3/2/2015 9:58 PM, weaselcat wrote:
Borrowing 'a' from a struct would make the parent struct
immutable during the
borrow scope of 'a', I believe.
Right, now consider that struct is a leaf in a complex graph of
data structures.
On 3/2/2015 9:58 PM, weaselcat wrote:
Borrowing 'a' from a struct would make the parent struct immutable during the
borrow scope of 'a', I believe.
Right, now consider that struct is a leaf in a complex graph of data structures.
On Monday, 2 March 2015 at 21:12:20 UTC, deadalnix wrote:
On Monday, 2 March 2015 at 20:54:20 UTC, Walter Bright wrote:
I looked at how Rust does it. I was hoping it was something
clever, but it isn't. A copy is made of the object to which a
borrowed reference is taken - in other words, the
On 3/2/2015 3:22 PM, Andrei Alexandrescu wrote:
And since an RCArray may undergo several assignments during its lifetime (thus
potentially needing to free several chunks of memory), the arrays to be
destroyed will be kept in a freelist-style structure. Destructor walks the
freelist and frees the
On 3/2/15 12:37 PM, Walter Bright wrote:
On 3/1/2015 12:51 PM, Michel Fortin wrote:
That's actually not enough. You'll have to block access to global
variables too:
S s;
void main() {
s.array = RCArray!T([T()]); // s.array's refcount is now 1
foo(s.array[0]);
On 3/2/15 12:53 PM, Walter Bright wrote:
I was hoping to avoid that, but apparently there's no way.
There is! There is! -- Andrei
On Monday, 2 March 2015 at 21:00:54 UTC, Andrei Alexandrescu
wrote:
On 3/2/15 12:37 PM, Walter Bright wrote:
On 3/1/2015 12:51 PM, Michel Fortin wrote:
That's actually not enough. You'll have to block access to
global
variables too:
S s;
void main() {
s.array =
On 3/2/15 2:57 PM, Walter Bright wrote:
On 3/2/2015 1:09 PM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net
wrote:
I have discovered a marvellous solution, but this post is too short
to describe
it.
Fortunately, Fermat (er, Andrei) was able to pass along his dazz idea to
me this afternoon,
On 3/2/15 3:22 PM, Andrei Alexandrescu wrote:
On 3/2/15 2:57 PM, Walter Bright wrote:
On 3/2/2015 1:09 PM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net
wrote:
I have discovered a marvellous solution, but this post is too short
to describe
it.
Fortunately, Fermat (er, Andrei) was able to
On Sunday, 1 March 2015 at 19:22:06 UTC, Walter Bright wrote:
On 3/1/2015 7:44 AM, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
A weakness of the same kind affects DIP25, too. The core of
the problem is
borrowing (ref return as in DIP25), combined with manual
(albeit hidden) memory
On Monday, 2 March 2015 at 20:54:20 UTC, Walter Bright wrote:
On 3/2/2015 12:42 PM, Walter Bright wrote:
For D structs, that means, if there's a postblit, a copy must
be made. For D ref counted classes, a ref count increment must
be done.
I was hoping to avoid that, but apparently there's no
On 3/2/2015 1:12 PM, deadalnix wrote:
I do think you are confusing how Rust does it. In Rust, borrowing makes the
source and borrowed reference immutable by default. So by default the problem do
not occurs.
May I refer you to:
On 3/2/2015 1:09 PM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote:
I have discovered a marvellous solution, but this post is too short to describe
it.
Fortunately, Fermat (er, Andrei) was able to pass along his dazz idea to me this
afternoon, before he expired to something he had to
On Monday, 2 March 2015 at 20:54:20 UTC, Walter Bright wrote:
I looked at how Rust does it. I was hoping it was something
clever, but it isn't. A copy is made of the object to which a
borrowed reference is taken - in other words, the reference
count is incremented.
For D structs, that means,
On Tuesday, 3 March 2015 at 00:08:10 UTC, Walter Bright wrote:
On 3/2/2015 3:47 PM, weaselcat wrote:
That's actually very old(0.6 - nearly 2 years ago.) I believe
rooting was
dropped from the language completely.
http://doc.rust-lang.org/book/ownership.html
also, rust by example chapter
On Tuesday, 3 March 2015 at 00:08:10 UTC, Walter Bright wrote:
On 3/2/2015 3:47 PM, weaselcat wrote:
That's actually very old(0.6 - nearly 2 years ago.) I believe
rooting was
dropped from the language completely.
http://doc.rust-lang.org/book/ownership.html
also, rust by example chapter
On Monday, 2 March 2015 at 20:37:46 UTC, Walter Bright wrote:
On 3/1/2015 12:51 PM, Michel Fortin wrote:
That's actually not enough. You'll have to block access to
global variables too:
S s;
void main() {
s.array = RCArray!T([T()]); // s.array's refcount is
now 1
On Tuesday, 3 March 2015 at 01:23:24 UTC, Zach the Mystic wrote:
Which makes me think about a bigger problem... when you
opAssign, don't you redirect the variable to a different
instance? Won't the destructor then destroy *that* instance (or
not destroy it, since it just got a +1 count)
On Monday, 2 March 2015 at 22:58:19 UTC, Walter Bright wrote:
His insight was that the deletion of the payload occurred
before the end of the lifetime of the RC object, and that this
was the source of the problem. If the deletion of the payload
occurs during the destructor call, rather than
On 3/2/15 4:01 PM, Zach the Mystic wrote:
On Monday, 2 March 2015 at 22:58:19 UTC, Walter Bright wrote:
His insight was that the deletion of the payload occurred before the
end of the lifetime of the RC object, and that this was the source of
the problem. If the deletion of the payload occurs
On Tuesday, 3 March 2015 at 02:10:23 UTC, weaselcat wrote:
On Tuesday, 3 March 2015 at 02:04:15 UTC, weaselcat wrote:
On Tuesday, 3 March 2015 at 01:56:09 UTC, Walter Bright wrote:
On 3/2/2015 4:40 PM, deadalnix wrote:
After moving resources, the previous owner can no longer be
used.
How
On Monday, 2 March 2015 at 22:58:19 UTC, Walter Bright wrote:
I.e. the postblit manipulates the ref count, but does NOT do
payload deletions. The destructor checks the ref count, if it
is zero, THEN it does the payload deletion.
Pretty dazz idea, dontcha think? And DIP25 still stands
1 - 100 of 125 matches
Mail list logo
