On Thursday, 6 September 2012 at 10:29:17 UTC, Artur Skawina
wrote:
On 09/06/12 00:50, Era Scarecrow wrote:
How I'm understanding references in D (And perhaps I'm
repeating myself in two different topics) is they point to
live variables (IE guaranteed pointers), and remains this way
until you return from that function.
The struct example I gave previously (quoted below) shows how
easily you can end up with a null reference in D; refs are
*not* guaranteed to be live. It's not just about pointers:
class C { int i; auto f() { return i; } }
int main() {
C c;
return c.f();
}
Here you won't even get an assert error, just a segfault. But
the pointer-to-class (reference type in general, but so far
there are only classes) model chosen in D is wrong; this
probably contributes to the confusion about refs, because they
behave differently for classes. Let's ignore classes for now,
they're "special".
Yeah, they are allocated, and 'can' still contain a null
reference (or be deallocated/voided) in some way, so are pointers
automatically.
Pointers *are* @safe, it's just certain operations on them that
are not.
To my understanding I thought pointers (almost everything of
them) was not covered in SafeD/@safe code. True as long as you
don't mess with the pointer, than the object could remain valid
(assuming it was allocated), but you automatically go into
low-level code, and in trusted or system programing.
Would you REALLY want to mark every single function that uses
ref as @trusted?
No idea why you think that would be needed.
Because we aren't allocating everything on the heap. Maybe I'm
just seeing things at a very different angle than you. Maybe I
need a core dump for my head.
I've been thinking about this; It would definitely be the
wrong thing to do. The assert would _Always_ succeed. The
address you get would be of the pointer/reference for the
stack (the pointer
No, that's not how ref args work. '&s' will give you the
address of the object (eg struct). A reference type like
'class' has another (internal) level of indirection so in that
case you would get a pointer to the class-reference. But that's
how classes work internally, the 'object' in that case is just
the internal pointer to the "real" class data. Taking the
address of an argument gives you a pointer to it in every case.
Curious. Both ways could be correct. But somehow I don't think
so...
Alright let's go the opposite direction. Give me an example in
which passing a variable (by reference to a function) would EVER
require it to check the address to see if it was null.
Class/allocated objects should fail before the function gets
control. ie:
void func(ref int i);
class X {
int i;
}
X x;
int* i;
int[10] a;
func(x.i); /*should fail while dereferencing x to access i,
so never gets to func*/
func(*i); //does this count as a lvalue? Probably not,
func(a[0]);//none of these three should compile with that in mind
func(0);
Being named variables, and likely non-classes you are then left
with mostly local variables, or arrays, or some type of pointer
indirection issue. But ever case I come up with says it would
fail before the function was called.
