RFC: scope and borrowing

[Marco Leise via Digitalmars-d]

Am Sun, 24 Aug 2014 13:14:43 +0000
schrieb "Marc Schütz" <schuetzm at gmx.net>:

> In the "Opportunities for D" thread, Walter again mentioned the 
> topics ref counting, GC, uniqueness, and borrowing, from which a 
> lively discussion developed [1]. I took this thread as an 
> opportunity to write down some ideas about these topics. The 
> result is a rather extensive proposal for the implementation of 
> borrowing, and its implementations:
> 
> http://wiki.dlang.org/User:Schuetzm/scope

The amount of possible use-cases you listed for this extension is
staggering. It surely carries its own weight.
scope!(ident1, ident2, ...) was quite clever. inout could
borrow from this.

> This is not a real DIP, but before I put more work into 
> formalizing it, I'd like to hear some thoughts from the languages 
> gurus here:
> 
> * Is this the general direction we want to go? Is it acceptable 
> in general?
> * Is the proposal internally consistent?

Can anyone tell without actually implementing it? :)
You could try to formalize some error messages and how the
compiler's reasoning would go. What happens when I pass
identifiers to scope!(…) return types?
- Can the compiler look up the identifiers' types and scopes
  in all cases?
- Will the compiler deduce the return type from these
  identifiers? E.g. "scope!(someString) ref getString();" will
  work like in your example? I don't think so, because the
  "lifetime identifiers" could be structs containing the
  returned type.
- What if we used incompatible types like
  "scope!(someString, someIntPtr)" there?
- What about variables?

  static int someInt = 32;
  string someString;
  scope!(someString, someInt) int* x;
  x = &someInt;

  Is the declaration of x in error? Strings don't contain
  integers unless unsafe casts are used, so why would they
  narrow the lifetime of an integer reference?

- Is it necessary to keep around all declared lifetime
  identifiers? In the snippet above (assuming it is valid), it
  looks like the shorter lived `someString' is enough to
  establish the semantics.

> * How big would the effort to implement it be? (I suspect it's a 
> large amount of work, but relatively straightforward.)
> 
> [1] http://forum.dlang.org/thread/lphnen$1ml7$1@digitalmars.com

-- 
Marco