Date: Fri, 3 Jan 2020 19:07:40 +0200
On Fri, 3 Jan 2020 at 18:28, Kyle Knoepfel via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Hi all,
>
> I know the following has been considered in the past, but I'm wondering if the considerations have changed in the last few years. To summarize, structured bindings allow all names to be introduced with the same qualification:
>
> std::map<unsigned int, std::string> employees = workers();
> for (auto const [id, last_name] : employees); // 1. id and last_name are both copies
id and last_name are names for members of a copied pair, they are not
copies in and of themselves.
> for (auto const& [id, last_name] : employees); // 2. id and last_name are both references
>
> The lesser of two evils would be to pick option 2 to avoid the string copy, even though using id as a reference is suboptimal.
I'm not sure what should be suboptimal about it. Surely an optimizer
can make things so that there are no extraneous
indirections here?
> I would love to be able to do something like:
>
> for (auto const [id, &last_name] : employees); // 3. id is a copy; last_name is a reference
>
> This syntax parallels that of lambda expressions, and would therefore not be "that new" of a construct to get used to. However, I know that this has been considered before in:
>
> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0144r1.pdf
>
> in section 3.5, and the preference is to disallow it for various reasons. Other proposals have been made that would enable more flexible use of structured bindings. See Ville's proposal:
>
> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0480r1.html
>
> It seems that the direction the committee is taking is to leave things be (keep it simple, for now) until pattern matching evolves a bit more. Does anyone know if that's still the case, or should an attempt be made again to make structured bindings more flexible a la what is/has been proposed above? Ville, do you have any comments?
I'm waiting and seeing what pattern matching gives me. Per-element
choice of whether to copy or not would be nice,
explicit typing would be nice, concept-constraints would be nice.
<std-proposals_at_[hidden]> wrote:
>
> Hi all,
>
> I know the following has been considered in the past, but I'm wondering if the considerations have changed in the last few years. To summarize, structured bindings allow all names to be introduced with the same qualification:
>
> std::map<unsigned int, std::string> employees = workers();
> for (auto const [id, last_name] : employees); // 1. id and last_name are both copies
id and last_name are names for members of a copied pair, they are not
copies in and of themselves.
> for (auto const& [id, last_name] : employees); // 2. id and last_name are both references
>
> The lesser of two evils would be to pick option 2 to avoid the string copy, even though using id as a reference is suboptimal.
I'm not sure what should be suboptimal about it. Surely an optimizer
can make things so that there are no extraneous
indirections here?
> I would love to be able to do something like:
>
> for (auto const [id, &last_name] : employees); // 3. id is a copy; last_name is a reference
>
> This syntax parallels that of lambda expressions, and would therefore not be "that new" of a construct to get used to. However, I know that this has been considered before in:
>
> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0144r1.pdf
>
> in section 3.5, and the preference is to disallow it for various reasons. Other proposals have been made that would enable more flexible use of structured bindings. See Ville's proposal:
>
> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0480r1.html
>
> It seems that the direction the committee is taking is to leave things be (keep it simple, for now) until pattern matching evolves a bit more. Does anyone know if that's still the case, or should an attempt be made again to make structured bindings more flexible a la what is/has been proposed above? Ville, do you have any comments?
I'm waiting and seeing what pattern matching gives me. Per-element
choice of whether to copy or not would be nice,
explicit typing would be nice, concept-constraints would be nice.
Received on 2020-01-03 11:10:22