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

[Marc Schütz]

On Sunday, 1 November 2015 at 22:09:04 UTC, deadal nix wrote:
> There has been a fair amount of discussion about RC here, but I 
> think it is missing the bigger picture.
>
> There are a lot of variation of RC that can be done, but it 
> doesn't really matter. After all, the problem that we want to 
> solve as languages designer here is to control how references 
> escape.

Needless to say, I agree. But various proposals to achieve that 
goal have been dismissed as "too complicated". I think this is 
therefore what we have to tackle first.

I can see complexity in three forms:

1.) Complexity of the concept

A system equivalent to Rust's is very complicated and requires 
various analysis passed to be added to the compiler frontend, 
considerably increasing the language's complexity. While I think 
that the escape analysis itself can be fairly simple (Walter's 
already implemented it partially for DIP25), a larger difficulty 
seems to be to make sure that the original owner does not somehow 
get invalidated during the lifetime of dependent references. This 
involves alias analysis. It also is an additional burden for the 
users and their understanding of the language.

Maybe there is a way to get the same guarantees that Rust 
provides by adding some additional restrictions that would enable 
both the implementation and the concept to be easier to 
understand? Or attacking the problem from a different angle, 
could we cut back on the guarantees (making some corner cases 
unsafe) to reduce the complexity?

There's also the question whether we want to integrate the 
related topic of uniqueness at the same time.

2.) Complexity in use of the language

Walter and others have rightly pointed out that we already have a 
plethora of annotations. We have to be careful not to make the 
situation worse. There are different ways to handle this: a) we 
can have the compiler infer attributes/annotations in more cases 
that it does now, and b) we can change some defaults so that 
frequent patterns are enabled by default and have to be opted out 
if necessary. Both ways will likely break some existing code, so 
we have to weigh out options and decide how much breakage is 
acceptable to simplify common use cases.

There's also the general point of ergonomy. The feature should 
integrate well with the existing language, and it shouldn't "get 
in our way". The latter is not only important for those who don't 
want to use it, but also for those who do, because we want to 
make it as easy as possible to write safe and efficient code that 
takes advantage of it.

3.) Compatibility

While it is probably possible to introduce this feature without 
breaking any code, this goal clashes with ease-of-use. If we make 
it completely opt-in (e.g. by requiring special keywords), this 
would mean that none of the existing code, including Phobos, is 
usable with it. We would essentially create a new version of the 
language.

We therefore need to design the feature in a way so that as much 
code as possible is automatically compatible. For example, many 
of the string processing functions only borrow references to the 
original string and don't keep them around after they returned; 
likewise, many of them return a reference to it. It would be nice 
if those need as few modifications as possible (ideally none) to 
take advantage of this fact.