[Dlang-study] [lifetime] Let's focus on escape analysis

[Amaury SECHET]

Well, Rust, as well as Swift, as irreducible control flow (understand no
goto) which makes the analysis WAY easier to specify. I discussed this with
Chris Latner in Dec and this was a very delibrate Swift design to go that
road (we also discussed exception handling and he made some very good
points, but that is for another time).


@Walter, could you describe the algorithm used by DMD to figure out where
to put the destructors ? Especially when it comes to goto. That would help
tremendously.

2016-01-19 13:44 GMT-08:00 György Andrasek <jurily at gmail.com>:

> On Monday, 2 November 2015 at 16:03:04 UTC, Andrei Alexandrescu wrote:
>
>> I don't follow Rust much, but my perception from following the trade news
>> is that since launched it has scored a few victories (an OS project, a safe
>> Doom implementation) but by and large the excitement has subsided after the
>> pre-release excitement gave way to the post-1.0 certainty. The status seems
>> to be - things aren't as great as they were cracked to be. Putting
>> ownership front and center just makes things difficult, often for no good
>> outcome.
>>
>
> The Rust devs have made a bunch of braindead design decisions that turned
> it from a promising systems language into a RAII tutorial for Rubyists.
> Finalizing those in 1.0 is what drove people away, including me.
>
> That said, lifetime management is the one thing they did exactly right.
>
> The key thing to observe here is that we already have lifetime semantics
> everywhere, it's just not always checked by the compiler. GC languages get
> around the issue by extending the unchecked lifetimes to infinity, the
> problem we have now is that this is incorrect without the GC. We don't need
> to add extra complexity or runtime overhead to do it right, just keep more
> information in the compiler and some syntax to talk about it.
>
> In Rust, all object and reference lifetimes are tracked by the compiler,
> at no runtime cost. You can say "I'm only allocating objects that don't
> outlive me", and have it checked transitively for all references into those
> objects. You can say "my lifetime will be the shortest of the constructor
> arguments" or "my lifetime is independent of them".
>
> Safe RC is almost trivial in Rust, they have both a thread-local `Rc<T>`
> and an atomic `Arc<T>` in the standard library. It's also very easy to
> write, say, lifetime-safe glib bindings, where the refcount semantics are
> documented externally.
>
> It's almost always inferred away, there's no syntax overhead for the
> common case. Most people don't need to care beyond what they're already
> familiar with from the curly braces. In fact, neither `Rc<T>` nor `Arc<T>`
> have a single explicit lifetime annotation in their public API. It Just
> Works(tm), wrong usage will simply not compile.
>
> For D, I believe this could be implemented without breaking any existing
> correct code, maybe with syntax like
>
>     C!A foo(A: scope)(C!A c) { return c; }
>
> or
>
>     scope!A C foo(scope(A) C c) { return c; }
>
> which with lifetime inference could safely be written as
>
>    C foo(C c) { return c; }
>
> Of course it gets tricky with mutability, raw pointers, non-static
> lifetimes etc, but Rust has been exploring the solution space for years
> now. It would be a shame to just ignore them, especially when people are
> already starting to do the same for C++:
> https://www.youtube.com/watch?v=hEx5DNLWGgA
>
>
> _______________________________________________
> Dlang-study mailing list
> Dlang-study at puremagic.com
> http://lists.puremagic.com/cgi-bin/mailman/listinfo/dlang-study
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dlang-study/attachments/20160119/5b8e1bfc/attachment.html>