C++ Logo

STD-PROPOSALS

Advanced search

Subject: Re: [std-proposals] Request for opinion: Leaning on strong typing in STL.
From: Arthur O'Dwyer (arthur.j.odwyer_at_[hidden])
Date: 2020-07-22 19:20:36


On Wed, Jul 22, 2020 at 2:02 PM Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Wednesday, 22 July 2020 10:50:52 PDT Scott Michaud via Std-Proposals
> wrote:
> > Any thoughts on where else this could be used?
>
> Call the explicit vec.reserve() function instead. There's no ambiguity in
> what it does.
>
> I don't think we need more short-hands. Constructors should be reserved
> for
> the few needs where multiple lines would not do. Here's a litmus test:
> does it
> make sense to pass an object created with *just* that constructor to a
> function, either by value or by const-reference?
>
> func({1, 2, 3}); // certainly does
> func(reservation_t{12}); // ???
>

Presumably Scott's proposed `vector(reservation_t)` constructor would be
marked `explicit`, to turn off that implicit conversion. Implicit
conversions are the devil.

Scott: These blog posts of mine are relevant to your interests.
Essentially, I claim that you shouldn't want "create a vector with capacity
C" to be in the same overload set with any other constructor to begin with;
you ought to want it to be a named factory function.
https://quuxplusone.github.io/blog/2018/06/21/factory-vs-conversion/
https://quuxplusone.github.io/blog/2018/03/29/the-superconstructing-super-elider/

–Arthur



STD-PROPOSALS list run by herb.sutter at gmail.com

Standard Proposals Archives on Google Groups