pointers, functions, and uniform call syntax

[Artur Skawina]

On 09/06/12 00:50, Era Scarecrow wrote:
> On Wednesday, 5 September 2012 at 11:01:50 UTC, Artur Skawina wrote:
>> On 09/04/12 20:19, Era Scarecrow wrote:
>>>  I ask you, how do you check if it's a null pointer? &s?
>>
>> Yes, obviously. If you need to do that manually.
> 
>  But you shouldn't have to.
> 
>>>   int getx(ref S s)
>>>   //How does this make sense?? it looks wrong and is misleading
>>>   in {assert(&s); }
>>>   body {return s.x); }
>>
>> It looks correct and is perfectly obvious. But see below - you don't need to do this manually - the compiler does it for you when calling methods and could handle the UFCS case too.
> 
>  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".

>  This is entirely valid and simplifies things. Remember in D we want the language to 'do the right thing', but if you make references where it works to 'sometimes works' then it becomes a problem (pointers 'sometimes' work and are not @safe, while ref is @safe). Checking the address of a reference shouldn't be needed, since it should be dereferenced at where it was called at if need be (throwing it there).

Pointers *are* @safe, it's just certain operations on them that are not.

>  Would you REALLY want to mark every single function that uses ref as @trusted? 

No idea why you think that would be needed.

>>>  More importantly, if it's now a possibility do we have to start adding checks everywhere?
>>>
>>>   int getx(S *s)
>>>   in {assert(s); } //perfectly acceptable check, we know it's a pointer
>>>   body {return s.x); }
> 
>>    struct S { int i; auto f() { return i; } }
>>    int main() {
>>       S* s;
>>       return s.f();
>>    }
>>
>> This program will assert at runtime (and (correctly) segfault in a release-build). The compiler inserts not-null-this checks for "normal" methods in non-release mode, and could also do that before invoking any UFCS "method". So you wouldn't need to check for '!!&this' yourself.
> 
>  I thought those checks weren't added (via the compiler) since if it causes a seg fault the CPU would catch it and kill the program on it's own (just add debugging flags); If you added the checks they would do the same thing (More buck for the same bang).

The checks happen for structs, and should be configurable, but right now
are not, which sometimes causes trouble.


On 09/06/12 08:18, Era Scarecrow wrote:
> On Wednesday, 5 September 2012 at 11:01:50 UTC, Artur Skawina wrote:
>> On 09/04/12 20:19, Era Scarecrow wrote:
>>>  I ask you, how do you check if it's a null pointer? &s?
>>
>> Yes, obviously. If you need to do that manually.
>>
>>>   int getx(ref S s)
>>>   //How does this make sense?? it looks wrong and is misleading
>>>   in {assert(&s); }
>>>   body {return s.x); }
>>
>> It looks correct and is perfectly obvious. But see below - you don't need to do this manually - the compiler does it for you when calling methods and could handle the UFCS case too.
> 
>  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.

artur