`@rvalue ref` and `@universal ref`

[IchorDev]

On Tuesday, 6 August 2024 at 15:26:49 UTC, Quirin Schroll wrote:
> On Monday, 29 July 2024 at 05:52:40 UTC, IchorDev wrote:
>> Also I’m not sure about the at-attribute-based syntax. It 
>> makes the feature feel like an afterthought, even though this 
>> functionality is very useful. Perhaps a better solution 
>> syntax-wise could be to use `in` as the ‘rvalue’ attribute, 
>> and `auto in` could be the ‘universal’ attribute. So then:
>> - `@rvalue` —> `in`
>> - `@rvalue ref` —> `in ref`
>> - `@universal ref` —> `auto in ref`
>> - `@universal auto ref` —> `auto in auto ref`
>
> The issue is, it can’t be done anymore. For all the time it was 
> there, `in` meant `const`.

And it still does. Just this week I’ve had to dissuade two people 
from using `in` instead of `const`.

> Also, and this is the key killer: Conceptually, `in` means 
> input parameter, i.e. something that supplies your function 
> with data to make decisions on, call it configuration if you 
> like

This meaning is nebulous at best. What would we actually make 
`in` *do* to have it make parameters inputs? `-preview=in` making 
`in` into `scope ref const` that binds to rvalues is just as 
related to a parameter being an input as `in` binding to rvalues 
in general is.

> and this is what informed the `-preview=in` semantics.

And time has proven that `-preview=in` is:
1. never going to become the default; and
2. is too limiting to even be very useful.

Your DIP would make `-preview=in` an obsolete dinosaur, so just 
replace it.

> Another aspect I don’t like stylistically, is `auto in`. As a 
> parameter storage class, `auto` means infer and requires 
> templates, plus one could introspect what the inference 
> determined.

Is that a huge problem? You could always try suggest a better 
syntax for that case though, I was just invoking a recognisable 
idiom.

> Contrary to that, `@universal` requires materializing rvalues. 
> Essentially, binding `arg` to a `@universal ref` parameter 
> would be exactly like passing `arg.materializeU.value` to a 
> `ref` parameter, and likewise passing `arg.materializeR.value` 
> for binding to an `@rvalue ref` parameter.

I think you should try rephrasing this because it doesn’t make 
sense.

>> This way it’s […] shorter to write
>
> That I consider the wordiness a win[sic]. Not only is it 
> clearer […]

It’s harder to read more text, particularly when it overflows the 
available horizontal space. It’s not ‘clearer‘ at all.

>> […] [A]nd we can **finally** make `in` do something useful by 
>> default.
>
> But `-preview=in` already does that.

`-preview=in` is not the default. Saying that ‘as long as you 
change the defaults, the defaults are good’ is misleading. 
`-preview=in` is not the default. No matter how we move forwards 
with `in`, something is going to break; but I think making `in` a 
useful feature instead of dead-on-arrival would be a welcome 
change rather than a disappointing one.