Le 21/03/2016 17:35, Matthew Woehlke a =C3=A9crit :
> (Vicente, some of this will likely repeat statements made privately;
> apologies for the repetition. This reply is, naturally, for the benefit
> of the group as a whole.)
>
> On 2016-03-20 19:35, Vicente J. Botet Escriba wrote:
>> I agree that P0144 and P0197 are related and that considering the big
>> picture will help. However I don't think P0197 is ready to be adopted.
> It's not going to be in C++17. That ship, unfortunately, sailed at
> Jacksonville. While I would have loved to see it in C++17, I don't think
> it's the end of the world.
>
> What I *don't* want to see is P0144 adopted in a way that is
> incompatible with eventually adopting P0197, i.e. that leaves us stuck
> with P0144 Case 3 forever (sans a breaking change).
What we need is to define what is a product-type. P0144 should just use=20
the interface of a product type. P0197 could if adopted, generate=20
default implementations for those operators.
>
>> Tony has raised on another thread that making a core language feature
>> depend on a library is something that must be avoided. P0144 doesn't
>> depends on a library until we decide to use tuple_size to check the size
>> of the tuples match.
> This isn't necessarily true; Case 2 currently depends on `get<N>`. Now,
> that point was briefly raised at Jacksonville, and is the reason for the
> "Access" section in P0311.
get<N>(t) is not a dependency on any library as is not begin(r). Those=20
are found by ADL.
>
>> So, I'm planning to provide a revision of P0197 (or an additional paper)
>> that will take in account the possibility that the product type access
>> interface is not determined by the know get<I> function and the trait
>> tuple_size<T> trait, but from some specific operators.
> Yes, I think that's the way to go. I don't see a real problem here;
> either EWG will decide that `get<N>` is okay, or they will decide on
> something else. Either way, it makes sense that P0197 would use the same
> mechanism, so I don't see this issue as a barrier to adopting P0197
> (unless it gets dropped entirely from P0144, but I really hope that
> won't happen).
Both must use the same. The problem is not in get<I>, It is on=20
tuple_size and the specialization for c-arrays.
>
>> The adoption of P0144 should be independent of P0197 in particular
> Depending on your definition of "independent", I either agree strongly
> or disagree strongly. I agree that P0197 should not "hold up" P0144, but
> I also want P0144 adopted in a way that will a) allow P0197 to be
> adopoted later, and b) result in such adoption eliminating Case 3 of P014=
4.
We need to adapt P0144 to whatever make it independent of the library.
>
>> David proposes a single operator extract to extract the elements of a
>> product type.
> That... sounds suspiciously like generalized unpacking?
the `operator extract` doesn't do an extraction, but it is more a=20
mapping. between the CT index and the address of the member.
> How would you
> customize this without either the size / single element customizations,
> or else first class multiple return values?
This is why I believe that we need two operators.
>
>> I know that finding good names for them would be difficult.
> In P0311, I "proposed" 'get' and 'sizeof' :-).
I missed this in your paper :(. We are in line.
>
>> Structured Binding ([P0144R1]) and pattern matching [1] should be
>> based on the same operators. The user should be able to define those
>> operators for his own types and the language should provide
>> convenient default for them.
> Yes, this is *exactly* the point that P0311 tries to convey :-). (Also,
> that generalized unpacking belongs in that list too.)
I will re-read it more carefully.
>
>> In addition a c-array must be seen as a product-type, but we are unable
>> to define the get<I> function on them. However if `operator
>> product_type_size` and `operator product_type_nth_element` are operators
>> we could define its meaning on the language for this builtin product typ=
e.
> This would be a good point to raise at Oulu when this discussion comes
> up re: P0144.
>
Vicente

--=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/56F05E54.9000708%40wanadoo.fr.

.