Comment by Animats | Hacker News Reader

Comment by Animats | Hacker News Reader

Parent Full thread

The big question with Rust lifetimes was "can you tighten the screws down that tight and still do anything"? Rust managed to get it to work reasonably well. This lightens it up a bit.

It's not clear to me how far this goes. One annoying Rust idiom is having to allocate something, then pass it into a function so the function can return it. There's no way to give a return value the lifetime of the caller, not the callee. Will this change allow that? It doesn't look like it.

This is more in the other direction. "In the new proposal, the lifetime of a reference lasts only for those portions of the function in which the reference may later be used (where the reference is live, in compiler speak)." In modern compilers, when a local variable has been used for the last time in its scope, it's dead, and its storage can be reused. This is mostly done to free up registers. It seems to be exposing liveness analysis at the source level.

The use cases aren't that convincing. This may be more of a "because we can" feature.

> There's no way to give a return value the lifetime of the caller, not the callee.

That is, in the general case, not physically possible, and this sort of thing only works in GC languages because they return GC pointers to dynamically allocated data. It certainly doesn't exist in C or C++ (unless I completely misunderstood what semantics you wanted).

AFAIK there is no implementation of anything (not even JITs) which can allocate on the caller's stack. The closest anything gets is Forth where the call stack and data stack are separate and returning just leaves data on the stack for caller to read.

Without a split stack, returning something larger than a register (or two) is done by passing a pointer to space on the caller's stack, to the callee.

There have been very specific schemes proposed for `-> [T]` in Rust, e.g. the slice is left of the callee's stack, and a pointer to it returned, so the caller can allocate that much stack space and memmove'd it up.

But that wouldn't help with "allocating" on the caller's caller's stack because moving the data would invalidate references to it (and if you can have a reference to something, you can use it in ways the compiler can't trace it, unlike a GC).

You can surely allocate on callers stack on C++, that is how return value optimization works, and was made explicit on ANSI C++17 standard.

Well, in that sense, Rust does return value optimization too, and it has been doing so basically since forever. Because Rust has no copy constructor, RVO in Rust does not need any explicit support from the language specification.

That's not allocating on the callers's stack though, that's just initialising there. The caller does the allocation.

And Rust does RVO, in fact it's important for "placement new" structures until the dedicated syntax lands.

Right. Just think of the return value as an additional mutable formal parameter, and function return values as syntactic sugar for that additional parameter. The caller allocates space for the actual parameter.

To be more explicit

   y = f(g(h(x)));

is really

   var hreturn;
   h(x, hreturn);
   var greturn;
   g(hreturn, greturn);
   // hreturn is no longer live
   var y;
   h(greturn, y);
   // greturn is no longer live

Looked at this way, a function can return any fixed-size type without a copy. Some languages, mostly those in the Pascal/Modula family, did this explicitly. Instead of having a return statement, within a function, the name of the function was the return value, and code could assign to it, or pass it by reference to another function.

IIRC ada can return variable sized objects on the stack.

> This may be more of a "because we can" feature.

What I see is actually "it's wanted/needed enough that it's worth putting in the huge effort to make such a complex (and novel?) system reality".

EDIT: to be more clear: what's new here isn't "exposing liveness at the source level" but "model liveness in region typing". If we were changing when the destructor runs (which we can't because backwards compatibility - also, doubtful we'd want that at all), that would be more "source level".

Believe me, all use cases there are based on actual user complaints and this is in no way "because we can" feature.

It's also a solid stepping stone to the next level of unergonomic problems with lifetimes.

Can you provide specific examples?

Reply on news.ycombinator.com