pointers, functions, and uniform call syntax

[Era Scarecrow]

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.