Mandatory inlined functions for unsized types and 'super lifetime?

[nakacristo]

I have re-read the thread and I think I have been missing some point. As @elidupree says we can already return a reference or data by using Cows.

@elidupree

fn upper_if_odd(s: &str) -> Cow<str> {

• If the issue is that we want to allocate a different type than the one we want to reference, then we could generalize Cow. For example to allocate (A,B) and get &A we could impl CowFor<A> for (A,B). This could help with the comment

@petertodd

Secondly, I'll point out that return value optimization in general has issues when you want to return part of a larger object: let super could allow you to be explicit as to what you want to put in the callers stack frame, even in cases where you're only going to logically return a subset of the data. Eg if I return the latter half of ([u8; 1_000_000], [u8; 1_000_000]) I may still want both parts allocated once, at the top of the call stack so as to avoid copying it over and over.

• If the issue are that we do not get enough return value optimizations then we could help the compiler with annotations to hint what variables could be allocated in the caller stack, but without changing any meaning.
• If the issue is that we are too lazy to write Cows or find them to pollute the programming logic, then we could make some macros to wrap them automatically.
• If the issue is specific to unsized types, as mentioned by @petertodd then I have yet to see more clearly the intended use.

@petertodd

I'm not. There's a few ideas I'm talking about in this thread. An important category of them being able to return unsized types. Currently, Rust functions can only return sized values, and it's not at all clear what's the best way to support unsized values. RVO can't help that use-case.

Although I have mixed them before, now I think these are different issues and should be addressed separately.

[H2CO3]

Sorry, I was referring to dhm's reply.

[illicitonion]

@dhm

we just need that existential impl Sized in argument position to work

What specifically does this enable? I had been reading the existential impl Sized as mostly sugar (to avoid needing to write out more verbose types, and to make sugar easier to write), rather than fundamentally changing much?

[atagunov]

@dhm

let mut v = vec![];
for _ in 0 .. n {
    v.push(f2());
}

We agree that that should not compile, right? ( None slot reused).

@petertodd

I would expect that to work

Do you mean to say it could work with inlining and alloca-s?

Without allocas I don't see how it could work.. f2() allocates an object in its parent's frame and returns a reference to it. The reference is stored in a Vec and outlives a single loop iteration. This is done an unknown number of times. It wouldn't be safe to always return reference to the same object - the vector would end up containing duplicate references. And we wouldn't know how large a buffer to allocate if we wanted to allocate a new object on each iteration of the loop..

@H2CO3

If the intention is to be able to return unsized locals by-value ...

• -> impl Trait already exists
• -> [T] could similarly exist

What has been suggested in this thread is a little more general: a way to create several (potentially linked) objects in (grand)-grand-..parents' frames. If that is useful enough or not is a different question.

@H2CO3

@atagunov 's example still doesn't show anything that's not possible today by passing a &mut [T] explicitly

I guess my example implied some extra niceties:

• the total buffer size is automatically computed for the caller and used in the callee
• the caller does not know nor care what types exactly the callee allocates in the buffer
• multiple values of different types can be constructed in the same buffer without unsafe code
• the buffer does not need to be initialized by the caller

...but indeed the sprit is very similar to passing in a &mut[..]

[petertodd]

@atagunov

Do you mean to say it could work with inlining and alloca -s?

Without allocas I don't see how it could work.. f2() allocates an object in its parent's frame and returns a reference to it. The reference is stored in a Vec and outlives a single loop iteration. This is done an unknown number of times. It wouldn't be safe to always return reference to the same object - the vector would end up containing duplicate references. And we wouldn't know how large a buffer to allocate if we wanted to allocate a new object on each iteration of the loop..

Oh sorry, I misunderstood the definition of f2() that @dhm was using: I thought it was referring to returning logical ownership, not a borrowed reference.

Yes, I would expect returning a borrowed reference to not work, even with alloca. Or to be precise, if we choose semantics where it does work, the lifetime of that reference can't escape the loop body. There's actually a very simple reason for this:

fn f2<super 'a, T>() -> &'a T;

What has ownership of T? Something has to own the T value for the reference to be valid. Meanwhile I'd expect this to work, because push is taking ownership of a T value once per iteration:

fn f2<super 'a, T>() -> &'a own T {
    /* ... */
}

fn foo(n: usize) -> Vec<T> {
    for _ in 0 .. n {
        v.push(f2());
    }
}

I think the most clear semantics for this is via &'a own T, which makes clear what is responsible for running drop.

Second, in implementations that do support alloca, I'd suggest ensuring that alloca can only be called once per function call site, and the effect of that call must be undone prior to that function call site happening again. That would ensure that total stack usage is bounded even in loops. Though actually implementing that rule could be tricky.... I haven't thought about this super carefully. But it feels like modulo references, you can at least always come up with some sequence of data moves to undo the effect of an alloca with the above rule. But needs more thought.

[atagunov]

@petertodd

Though actually implementing that rule could be tricky

Hmm.. I hoped it would be fairly simple. Say, for each super lifetime we parameterize a function invocation with in the caller

• make sure that this lifetime outlives no enclosing loop
• limit all closures that it outlives but is enclosed by to implementing FnOnce

Anything else really?

[atagunov]

@dhm

The main thing needed to do that, and imho, it wouldn't really need that much sugar, would be existential types in argument position

Can't yet put a finger on it.. but it seems this sort of buffers/existentials could help support anonymous enum types for example to return errors Zig-style.

Yes this doesn't take trait objects into account yet.. But if you limit yourselves to monomorphisations only it seems entirely feasible to examine your whole call graph and compute what is the biggest number of bytes you need to store an Error which can arise at this point. Then some parent level function could provide the buffer to allocate such errors in, say on its stack.. so that they could be returned by value..

Yes the idea is still very rough