(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).

> 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.

> 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).

> 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 P0144.

> David proposes a single operator extract to extract the elements of a
> product type.

That... sounds suspiciously like generalized unpacking? How would you
customize this without either the size / single element customizations,
or else first class multiple return values?

> I know that finding good names for them would be difficult.

In P0311, I "proposed" 'get' and 'sizeof' :-).

> 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.)

> 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 type.

This would be a good point to raise at Oulu when this discussion comes
up re: P0144.

--
Matthew

--
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 email 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/ncp7td%24mhr%241%40ger.gmane.org.

.

On 2016-03-21 16:49, Vicente J. Botet Escriba wrote:
> Le 21/03/2016 17:35, Matthew Woehlke a =C3=A9crit :
>> 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.

Yes; the above was meant as a rhetorical question in order to express
exactly that belief :-).

> We are in line.

Yes, I believe we are.

--=20
Matthew

--=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/ncpnpv%24vlq%241%40ger.gmane.org.

.