DIP1000: The return of 'Extend Return Scope Semantics'

[Zach Attack!]

On Wednesday, 26 May 2021 at 12:36:42 UTC, Atila Neves wrote:
> It's not arbritrary at all - the purpose is to avoid this:
>
> https://carols10cents.github.io/book/ch10-03-lifetime-syntax.html#lifetime-annotations-in-function-signatures
>
> Reasonable people of course can disagree on whether or not 
> avoiding that is a good idea.

Proposal: Solve the problem incrementally. Start with a single 
pre-named routing channel (i.e. lifetime) supported directly by 
the compiler. Call it `@__in1`  and `@__out1` (these are 
parameter attributes). The compiler will track this lifetime in 
addition to the `scope` and `return` lifetimes. It’s possible 
that this one additional channel will solve all use cases.

If later on, someone provides an undeniably compelling use case 
for additional lifetime channels, simply add `@__in2` and 
`@__out2`, `@__in3` and `@__out3`, etc. as the case requires.

The assumption upon which this solution is based is that Rust’s 
user-named "dictionary of lifetimes" is **complete and total 
OVERKILL**, that the actual number of lifetimes a function ever 
really must track is so small that the tracking mechanism can be 
incrementally baked into the compiler itself. (If I’m not 
mistaken, a baked-in lifetime requires only two bits of compiler 
memory per parameter to track, and only one bit for other 
variables.)

For the most part, users would hardly ever see `@__in1` and 
`@__out1` since they would be inferred by templates, and rarely 
used anyway. But for cases like phobos’ `move`, the facility 
would be available.

Hope you like my suggestion.

Zach