Le 20/12/2016 =C3=A0 16:58, Matthew Woehlke a =C3=A9crit :
> On 2016-12-19 19:16, Vicente J. Botet Escriba wrote:
>> I'm not against redefining sizeof for product types, but it will be
>> worth mentioning the syntax is possible sizeof([:]t...) without the
>> redefinition.
> Pretty sure you meant `sizeof...([:]t)`, but yeah, it's a fair point. My
Right.
> main argument for having `sizeof...(t)` for product type `t` is for
> symmetry with prefix `[]` working on either packs or product types. If
> folks don't find the consistency argument compelling, I have no problem
> dropping that part of the proposal.
If you consider [:] as a way to convert a product type to a parameter=20
pack, slicing could become an additional operation.
>> The <double, double> returned in
>>
>>      <double, double> calculateTargetCoordinates();
>>
>> is not a parameter pack but a pack type as defined in P0341. This is of
>> course something new.
> ...but the expression `calculateTargetCoordinates()` results in a
> parameter pack, does it not? That, anyway, is how I read P0341...
> (Admittedly, I find P0341... vague and sometimes confusing.)
I agree that the paper could be vague, but I know the intention is to be=20
a type not a pack.
>
>> Pack types as defined in P0341 should accept this slice operator (we
>> shoild consider Pack types as product types). I'm not sure we will need
>> that Pack types provide directly the expansion operator....
> I hope that this will obviate much of P0341 :-). As I've said in various
> places, while the features of P0341 are useful, I don't feel that the
> approach in P0341 is desirable; it invents way too much IMHO in the way
> of new syntax, new language constructs, etc..
One of the major things P0341 proposes IMO is a type for aggregate=20
initializes. <T, U> is the type for the expression { t, u }. This is=20
something we are missing now.
The other is the ability to use packs in other locations, to help define=20
a simple_tuple type.
I don't think there is to much syntax changes in P0341
>
>> Have you considered strides [start:stop:step]? reverted slices
>> [start:stop:-1]?
> I hadn't specifically, but I'll refer you to "Future Direction". My
> general impression has been that the more complicated the feature
> becomes, the more people are inclined to dislike it. I think pack
> generators or other such approaches would be a better solution for this
> sort of thing.
Maybe you are right, but exploring the global problem is worth the effort.
It is not clear to me yet what pack generators are. I'll re-read the=20
paper but a clarification here is welcome.
>
>> The main difference between the proposed slice operator and python
>> slices is that the result is not a type, but a parameter pack, that can
>> not be on the LHS of an assignment. Have you considered this possibility=
?
> Doesn't std::tie solve that?
>
Yes, std::tie will work. If what we want is

     [1,3]pp =3D {a,b},

with tie, we need

     tie(([1,3]pp)...) =3D {a,b};

Do we need to improve the syntactic sugar of each construction?

With [:] and std::slice<I,J,K>(ts..) we can replace

     [I, J]pp // your proposed slice

with

     [:]slice<I,,J>(pp...) // your proposed product type to parameter=20
pack + a library function returning a product type view

It is more verbose but it is extensible without changing the language=20
too much, we need only a product type to parameter pack conversion

     tie((slice<1,3>(pp...)) =3D {a,b};

Do we really need [I, J]p when we could have a more verbose library=20
solution? Possibly if this could improve the compiler performances. I=20
believe that proposal should provide more examples where slicing helps=20
the user to define functions that the compiler could improve the compile=20
time performances.

What I'm saying is that we need to see what are the minimal operations=20
we need and what are the syntactic sugar ones.

I believe that we need:

     * a way to transform a product type into a parameter pack and

         [:]pt -> pp // your proposal

     * transform a parameter pack into a product type.
         <pp...> -> pt  // P0341

While I would like to have a direct product type expansion, I don't see=20
how P0341 UDT expansion works together with parameter pack expansions

         pt... // UDT product type expansion P0341

Then see what are the operations we need on parameter packs and product=20
types.

If we introduce a slice construct in the language for parameter packs,=20
why it cannot be on the lhs of a expression? This is why I was=20
considering that slicing should return a type and not a parameter pack

Do we need a language slicing construct for product types? Should=20
slicing on a product type result on a parameter pack or a product type view=
?

Selection of the nth element of a parameter pack and a product type
     [N]pp
versus
     nth<N>(pp...)

     [N]pt
versus
     product_type::get<N>(pt)

IMO, the proposal should show the language and the library solutions.

Vicente

P.S. pt stands for product type and pp for parameter pack

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1cc4a47c-d26f-4f6f-762a-c2f5a9da74a1%40wanadoo.f=
r.

.