On Tuesday, 13 May 2014 at 07:12:02 UTC, Marco Leise wrote:
Am Mon, 12 May 2014 08:44:51 +0000
schrieb "Marc Schütz" <schue...@gmx.net>:
On Monday, 12 May 2014 at 04:22:21 UTC, Marco Leise wrote:
> On the positive side the talk about Rust, in particular how
> reference counted pointers decay to borrowed pointers made me
> think the same could be done for our "scope" args. A
> reference
> counted slice with 3 machine words could decay to a 2 machine
> word "scoped" slice. Most of my code at least just works on
> the
> slices and doesn't keep a reference to them. A counter
> example
> is when you have something like an XML parser - a use case
> that D traditionally (see Tango) excelled in. The GC
> environment and slices make it possible to replace string
> copies with cheap slices into the original XML string.
Rust also has a solution for this: They have lifetime
annotations. D's scope could be extended to support something
similar:
scope(input) string getSlice(scope string input);
or with methods:
struct Xml {
scope(this) string getSlice();
}
scope(symbol) means, "this value references/aliases (parts of)
the value referred to by <symbol>". The compiler can then make
sure it is never assigned to variables with longer lifetimes
than <symbol>.
Crazy shit, now we are getting into concepts that I have no
idea of how well they play in real code. There are no globals,
but threads all create their own call stacks with independent
lifetimes. So at that point lifetime annotations become
interesting.
I don't really know a lot about Rust, but I believe this is not
an issue with Rust, as its variables are only thread-local. You
can send things to other threads, but then they become
inaccessible in the current thread. In general, lifetime
annotations can only be used for "simple" relationships. It's
also not a way to keep objects alive as long as they are
referenced, but rather a way to disallow references to exist
longer than the objects they point to.
