On Wednesday, 9 August 2017 at 12:47:49 UTC, Steven Schveighoffer wrote:
> On 8/8/17 3:59 PM, Johan Engelen wrote:
>> 
>> In C++, it is clear that the _caller_ is doing the dereferencing, and the dereference is also explicit.
>
> In fact it's not doing any dereferencing. It's just under the hood passing a pointer.

Come on Steven, I thought you knew I am a compiler dev.

The caller _is_ doing dereferencing. That's what the '*' means semantically and it matters. [1]

>>> However, the in contract does actually enforce the requirement.
>> 
>> And adds null pointer checks even when clearly not needed.
>
> Clearly not needed? I thought the point was to ensure the reference is not null?

I meant code like this: `k->something(); foo(*k);` or `auto k = new Klass(); foo(*k);`.

Anyway, the point was to express the intent nicely.
I wasn't expecting having to explain the merits of passing by reference.

- Johan


[1] Going off-topic.
The alternative is dereferencing inside the callee (which is apparently the only option D semantically provides for classes). I showed the impact of this semantic difference in my DConf 2017 talk; here are links to  examples:
https://godbolt.org/g/rgvHTC  (C++)
https://godbolt.org/g/NCTeXo  (D)
It's a pity we are not able to pass classes "by reference" (per C++ parlance), for reasoning and readability, and performance. I still have to come up with a rationale for not having an explicit "*" for classes for when I am going to teach D.

On 8/9/17 1:05 PM, Johan wrote:
> On Wednesday, 9 August 2017 at 12:47:49 UTC, Steven Schveighoffer wrote:
>> On 8/8/17 3:59 PM, Johan Engelen wrote:
>>>
>>> In C++, it is clear that the _caller_ is doing the dereferencing, and the dereference is also explicit.
>>
>> In fact it's not doing any dereferencing. It's just under the hood passing a pointer.
> 
> Come on Steven, I thought you knew I am a compiler dev.

Of course I do! I'm not a compiler dev though :)

> The caller _is_ doing dereferencing. That's what the '*' means semantically and it matters. [1]

As a layman user, I consider dereferencing to be when you actually use the data pointed at by the pointer (i.e. you've followed the reference).

What you are doing when passing a dereferenced pointer through a reference is the same as just passing a pointer, it doesn't seem to me like there should be a difference.

>>>> However, the in contract does actually enforce the requirement.
>>>
>>> And adds null pointer checks even when clearly not needed.
>>
>> Clearly not needed? I thought the point was to ensure the reference is not null?
> 
> I meant code like this: `k->something(); foo(*k);` or `auto k = new Klass(); foo(*k);`.
> 
> Anyway, the point was to express the intent nicely.
> I wasn't expecting having to explain the merits of passing by reference.
> 

Sorry, not a C++ developer. I just think in terms of how the code translates to the instructions to the computer. To me, pointers and references seem very similar.

> [1] Going off-topic.
> The alternative is dereferencing inside the callee (which is apparently the only option D semantically provides for classes). I showed the impact of this semantic difference in my DConf 2017 talk; here are links to  examples:
> https://godbolt.org/g/rgvHTC  (C++)
> https://godbolt.org/g/NCTeXo  (D)
> It's a pity we are not able to pass classes "by reference" (per C++ parlance), for reasoning and readability, and performance. I still have to come up with a rationale for not having an explicit "*" for classes for when I am going to teach D.

I didn't think this comes from the dereferencing, I thought it came from the ability to rebind.

That is, inside the loop, the pointer potentially could have been set to something different, so it has to reload the data.

What you really want perhaps is a class parameter that cannot be rebound? That would more accurately duplicate a ref parameter.

-Steve