Blog Post: Lifetime Parameters in Rust

[shelby3]

Thanks for the reply.

@notriddle

Actually, we get people asking why borrowing adds extra syntax over moves, instead of the other way around, all the time.

I was arguing the same point as @Maledictus for Rust's current "lifetimes everywhere" design:

@shelby3

I am thinking that borrowing could possibly have been the better non-annotated default
...
I lean more to this stance now given I now know that borrowing really has nothing to do with whether some of the data structure for a function argument is stored on the stack, e.g. Vec, i.e. borrowing is orthogonal to performance issues of pass-by-value or pass-by-reference. And for that reason, I also find the use of the symbol & for borrowing to incite confusion given its historical meaning in C/C++ as it is ingrained in my mind to make take the address of and create a reference/pointer.

What does @steveklabnik1 mean by "silently putting things behind a pointer" below? I thought borrow was orthogonal to representation on the stack or heap as we discussed upthread, and was only signifying lifetime semantics checking.

@https://www.reddit.com/r/rust/comments/40zyun/eli5_why_default_to_move_ownership_on_function/cyyjl6f

Yes. However, I think that wouldn't be a great way to do it. Silently putting things behind a pointer, and then verbosely just giving you the thing feels backwards to me.

@steveklabnik1's point reaffirms to me that "lifetimes everywhere" is complex. Taking borrows in the same code block feels like minutia (and then I need an artificial braces scope to handle some cases).

@notriddle

Nobody asks for "actually lifetime checking off," because that would make Rust a memory-unsafe language. Is that a typo?

I was referring not to Rust's current "lifetimes everywhere" design-philosophy, but to a potential alternative design-philosophy which I am contemplating would be "GC everywhere except where we can get compile-time lifetimes at very low complexity" especially to improve upon GC's overhead with freeing temporary objects.

I've thought a little bit more about my idea and the following is where I am with it thus far:

• let can only declare owned (including Copy) instances or GC instances. No borrows. The non-annotated default is GC instance. I'm thinking := instead of = for owned instances.
• Functions take compile-time enforced borrows on those arguments which are not annotated. No compile-time checked moves are allowed.
• The optional annotation on function arguments (perhaps :: instead : since it means the function is keeping a reference to the instance indefinitely) declares the argument to a GC instance. So use this to handle all cases that compile-time checked borrowing won't. Note GC instances can be input to either type of function arguments, but lifetime-checked instances can only be input to compile-time enforced borrowed arguments.
• No lifetime parameters. Input lifetimes can't be transferred to outputs.
• Function outputs are allocated as lifetime-checked or GC instances according to the function body, and lifetime-checked can be converted to GC instance (but not vice versa, because GC instance wouldn't have been forced to be borrowed within the function body) based on the assignment of the function output by the caller.

So essentially afaics I am encouraging the programmer to do compile-time borrowing as much as possible, so compile-time ownership can be used sometimes. For all other cases, GC is employed.

This seems much simpler. Afaics, there is nothing unsafe in terms of "use after freed" memory deallocation.

I am thinking mutability should not be compile-time checked at such a low level in terms of disallowing for example two mut references to same instance. Instead use higher level abstractions which enforce mutability when desired. I am contemplating to only allow mut on let and function arguments (and btw I would prefer val and var instead of let mut and let and make function arguments val by default and they can optionally been prefixed with var to make them mutable).

@shelby3

@keean

I would guess because the pointer arithmetic requires a raw pointer, it does not get the same safety checks as other references. I am not sure all collections would need unsafe code (for example to iterate a linked list may not), but for a slice (Rust equivalent of an array) we need pointer arithmetic, which means some unsafe code in the increment and dereference functions:
...
But thats just the implementation of a specific iterator. The generic methods and traits have no unsafe code, and you would need unsafe code to implement a collection like a vector or an array in the first place. My aim here is to replicate the EoP algorithms as they are for the moment. I have some ideas about adding safety checks at only specific points that will make the library safe to use, although it will require the library implementation to be correct. This follows my general rule of expert library implementors get to do unsafe things internally, but expose safe interfaces to the user (if I can make that bit work of course).

It seems to me that enforcing mutability exclusiveness at the low-level is not desirable. There will always be unsafe code. There is no such thing as a compiler that only produces safe code. Semantic mutability bugs and "memory leaks" will still occur with Rust. The only way to improve matters is high-level encapsulation, of which the examples I provided in this thread exemplify.

Radical brainstorming.