pointers, functions, and uniform call syntax

[Carl Sturtivant]

On Monday, 3 September 2012 at 19:49:14 UTC, monarch_dodra wrote:
> On Monday, 3 September 2012 at 18:45:42 UTC, Jonathan M Davis 
> wrote:
>> On Monday, September 03, 2012 14:13:10 monarch_dodra wrote:
>>> I was playing around with a very big struct, and told myself I
>>> wanted it allocated on the heap. This meant I was now
>>> manipulating S* instead of an S.
>>> 
>>> I thought "this should have zero impact, because in D, because
>>> "." is supposed to deference for you if needed."
>>> 
>>> I find it strange though that when trying to call a function 
>>> with
>>> a pointer, the pointer isn't automatically dereferenced if 
>>> needed:
>>> 
>>> ----
>>> struct S
>>> {
>>>   void foo();
>>> }
>>> void bar(S);
>>> void main()
>>> {
>>>   auto r = new S;
>>>   r.foo();
>>>   bar(r);  //derp
>>>   r.bar(); //derp
>>> };
>>> ----
>>> I find it strange, because I thought the entire point was to
>>> abstract way something was allocated to the way it was used: 
>>> EG.
>>> From a caller perspective, I don't care if r is on the stack 
>>> or
>>> on the heap: I just want to call the method bar on the object 
>>> in
>>> question.
>>> 
>>> Why does one consider a "free standing" function more 
>>> ambiguous
>>> than a member function?
>>> 
>>> Things get even stranger if you mix in uniform call syntax.
>>> "r.foo()" works, but "r.bar()" doesn't?
>>> 
>>> Am I really forced into:
>>> ----
>>> struct S
>>> {
>>>   void foo();
>>> }
>>> void bar(S);
>>> void main()
>>> {
>>>   auto r = new S;
>>>   r.foo();
>>>   bar(*r);    //Groan
>>>   (*r).bar(); //Super Groan.
>>> };
>>> ----
>>> I feel as if I'm just back at square 1...
>>
>> All that UFCS does is make it so that if the first parameter 
>> of a function is a
>> given type, you can call that function on that type as if it 
>> were a member
>> function. It's purely syntactic convenience.
>>
>> void bar(S) {}
>>
>> takes an S, not as S*, so I wouldn't expect UFCS to work with 
>> it and an S*.
>>
>> . dereferences a pointer when accessing a member function or 
>> variable, because
>> it works quite nicely to have it work that way and generally 
>> negates the need
>> for a second operator (->). It's certainly _not_ true that the 
>> automatic
>> dereferencing with . allows you to forget that something is a 
>> pointer. An
>> operation which _could_ be on the pointer (e.g ==) will 
>> operate on the
>> pointer, forcing you to dereference it. It's just that adding 
>> -> on top of .
>> is unnecessary and complicates the language.
>>
>> The choice to have . automatically dereference pointers when 
>> access members
>> predates the idea of UFCS considerably, and I don't think that 
>> it was ever
>> really considered how they two would interact.  The automatic 
>> dereferencing of
>> a pointer doesn't really have anything to do with UFCS except 
>> for similarites
>> of syntax. It's simply that if a variable is a pointer, and it 
>> points to a
>> type which has a member with the same name as what's on the 
>> right-hand side of
>> the dot, then that member function gets called. And 
>> technically, it doesn't
>> even dereference the pointer, because the member function 
>> takes a pointer (as
>> the invisible this pointer). If there is no such member 
>> function, then free
>> functions are checked to see if they take the variable's type 
>> as their first
>> argument. If there's such a function with the right name and 
>> number of
>> arguments, then it's used. For there to be any dereferencing 
>> involved would
>> require special casing pointers, which doesn't currently 
>> happen.
>>
>> I think that the way that it currently works is completely 
>> consistent. It's a
>> perfectly valid enhancement request to want
>>
>> void func(S s, int i) {...}
>>
>> to be be callable with S*, given that normally function calls 
>> on an S* don't
>> require you to dereference anything. But it's not like what we 
>> have is broken.
>> It's just that there's a corner case which forces you to deal 
>> with pointers
>> specially (which isn't exactly new, because things like == and 
>> assignment
>> already require you to treat pointer specially). So, feel free 
>> to create an
>> enhancement request. You've found a corner case that I suspect 
>> was never fully
>> though through, and Walter may very well think that the change 
>> is worth
>> making.
>>
>> However, one thing to remember that complicates this a bit is 
>> that it's
>> perfectly possible to declare a function which is overloaded 
>> with one function
>> taking a pointer and one not.
>>
>> void func(S* s, int i) {...}
>> void func(S s, int i) {...}
>>
>> in which case, there's an ambiguity, and I would then expect 
>> UFCS to _not_
>> compile when using S*, or you'd risk function call hijacking. 
>> That's not
>> necessarily a big deal, but it _does_ complicate things a bit.
>>
>> - Jonathan M Davis
>
> TY for the reply, I'll consider asking for it.
>
> In the mean time, is there a way to access that variable with 
> value semantics? I mean, in the scope where my pointer was 
> declared, I *know* it is non null.
>
> In C++, I often did it with iterators:
> ----
> for(it ...)
> {
>     int& val = *it;
>     //now, we can access it with value semantics through val.
> }
> ----
>
> ?

Good question, I've proceeded in the same way in C++ many times. 
I hope there's a way, but I think it likely there is not, except 
by passing *it to a function with a reference parameter.