Richard Biener <richard.guent...@gmail.com> writes: > On Wed, Jun 23, 2021 at 7:23 AM Trevor Saunders <tbsau...@tbsaunde.org> wrote: >> >> On Tue, Jun 22, 2021 at 02:01:24PM -0600, Martin Sebor wrote: >> > On 6/21/21 1:15 AM, Richard Biener wrote: > [...] >> > > >> > > But maybe I'm misunderstanding C++ too much :/ >> > > >> > > Well, I guess b) from above means auto_vec<> passing to >> > > vec<> taking functions will need changes? >> > >> > Converting an auto_vec object to a vec slices off its data members. >> > The auto_vec<T, 0> specialization has no data members so that's not >> > a bug in and of itself, but auto_vec<T, N> does have data members >> > so that would be a bug. The risk is not just passing it to >> > functions by value but also returning it. That risk was made >> > worse by the addition of the move ctor. >> >> I would agree that the conversion from auto_vec<> to vec<> is >> questionable, and should get some work at some point, perhaps just >> passingauto_vec references is good enough, or perhaps there is value in >> some const_vec view to avoid having to rely on optimizations, I'm not >> sure without looking more at the usage. > > We do need to be able to provide APIs that work with both auto_vec<> > and vec<>, I agree that those currently taking a vec<> by value are > fragile (and we've had bugs there before), but I'm not ready to say > that changing them all to [const] vec<>& is OK. The alternative > would be passing a const_vec<> by value, passing that along to > const vec<>& APIs should be valid then (I can see quite some API > boundary cleanups being necessary here ...).
FWIW, as far as const_vec<> goes, we already have array_slice, which is mostly a version of std::span. (The only real reason for not using std::span itself is that it requires a later version of C++.) Taking those as arguments has the advantage that we can pass normal arrays as well. Thanks, Richard
