czw., 20 mar 2025 o 23:40 Jeremy Rifkin via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> Hi,
>
> This idea would benefit from a lot of elaboration on exactly how this proposed decay is supposed to happen and when.
>

Rule of thumb would be in same place where `int[5]` would decay to `int*`.
And this new operator would control `std::decay_t` result too.

In my previous email I said that it should behave similar to
array-to-pointer conversion
but after checking standard text it has a bit more broader usage that
I would like.
Adding this to the user-defined conversion step would be asking for problems.
Probably only in couple of relevant places of usage array-to-pointer we should
put this user defined decay operator.

> > Some consider this "bad feature" but for me this is more is "bad
> implementation" of "good feature".
>
> It's broadly considered a bad feature because implicit conversions can be subtle and surprising. This does not change with implementation.
>
> > I think that many user defined types could benefit from this functionality.
> > Proxy objects
>
> Can you clarify how you think some sort of user-specified decay helps the proxy object case? That already works fine as-is.

Problem with proxy is when passed as value it still behaves as reference type.
This means it can dangle or update spruce unexpectedly.
And there is no generic way to prevent it, if we could use decay then it become
near generic operation of getting rid of references and proxy objects.
Consider this code:

```
assert(x != y);
auto a = x;
a = y;
assert(x != y); //ups... proxy

auto b = temp()[10]; //only proxy is dangling
```

and:

```
assert(x != y);
auto& a = x;
a = y;
assert(x == y); //ok for majority of types

auto& b = temp()[10]; //always dangling
```

with this decay proxies will have limited range it will unexpectedly
propagate as values,
and only by using `&` you can expand its reach and this has benefits
for being more visible.

>
> > Expression templates
>
> What you're describing is a bug in the implementation of that expression template. I'm also not sure how decay is supposed to help that.

Its not a bug, alternatively it would be forced to copy all temporary
arguments even if it will be discarded at the end of expression.
Another problem is evaluation as same expression can be reused in
couple of places:

```
auto temp = a * b;
for (auto x : tab) x += temp;
```

Now we have by orders of magnitude more operations. If expressio can
decay to a regular matrix then we have only simple
addition in the loop like if we used plain floats.

>
> > Recent problem discussed on this mailing list with ref types
>
> It's not clear to me how decay is supposed to change that, especially without breaking code. This is just an unfortunate consequence of the design of std::minmax.

But if my `Tuple` have decay and if I would implement `minmax` using
it then original poster would not have this problem:

```
auto& [x, y] = std::minmax(foo, bar);
//x and y are members from `Tuple<Foo&, Bar&>&` pointing to `foo` and `bar`

auto [x, y] = std::minmax(foo, bar);
//x and y are value members from `Tuple<Foo, Bar>`
```

And I do not ask for changing `std::tuple` as this would be indead
breaking change,
This would be used in `std::minmax2` or `std2::` or your own classes.

>
> Cheers,
> Jeremy
>
>
> On Thu, Mar 20, 2025 at 10:16 AM Marcin Jaczewski via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> Right now the only type that undergoes decaying is C array (aside of
>> refs or bit fields).
>> Some consider this "bad feature" but for me this is more is "bad
>> implementation" of "good feature".
>>
>> I think that many user defined types could benefit from this functionality.
>>
>> Proxy objects:
>> ```
>> std::vector<bool> ff = { false, false };
>> for (auto b : ff)
>> {
>> b = true;
>> }
>> assert(ff[0] == true);
>> ```
>>
>> Expression templates:
>> ```
>> auto matrix = Matrix2x2{1, 2, 3, 4}
>> auto mul = matrix * Vector2{3, 4};
>> Vector2 v = mul + Vector2{1, 1}; //UB because `mul` is expression and
>> dangle temporal vector
>> ```
>>
>> Recent problem discussed on this mailing list with ref types:
>>
>> ```
>> auto [a, b] = std::minmax(foo, 10);
>> auto c = a; // UB if `a` refer to `10`
>> ```
>>
>> Another could be a safer version of C array that is not copyable like
>> `std::array`
>> and instead of decay to pointer, it will decay to `std::span`.
>>
>> And finally if someone desires to ban "Almost Always Auto" as it could
>> be useful for
>> very heavy types for unexpected copies in generic code (by setting `= delete`).
>>
>> ```
>> auto x = a; //error
>> auto& x = a; //ok, no decay
>> NestedVector x = a; //ok
>> auto x = NestedVector{ a }; //ok
>> ```
>>
>> Code that enable it would look like:
>>
>> ```
>> struct Foo
>> {
>> Bar operator auto()
>> {
>> return Bar{};
>> }
>> };
>>
>> struct auto_ptr //pre C++11 unique_ptr
>> {
>> //nothing change but in places where it could be used diagnostic is raised
>> [[obsolete]] auto_ptr operator auto() = default;
>> };
>>
>> struct MyArray
>> {
>> //ban decay from temp objects like return from functions.
>> std::span<int> operator auto() && = deleted;
>> std::span<int> operator auto();
>> };
>>
>> template<typename T1, typename T2>
>> struct MyTuple
>> {
>> T1 t1;
>> T2 t2;
>> //decay propagate to members, making ref tuple safer to use if
>> returned form `std::minmax`
>> MyTuple<std::decay_t<T1>, std::decay_t<T2>> operator auto() {
>> return { t1, t2 }; }
>> };
>> ```
>>
>> When a type has multiple `operator auto` then all versions need to
>> return the same type.
>> Additionally, the returned type need not have a decay operator (or its
>> `=default`).
>>
>> Overall this make `auto x =` generally more safe to use and more regular.
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals