DIP 1022--foreach auto ref--Community Review Round 1

Dukc ajieskola at gmail.com
Sat Aug 10 08:09:08 UTC 2019


On Friday, 9 August 2019 at 21:55:45 UTC, Manu wrote:
>
> Sorry if that sounded blunt.

No, not at all. I was just surprised that you questioned my core 
resoning, yet wanted the dip to move forward.

>
> Let me try and be more clear; by comparison, we can consider 
> [Snip]
> 
> I suspect from reading that you are trying to solve the second 
> case
> with this DIP, but it's already solved by Andrei's work (which 
> he
> presented at dconf).
> What this DIP should actually solve though, in the 3rd case. We 
> need that.

Hmm, you want to retain the current behaviour of `ref`? This 
confuses me, because `auto ref` I'm proposing has exactly the 
same semantics as `ref` does now, yet you also want it to be 
included.

My guess is that you're thinking the benefit of `auto ref` to be 
allowing to handle rvalue ranges without becoming a pointer 
internally, thus being more efficient in at least some cases. The 
rest of my answer assumes that was your point.

I disagree. I am not trying to target efficiency issues a all. If 
my problem was that, I'd simply propose foreach `ref` to use 
rvalue copies directly, not via internal pointers. Unlike in C++, 
refs and the values they point to are indistinguishable from D 
user perspective, so that is just an implementation detail that 
would probably get through even without a DIP. Unless it's 
already done.

The problem I'm targeting is that currently the compiler will not 
complain, if the user, when expecting to mutate range elements, 
iterates by `ref` over foreach. But since I know there's need for 
the notion I'm deprecating, I also suggest `auto ref` for the 
behaviour.

I know this is a kind of a jerk change, as it forces to change 
code. But I thought that the migration path is so simple (just 
changing `ref` to `auto ref` where you get deprecation messages) 
that avoiding it (see alternative 1 of the DIP) is not worth 
having a language inconsistency.


More information about the Digitalmars-d mailing list