czw., 20 mar 2025 o 19:43 Ivan Lazaric via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> This sounds similar to http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0672r0.pdf
>

Ok, I did recall discussion on this topic, but not this exact proposal.
New sytynax is the same but the semantics are a bit different.
Reading link that Sebastian Wittmeier provides looks a bit more close
to Arthur suggested improvements.

My idea is simple, this new decay happens in exactly the same contexts
as the decay of `int[]`,
but the user defines what the final type is. Similar to normal user
defined but implicit.

Overall `auto` here is only for naming new operator, decay is not
linked to `auto` itself as code like:

```
template<typename T>
void foo(T t)
{

}
```

would trigger decay conversion. I would inject itself into the current
language right after Array-to-pointer conversion.


>
> On Thu, Mar 20, 2025, 17:49 Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> Would this be a language or a library change?
>>
>>
>>
>> With user defined decay, you mean conversion operators defined in the class?
>>
>> And new ones should be added for specific standard library types?
>>
>>
>>
>> Or do you mean an automatic decay / conversion, even if not specified in the class?
>>
>>
>>
>> Or is it specifically about rules, if type deduction is done with auto or for templates?
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Marcin Jaczewski via Std-Proposals <std-proposals_at_[hidden]>
>> Gesendet: Do 20.03.2025 17:16
>> Betreff: [std-proposals] User defined decay operator
>> An: std-proposals <std-proposals_at_[hidden]>;
>> CC: Marcin Jaczewski <marcinjaczewski86_at_[hidden]>;
>> 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
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals