wt., 17 lis 2020 o 14:20 Arthur O'Dwyer via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> On Tue, Nov 17, 2020 at 5:45 AM Pilar Latiesa via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> [...]
>>
>> std::ranges::transform(std::views::zip(v, w, y), u.begin(), [](auto
>> &&Proxy) { auto [a, b, c] = Proxy; return a * b / std::sqrt(c); });
>>
>> The question is: would it be theoretically possible to add overloads
>> to the algorithms such that they accept n-ary callables for iterators
>> with tuple-like iter_reference_t, where n is
>> tuple_size<iter_reference_t>?
>>
>> std::ranges::transform(std::views::zip(v, w, y), u.begin(), [](auto a,
>> auto b, auto c) { return a * b / std::sqrt(c); });
>
>
> There has definitely been at least an informal proposal for structured bindings in function parameters, like this:
>
> std::ranges::transform(std::views::zip(v, w, y), u.begin(), [](auto [a,b,c]) { return a * b / std::sqrt(c); });
>
> This would be much easier to implement (as a core-language feature) than the library thing you're proposing.
> (Has this ever been a real proposal paper? What happened with it?)
>

This would be supported in normal function and will be SFINAE
friendly? Because then it could be very useful in other contexts too.

>> Are there cases in which adding such overloads would cause ambiguities?
>
>
> Obviously yes (because it's C++)... but also, pretty obviously via a constructive proof. You just need to find a function that's callable with both 1 argument and 2 arguments. Such as any variadic lambda.
>
> // https://godbolt.org/z/3o89do
> auto arity = [](auto... ts) { return sizeof...(ts); };
> std::map<int, int> m = {{1,2}, {3,4}};
> std::ranges::transform(m, std::ostream_iterator<int>(std::cout), arity); // "11" today, "22" tomorrow?
>
> And if you combined this with generic code it would get even weirder. "What do you mean, 'it automatically explodes the element type T if-and-only-if T is destructurable'? How do I iterate over the elements then?"
>
> –Arthur
>
> (Serendipitously, I was just talking about the badness of APIs that try to guess the user's meaning in the "vertical" direction; this one is trying to guess the user's meaning in the "horizontal" direction. For its "vertical" analogue, see recursive_count_if.)
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals