On Wednesday, November 30, 2016 at 5:41:18 PM UTC-= 5, Vicente J. Botet Escriba wrote:

Le 30/11/2016 =C3=A0 22:53, Matthew Woehlke a =C3=A9crit :
> On 2016-11-30 16:04, =CE=9D=CE=B9=CE=BA=CF=8C=CE=BB=CE=B1=CE=BF=CF= =82 =CE=91=CE=B8=CE=B1=CE=BD=CE=B1=CF=83=CE=AF=CE=BF=CF=85 wrote:
>> Just floating the idea before composing the complete text. I r= ecently *blogged
>> <https://ngat= hanasiou.wordpress.com/2016/11/28/want-a-std-slice/>*about= a
>> hypothetical tuple slice functionality (and related design con= siderations)
>> and it seems useful & simple enough (conceptually and impl= ementation wise)
>> to be added in isolation to the Standard library (it may just = have been
>> overlooked in previous versions, I couldn't find related p= roposals).
> If we had generalized slicing, would the proposed library function= offer
> anything superior to `std::make_tuple([I1:I2]product_type...)= `?
>
> (Generalized slicing would work both on *any* product type, as wel= l as
> on parameter packs, so in at least that sense, it is superior to a
> library function that operates only on std::tuple.)
>
I agree that new algorithms should work on ProductTypes [P0327R1]. It i= s=20
not yet clear =C2=A0to me how we would have the same syntax for Product= Types=20
and parameter packs. I'm not saying that I'm against, just that= we don't=20
have yet a clear proposal for this common access. While this could be= =20
user friendly, it doesn't compose well in generic code.

I believe it is worth defining algorithms that do whatever we want=20
independently of the precise implementation and the possible language= =20
evolution.

I'm considering defining some kind of ProductType views as we could= have=20
Range views. product_type::slice<I1,I2>(pt) could return a lazy= =20
product_type::slice_view<I1,I2, PT>. This should be more eff= icient,=20
needs to store a reference to the ProductType instead to a reference to= =20
each one of the elements of the product type. Sorry, but I don't ha= ve=20
neither a draft paper nor an implementation to show yet.

What do you think of this suggested product type views?

BTW, would slicing [I1,I2]pt... return a pack or a product type? Or a v= iew?

It is none of those:

* `pt` is an expressi= on that results in a "product type".

* `[:]pt` is a produc= t type pack, which is behaviorally identical to a parameter pack, save the = fact that it unpacks into a sequence of `get<i>(pt)` calls.

* = `[I1:I2]pt` is a product type pack that goes from `get<I1>` to `get&l= t;I2>`, rather than across the entire range of `pt`.

* `[I1:I2]pt= ....` unpacks the pack, which works exactly like unpacking a parameter pack.=