Sorry, my lines got mangled, let me try pasting it again.
Making scope the default
=======================
There's five points to discuss:
1) All variables are assumed to be marked with scope implicitly
2) The exception is structs with a special annotation which marks
that they encapsulate a resource. An encapsulated resource
explicitly marked scope at the usage site is STILL scope, but it
will not implicitly inherit the scopiness of the member reference/
@encapsulated_resource
struct RefCounted(T) {
T t; // the scopiness of this would not propagated to
// refcounted itself
}
This lets us write structs to manage raw pointers (etc.) as an
escape from the rules. Note you may also write
@encaspulated_resource struct Borrowed(T){} as an escape from the
rules. Using this would of course be at your own risk, analogous
to @trusted code.
3) Built-in allocations return GC!T instead of T. GC!T's
definition is:
@encapsulated_resource
struct GC(T) {
private T _managed_payload;
/* @force_inline */
/* implicit scope return value */
@safe nothrow inout(T) borrow() { return _managed_payload; }
alias borrow this;
}
NOTE: if inout(T) there doesn't work for const correctness, we
need to fix const on wrapped types; an orthogonal issue.
If you don't care about ownership, the alias this gives you a
naked borrowed reference whenever needed. If you do care about
ownership:
auto foo = new Foo();
static assert(is(typeof(foo) == GC!Foo));
letting you store it with confidence without additional steps or
assumptions.
When passing to a template, if you want to explicitly borrow it,
you might write borrow. Otherwise, IFTI will see the whole GC!T
type. This is important if we want to write owned identity
templates.
If an argument is scope, ownership is irrelevant. We might strip
it off but I don't think that's necessary... might help avoid
template bloat though.
4) All other types remain the same. Yes, typeof(this) == T, NEVER
GC!T. Again, remember the rule of thumb: would this work with as
static stack buffer?
class Foo { Foo getMe() { return this; } }
ubyte[__traits(classInstanceSize, Foo)] buffer;
Foo f = emplace!Foo(buffer); // ok so far, f is scope
GC!Foo gc = f.getMe(); // obviously wrong, f is not GC
The object does not control its own allocation, so it does not
own its own memory. Thus, `this` is *always* borrowed.
Does this work if building a tree:
class Tree { Tree[] children; Tree addChild(Tree t) {
children ~= t; } }
addChild there would *not* compile, since it escapes the t
into the object's scope. Tree would need to know ownership: make
children and addChild take GC!Tree instead, for example, then it
will work.
What if addChild wants to set t.parent = this; ? That wouldn't
be possible (without using a trust-me borrowed!T wrapper)... and
while this would break some of my code... I say unto you, such
code was already broken, because the parent might be emplaced on
a stack buffer!
GC!Tree child = new Tree();
{
ubyte[...] stack;
Owned!Tree parent = emplace!Tree(stack[]);
parent.addChild(child);
}
child.parent; // bug city
Instead, addChild should request its own ownership.
Tree addChild(GC!Tree child, GC!Tree _this) {
children ~= child;
child.parent = _this;
}
Then, the buggy above scenario does not compile, while making
it possible to do the correct thing, storing a (verified) GC
reference in the object graph.
I understand that would be a bit of a pain, but you agree it
is more correct, yes? So that might be worthwhile breakage
(especailly since we're talking about potentially large breakage
already.)
5) Interaction with @safe is something we can debate. @safe works
best with the GC, but if we play our scope cards right, memory
corruption via stack stuff can be statically eliminated too, thus
making some varaints of emplace @safe too. So I don't think even
@safe functions can assume this == GC, and even if they could, we
shouldn't since it limits us from legitimate optimizations.
So I think the @safe rules should stay exactly as they are
now. Wrapper structs that do things like malloc/realloc might be
@system because it would still be possible for a borrowed pointer
to be invalidated when they realloc (note this is not the case
with GC, which is @safe even through growth reallocations). So
@safe and scope are separate issues.
