Am Sun, 24 Aug 2014 13:14:43 +0000 schrieb "Marc Schütz" <[email protected]>:
> 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/[email protected] -- Marco
