On Monday, 21 January 2013 at 17:37:38 UTC, F i L wrote:
type Foo
{
var bar = 0
}
func main
{
ref f : Foo
ref b : int
scope
{
var foo = Foo # allocates Foo
f => foo # f points to foo
f.bar = 1 # foo.bar = 1
b => f.bar # b points to foo.bar
b = 3 # foo.bar = 3
# auto 'clean up code' at end of scope:
#
# Memory.delete(foo)
# f => null
#
}
f.bar = 4 # ERROR: f is null
I think there should be also b => null in the implicit 'auto
clean up' phase.
I think it's good to note whether errors are compilation errors
or runtime errors. I assume f.bar = 4 in the end there would be a
compilation error?
On Friday, 25 January 2013 at 02:12:56 UTC, F i L wrote:
var nums = int[] # DynamicArray(int)
ref a, b : int
func main
{
nums += 1 # allocate
nums += 2 # allocate
nums += 3 # allocate
a => nums[2] # nums.=>(2, a)
b => a # nums.=>(2, b)
What if we now (after the code snippet above) write:
nums += 4
And nums has run out of room in its place in the heap and needs
to re-allocate its data (4 ints now). I guess that would mean
that the call += should nullify all refs pointing to nums (a and
b). If we now write:
a = -3
...that can't be a compilation error. Because it's not known at
compile-time whether or not nums += 4 forces a re-allocation.
Wouldn't this mean then, that all accesses through references
would require a runtime penalty for checking whether the ref is
null or not?
