Parameter storage classes on foreach variables

[Quirin Schroll]

On Saturday, 18 May 2024 at 22:43:48 UTC, Timon Gehr wrote:
> On 5/17/24 20:59, Quirin Schroll wrote:
>> As of now, `foreach` admits `ref` variables as in `foreach 
>> (ref x; xs)`. There, `ref` can be used for two conceptually 
>> different things:
>> * Avoiding copies
>> * Mutating the values in place
>> 
>> If mutating in place is desired, `ref` is an excellent choice.
>> However, if mere copy avoiding is desired, another great 
>> option would be `in`.
>
> I contest that `in` is a great option every time mere avoiding 
> of copies is desired (because it implies transitive `const`).

True. In generic code, one basically can’t use `const`, and 
therefore `in`, as a type can become simply unusable. (Prime 
example would be delegate types once they’re fixed.)

I case you know the type and it’s a type that works well being 
`const`, *then* `in` might be a great option.

> In general, extending `foreach` to `in` and `out` makes some 
> sense, but `out` is likely to be quite controversial, 
> especially the output range lowering. When I think of 
> `foreach`, I think of consuming a range, not producing one.

I thought the same, but on the other hand, there’s a keyword, so 
it absolutely won’t happen accidentally. It may just surprise 
people to read it in someone else’s code.

My sense is that everything that the stuff in a `foreach` header 
before the semicolon should support exactly the same things a 
lambda parameter list would simply because it may become a lambda 
passed to `opApply`. If it isn’t, well, it’s up for discussion 
what to do with it. Making it invalid is always an option.