On Friday, 25 January 2013 at 11:28:16 UTC, TommiT wrote:
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.
b didn't need to be assigned to null because the compiler could
determine it wasn't being directly accessed after that scope (it
was assigned to a new var first). It was intentionally left out
to illustrate how the compiler could optimize special cases like
that. I wrote that in my original post a bit after that code.
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?
If the compiler could determine that a ref was being used
directly after being cleaned up, then yes, the compiler could
throw an error. But that can't happen in every case, so when it
can't you'll get a runtime error. Sorry I wasn't clear about that.
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?
The specific code you're talking about is a demonstration of an
area where the compiler can't (like you said) determine at
compile-time the clean-up code, and therefor has to use a runtime
approach to nullifying references.
The issue you raise isn't really a problem though. If the memory
gets rearranged then the runtime could inform the DynamicArray,
and it, in turn, could reassign those refs to the new memory
address.
The idea here is that if you're writing something complex like a
Container, you may need to use the unmanaged 'ptr' type to get
the job done. However, such containers could still make safety
guarantees to their users. So if the standard libs provided
enough basic building blocks, and the compiler supported advanced
meta-programming features (like in D), then programmers would
rarely, if ever, need to touch a 'ptr' to make applications.
