>. You *really* should read Daveed's paper :-). I have some reservations as
far as implementation complexity (which, in the interest of full
disclosure, he doesn't share); other than that, it's *really* cool.

(assuming we are taking about the same Daveed, there only one right?) Davee=
d is typically =E2=80=8Epretty conservative about implementation complexity=
.. If he's not worried, I'm not worried.=C2=A0

=C2=A0

Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi=
ce
=C2=A0 Original Message =C2=A0
From: Matthew Woehlke
Sent: Sunday, March 20, 2016 1:44 PM
To: std-proposals@isocpp.org
Reply To: std-proposals@isocpp.org
Subject: [std-proposals] Re: [RFC] Call for considering "the big picture" r=
e: tuples and parameter packs

On 2016-03-20 04:21, Daniel Frey wrote:
> On 19.03.2016, at 20:15, Matthew Woehlke wrote:
>> On 2016-03-19 06:53, Daniel Frey wrote:
>>> On 18.03.2016, at 16:51, Matthew Woehlke wrote:
>>>> [paper]
>>
>> I'm going to try to keep this brief as it is turning into a discussion
>> on your proposal vs. mine, which really isn't the topic. (Parameter pack
>> stuff in general is really only partly on topic; the main topic should
>> be P0197.)
>=20
> In a way, it is the topic. We are both trying to solve problem in a=20
> similar domain, coming from different directions and with different=20
> ideas about how to solve those problems.

Well... okay, yes :-). I do go into this direction, and it is a topic
that I think needs to be resolved. Eventually. The reason I urgently
wanted the paper in the next mailing however is for the sake of P0197,
P0144 and their respective interactions. The issues around parameter
packs are meant (in the context of D0311) more to serve as an
illustration of where we are (probably) headed and why it's important to
considering these interactions, especially where they touch on P0144 and
therefore are of urgent import, as P0144 may yet go into C++17. (I tend
to hope that it does, though if it doesn't, we'll have more chance to
"get it right" with respect to the larger issues.)

> I appreciate these discussions as they are forcing both of us to look
> further, do more. This is a constructive way of making progress and
> by that, I do see value in discussing your proposal vs. mine.

Indeed. You may notice in the latest draft (which includes the
acknowledgments section) that I credited you for exactly this :-).

For the record, I'll reiterate here: thank *you* for making *me* defend
my position more seriously :-).

> It might end with both of us (and others) joining forces into a
> single proposal

That would be awesome :-).

p.s. You might want to ask Daveed if he'll share his pack generation
paper; it might give you a different perspective on some of your ideas.

> I can agree to that, I am about to add an "operator..." to unpack
> tuple(-like) classes to my proposal.

Hmm... I'll try to reserve judgment until I see an example, but my
offhand reaction is that unpacking and fold expansion need to have
different syntax.

>>> * I don't see slices as the only thing we want
>>> - We also want arbitrary lists of indices (2, 4, 7, 12, 3)
>>> - We also want reversed slices/ranges
>>
>> Agreed. Pack generation will be able to do these, though. My feeling is
>> that they are obscure enough that extra syntax (i.e. "library" solution)
>> is okay. In that respect, your proposal and Daveed's are equally simple,
>> but Daveed's can do a lot that your proposal can't.
>=20
> The syntax I've chosen allows for more ways to generate sequences to be a=
dded, as the left-hand side (int... Is) is an anchor, so the possible expre=
ssions on the right-hand side (...4) can be extended by further options wit=
hout interaction with the rest of the language. Example:
>=20
> int... Is =3D 2*(...4)+1; // allow an expression with exactly one generat=
ed sequence
>=20
> I am currently not proposing anything specific in this area, as I'm not s=
ure how important this use-case is. If others feel it should be addressed, =
I'll think of something.

You *really* should read Daveed's paper :-). I have some reservations as
far as implementation complexity (which, in the interest of full
disclosure, he doesn't share); other than that, it's *really* cool.

>>> - We want slices of different types (std::size_t, int, enum?, ...)
>>
>> Do you mean as indices? These should Just Work with syntactic slicing,
>> and making them work with library slicing isn't hard.
>=20
> "slices" wasn't the best word in the above sentence I wrote. Maybe
> "sequences" would be a better fit. The point is: We currently have
> (via deduction) sequences of different integral types. If we have
> sequence generators, we should also be able to control the type.
> [2:5] would generate a sequence of what? std::size_t?

It would generate the parameter pack `[2]__t, [3]__t, [4]__t`. The type
of the indices is not greatly important, since it gets immediately
stuffed into the single-value indexing operator. (Note also that
`[N]__t` isn't fully expanded either; it would actually be `get<N>(__t)`
or whatever we decide we like for tuple-like indexed access.)

> Then how do you generate a sequence of int...?

Using something other than my proposal :-). The scope I am addressing is
more narrow than the scope you are addressing, which is more narrow than
the scope Daveed is addressing. I'm pretty sure I said this elsewhere,
but my approach is to focus on the easy/common cases and also provide
the function (indexed access into parameter packs) that seems to be a
prerequisite for any of the more advanced approaches. It would help if
you don't view your proposal as directly competing with mine; parts of
it would be rather an addition. My main "complaint" against your
proposal in that respect is that I don't see it solving anything that
Daveed's proposal doesn't.

>>> * Extracting a single element from a tuple(-like) object already has a =
syntax: std::get<I>(t)
>>
>> There was discussion at Jacksonville if that's really the syntax we
>> want. Compile-time indexing would offer an obvious alternative (as
>> presented in the section "An operator-like alternative"). More to the
>> point, though, it seems silly for slicing to operate on both tuple-likes
>> and parameter packs but to restrict single-value extraction to the
>> latter. IOW, there is no syntactic cost and there is a benefit in
>> consistency.
>=20
> I think you are mixing two different things which should (or even need to=
) be distinguished properly:
>=20
> * Slicing (or other forms of multi-index access) generates another pack (=
or parameter list)
> * Single elements are not packs
>=20
> This is a very important difference. I don't want consistency here,
> I want to explicitly know which case I am working with. A pack of
> size 1 is still a pack that needs to be expanded, the other is simply
> a single type or a value (or a single expression).

Isn't this a point I was making in an earlier message?

This is a pack: `[4:5]p;`

This is a single element: `[4]p`
This is the same as the previous example: `([4:5]p...)`

The "clear" (okay, we can argue on just *how* clear) differentiation
point is that a single index always gives you a value=C2=B9, whereas the on=
ly
way you get a pack is if there is a `:` in the index-expression;
conversely, you *always* get a pack if there is a `:`, even if the pack
has only one element.

(=C2=B9 *If* we allow packs as indices, the effect would be the same as
`foo[pack]...`, i.e. the indexing expression is "outside" pack
expansion, the same as a call to `bar` is "outside" pack expansion in
e.g. `0 + ... + bar(pack)`.)

Yes, I am lumping those into one syntax (prefix `[]`). I am doing so
because they both are in the "compile time indexing" basket, because we
*need* parameter pack indexing (and I don't see undecorated postfix `[]`
as a feasible solution for that), because I feel very strongly that we
need a short syntax for the common tuple-like unpacking case, and
because the grammar cost of combining these is lower versus having two
different new syntaxes.

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

--=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/20160320183535.4894800.83455.8472%40gmail.com.

.

Le 20/03/2016 18:44, Matthew Woehlke a =C3=A9crit :
> On 2016-03-20 04:21, Daniel Frey wrote:
>> On 19.03.2016, at 20:15, Matthew Woehlke wrote:
>>> On 2016-03-19 06:53, Daniel Frey wrote:
>>>> On 18.03.2016, at 16:51, Matthew Woehlke wrote:
>>>>> [paper]
>>> I'm going to try to keep this brief as it is turning into a discussion
>>> on your proposal vs. mine, which really isn't the topic. (Parameter pac=
k
>>> stuff in general is really only partly on topic; the main topic should
>>> be P0197.)
>> In a way, it is the topic. We are both trying to solve problem in a
>> similar domain, coming from different directions and with different
>> ideas about how to solve those problems.
> Well... okay, yes :-). I do go into this direction, and it is a topic
> that I think needs to be resolved. Eventually. The reason I urgently
> wanted the paper in the next mailing however is for the sake of P0197,
> P0144 and their respective interactions.

I agree that P0144 and P0197 are related and that considering the big=20
picture will help. However I don't think P0197 is ready to be adopted.
Tony has raised on another thread that making a core language feature=20
depend on a library is something that must be avoided. P0144 doesn't=20
depends on a library until we decide to use tuple_size to check the size=20
of the tuples match. P0197 depend completely on the library and this=20
could be a showstopper to his adoption.
The adoption of P0144 should be independent of P0197 in particular, but=20
we should consider the path to the big picture with pattern matching. I=20
believe that the authors of P0144 know already how this should be done.

Davis Sankel has been working on a pattern matching feature for sum=20
types and product types [1] . This is not a concrete proposal yet but=20
give an idea of how to integrate both kind of types in the language.=20
David proposes to add some builtin operators that are used while doing=20
pattern matching.

I believe that we need to define the concept of product/sum type in the=20
language because we want to provide features at the language level for=20
those types.
* structured binding
* pattern matching
* direct access to the parts

So, I'm planning to provide a revision of P0197 (or an additional paper)=20
that will take in account the possibility that the product type access=20
interface is not determined by the know get<I> function and the trait=20
tuple_size<T> trait, but from some specific operators.

David proposes a single operator extract to extract the elements of a=20
product type. This is good when we want to extract all the members, but=20
not when we want one member., so I believe that we need 2 operators: one=20
to get the size and one to get the n<sup>th</sup> element. The=20
name/syntax of these operators needs to be defined, however, until that=20
I will name them `operator product_type_size` and `operator=20
product_type_nth_element`. I know that finding good names for them would=20
be difficult.

Structured Binding ([P0144R1]) and pattern matching [1] should be based=20
on the same operators.
The user should be able to define those operators for his own types and=20
the language should provide convenient default for them.

To be compatible with the existing tuple-like types, I would propose to=20
update the definition of `tuple_size`, `tuple_element` and=20
`get<I>/get<T>` for product-types, and add the customization for those=20
operators for the standard tuple-like types `std::tuple`, `std::pair`=20
and `std::array`.

In addition a c-array must be seen as a product-type, but we are unable=20
to define the get<I> function on them. However if `operator=20
product_type_size` and `operator product_type_nth_element` are operators=20
we could define its meaning on the language for this builtin product type.

If we had the good names/syntax for those operators, P0144 could be=20
adapted to them and be included in C++17. We could add PM and default=20
product-type access for aggregates and so later on.

What do you think of this path?

Vicente

[1]http://davidsankel.com/uncategorized/c-language-support-for-pattern-matc=
hing-and-variants/


P.S. Sorry I'm not considering at all the other part of P0301=20
(unpacking) and I consider that those are orthogonal features.

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

.

Could the member access syntax actually be s[N] for some struct or class s?

ie just extend operator[] to allow the return type to be different for diff=
erent constexpr inputs.=C2=A0

Then arrays (and vectors, etc) 'just work'. This assumes you never want to =
access the actual members of vector (ie v._ptr and v._size or whatever the =
vector implementation uses). I think it is safe to assume that any class th=
at overrides operator[] wants to be array-like and doesn't want its members=
 exposed as a tuple.=C2=A0

?

Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi=
ce
=C2=A0 Original Message =C2=A0
From: Vicente J. Botet Escriba
Sent: Sunday, March 20, 2016 7:35 PM
To: std-proposals@isocpp.org
Reply To: std-proposals@isocpp.org
Subject: Re: [std-proposals] Re: [RFC] Call for considering "the big pictur=
e" re: tuples and parameter packs

Le 20/03/2016 18:44, Matthew Woehlke a =C3=A9crit :
> On 2016-03-20 04:21, Daniel Frey wrote:
>> On 19.03.2016, at 20:15, Matthew Woehlke wrote:
>>> On 2016-03-19 06:53, Daniel Frey wrote:
>>>> On 18.03.2016, at 16:51, Matthew Woehlke wrote:
>>>>> [paper]
>>> I'm going to try to keep this brief as it is turning into a discussion
>>> on your proposal vs. mine, which really isn't the topic. (Parameter pac=
k
>>> stuff in general is really only partly on topic; the main topic should
>>> be P0197.)
>> In a way, it is the topic. We are both trying to solve problem in a
>> similar domain, coming from different directions and with different
>> ideas about how to solve those problems.
> Well... okay, yes :-). I do go into this direction, and it is a topic
> that I think needs to be resolved. Eventually. The reason I urgently
> wanted the paper in the next mailing however is for the sake of P0197,
> P0144 and their respective interactions.

I agree that P0144 and P0197 are related and that considering the big=20
picture will help. However I don't think P0197 is ready to be adopted.
Tony has raised on another thread that making a core language feature=20
depend on a library is something that must be avoided. P0144 doesn't=20
depends on a library until we decide to use tuple_size to check the size=20
of the tuples match. P0197 depend completely on the library and this=20
could be a showstopper to his adoption.
The adoption of P0144 should be independent of P0197 in particular, but=20
we should consider the path to the big picture with pattern matching. I=20
believe that the authors of P0144 know already how this should be done.

Davis Sankel has been working on a pattern matching feature for sum=20
types and product types [1] . This is not a concrete proposal yet but=20
give an idea of how to integrate both kind of types in the language.=20
David proposes to add some builtin operators that are used while doing=20
pattern matching.

I believe that we need to define the concept of product/sum type in the=20
language because we want to provide features at the language level for=20
those types.
* structured binding
* pattern matching
* direct access to the parts

So, I'm planning to provide a revision of P0197 (or an additional paper)=20
that will take in account the possibility that the product type access=20
interface is not determined by the know get<I> function and the trait=20
tuple_size<T> trait, but from some specific operators.

David proposes a single operator extract to extract the elements of a=20
product type. This is good when we want to extract all the members, but=20
not when we want one member., so I believe that we need 2 operators: one=20
to get the size and one to get the n<sup>th</sup> element. The=20
name/syntax of these operators needs to be defined, however, until that=20
I will name them `operator product_type_size` and `operator=20
product_type_nth_element`. I know that finding good names for them would=20
be difficult.

Structured Binding ([P0144R1]) and pattern matching [1] should be based=20
on the same operators.
The user should be able to define those operators for his own types and=20
the language should provide convenient default for them.

To be compatible with the existing tuple-like types, I would propose to=20
update the definition of `tuple_size`, `tuple_element` and=20
`get<I>/get<T>` for product-types, and add the customization for those=20
operators for the standard tuple-like types `std::tuple`, `std::pair`=20
and `std::array`.

In addition a c-array must be seen as a product-type, but we are unable=20
to define the get<I> function on them. However if `operator=20
product_type_size` and `operator product_type_nth_element` are operators=20
we could define its meaning on the language for this builtin product type.

If we had the good names/syntax for those operators, P0144 could be=20
adapted to them and be included in C++17. We could add PM and default=20
product-type access for aggregates and so later on.

What do you think of this path?

Vicente

[1]http://davidsankel.com/uncategorized/c-language-support-for-pattern-matc=
hing-and-variants/


P.S. Sorry I'm not considering at all the other part of P0301=20
(unpacking) and I consider that those are orthogonal features.

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

--=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/20160321032111.4898897.41547.8488%40gmail.com.

.

--Apple-Mail=_592E0FE3-D687-4625-ADCD-F45271F78D17
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

> On 21.03.2016, at 18:16, barry.revzin@gmail.com wrote:
>=20
> On Monday, March 21, 2016 at 11:53:52 AM UTC-5, Matthew Woehlke wrote:
>> On 2016-03-20 23:21, Tony V E wrote:
>> > Could the member access syntax actually be s[N] for some struct or cla=
ss s?
>> >
>> > ie just extend operator[] to allow the return type to be different for=
 different constexpr inputs.
>>=20
>> I think that way lies madness... too easy to confuse CTI=C2=B9 with RTI=
=C2=B2.
>> Using a separate syntax makes it clear which is happening, and doesn't
>> run into overload resolution problems for e.g. std::array that needs
>> both. Also...
>>=20
>> (=C2=B9 Compile-Time Indexing)
>> (=C2=B2 Run-Time Indexing, obviously)
>>=20
> Madness? This is C++!

:)

> Anyway, we basically have three categories: tuple (CTI only ever), vector=
 (RTI only ever), and array (both - which do the same thing really, except =
CTI gives some nice safety mechanisms).  We have std::get<I> for CTI, but t=
hat's because it was created as a library to support tuple, right? Is there=
 a conceptual reason why we wouldn't want tuple[0] to work and do something=
 like call tuple.operator[](integral_constant<size_t, 0> ) (or std::get<0>(=
tuple) or something else along these lines)?

I already said earlier that I think s[N] is the right syntax.

The question to me is how to achieve this. Overloading on constexpr paramet=
ers might be one option, templated constructors might be another solution -=
 or just the solution for allowing overloading. IIUC, it was already propos=
ed. If you consider integral_constant to have a ctor that is able to deduce=
 size_t and 0 from the argument (0), you already have everything you need (=
even int and 0 is OK). It also automatically ensures that the argument is a=
 constant.

I fail to see why "confusing" CTI and RTI is a problem. If you misuse overl=
oading or basically any other feature you will get confusing syntax or sema=
ntics. But that doesn't mean that it's bad if used for the right use-cases =
and to me, this is one of the obvious use-cases. Provide access to a tuple'=
s elements via tuple::operator[].

-- Daniel

--=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/C98AB9FE-13A6-433D-BCDC-B67C6DD9787D%40gmx.de.

--Apple-Mail=_592E0FE3-D687-4625-ADCD-F45271F78D17
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename=signature.asc
Content-Type: application/pgp-signature;
 name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iEYEARECAAYFAlbwMQcACgkQAUxJbew56yFPIgCbBa5DJEGS6ysBEjE3s3yZ9G2a
ze4AoI4/mOXcJLAOGELNV9UKeOnLtT+w
=2/4s
-----END PGP SIGNATURE-----

--Apple-Mail=_592E0FE3-D687-4625-ADCD-F45271F78D17--

.

--Apple-Mail=_949FD513-A133-4CD7-A3E5-415E7A26DC2E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

> On 21.03.2016, at 18:56, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote=
:
>=20
> On 2016-03-21 13:36, Daniel Frey wrote:
>> I fail to see why "confusing" CTI and RTI is a problem. If you misuse
>> overloading or basically any other feature you will get confusing
>> syntax or semantics. But that doesn't mean that it's bad if used for
>> the right use-cases and to me, this is one of the obvious use-cases.
>> Provide access to a tuple's elements via tuple::operator[].
>=20
> Given a hypothetical (*RTI*) `std::any std::tuple::operator[]`:

Are you misreading what I said? tuple::operator[] is CTI only, there is no =
confusion with RTI because tuple::operator[] is not a use-case for overload=
ing both. Of course that would be bad. I'm talking about adding CTI operato=
r[] to tuple only. Only if a use-case has "obvious", non-confusing semantic=
s, one would overload both. For example when it allows additional checks at=
 compile-time, e.g., for std::array. CTI operator[] would check the bound a=
t compile-time, RTI operator[] can only check (and throw) at run-time. Othe=
r examples might provide optimized versions or a CTI version which is const=
expr, hence the result is usable as a compile-time constant which the RTI v=
ersion might have a different implementation which is simply faster if actu=
ally executed on the CPU.

>  auto t =3D std::tuple<int, float>{};
>  auto x =3D tuple[foo()];

I assume the second line is "auto x =3D t[foo()];". Anyways, if t is a tupl=
e, foo() *must* return a constexpr. Also, with std::get<foo()>(t) you still=
 wouldn't know if the result is int or float. Nothing about that is bad, on=
ly mixing RTI into it is.

> ...what is decltype(x)? int/float? std::any? I need to inspect `foo()`
> to try to determine if the value is constexpr or not.
>=20
> Even worse:
>=20
>  constexpr inline auto foo(auto tuple, int x)
>  {
>    return tuple[x];
>  }
>=20
>  foo(t, 0); // CTI? RTI?
>  foo(t, opaque()); // RTI

You are simply making up a very bad example or mixing CTI/RTI. Again, tuple=
 should not have RTI operator[].

> On 2016-03-21 13:46, Daniel Frey wrote:
>> No one would want to return `std::any`.
>=20
> How do you know? (Note I'm talking about *RTI* here... the return value
> *cannot* depend on the index, and so you *must* use something like
> std::any. The question is if you would want RTI, and I assert you can't
> just declare that "no one ever will", especially not for all user types.)

Ok, *I* don't want to return std::any for tuple::operator[], I am not sugge=
sting/proposing adding an RTI tuple::operator[] and therefore you shouldn't=
 hold it as an argument against me. If you'd overload tuple::operator[] for=
 CTI and RTI, that's your problem, not mine :)

-- Daniel

--=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/18A7F6A4-7A7F-47A6-A7FE-401C9CC5306B%40gmx.de.

--Apple-Mail=_949FD513-A133-4CD7-A3E5-415E7A26DC2E
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename=signature.asc
Content-Type: application/pgp-signature;
 name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iEYEARECAAYFAlbwO1sACgkQAUxJbew56yFNZQCfZ0pWOVb3iPWWPckP6G+YpVms
qIEAn3OusK8wnewVkSNvLPtKPJI7NrOT
=RUNk
-----END PGP SIGNATURE-----

--Apple-Mail=_949FD513-A133-4CD7-A3E5-415E7A26DC2E--

.

Le 21/03/2016 04:21, Tony V E a =C3=A9crit :
> Could the member access syntax actually be s[N] for some struct or class =
s?
>
> ie just extend operator[] to allow the return type to be different for di=
fferent constexpr inputs.
>
> Then arrays (and vectors, etc) 'just work'. This assumes you never want t=
o access the actual members of vector (ie v._ptr and v._size or whatever th=
e vector implementation uses). I think it is safe to assume that any class =
that overrides operator[] wants to be array-like and doesn't want its membe=
rs exposed as a tuple.
>
> ?
Maybe. But the function the problem is not in get<I>(t). it is in=20
tuple_size<T>::value, and is the size operator that need to be defined.


Having the names of the operator is important, but I believe that we=20
need to confirm or not that we have to define them as operators or not=20
to avoid the library dependency.

Vicente


P.S.

Boost.Hana make use already of the operator[] on heterogeneous=20
sequences. With user defined literal we could have

// Access tuple elements with operator[] instead of std::get.
Cat garfield =3D animals[1_c];

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

.

Le 21/03/2016 21:08, Jim Porter a =C3=A9crit :
>
> However, I'm assuming that the real reason you'd want CTI for=20
> std::array is to get compile-time *bounds checking*. As I'm sure you=20
> know, this isn't possible today with function parameter (hence why=20
> std::get uses a non-type template parameter instead), hence why your=20
> proposal contains the following syntax:
>
>     operator get(auto& tuple, constexpr size_t i);
>
> Note especially the `constexpr`. Your paper doesn't elaborate on the=20
> semantics of applying constexpr to a function parameter (and I didn't=20
> see it earlier in the thread, but I may have just missed it), so I'll=20
> assume that it means "this argument *must* be constexpr". Then you'd=20
> just do the same thing std::get does, and presto, compile-time bounds=20
> checking!
>
> Of course, this feature would be useful for other things than CTI, so=20
> I would expect it to be usable by any function (e.g. a printf clone?).=20
> With such a feature it's possible, though not necessarily recommended,=20
> to implement CTI using the current operator[].
>
> Leading from this, one question is: should it be possible to overload=20
> a function based on the constexpr-ness of its parameters? If no, then=20
> you'd need different syntaxes for CTI and RTI. If yes, there's no=20
> technical need for prefix-[], and I'd just as soon avoid adding it.
Not with the current standard. We can not qualify a parameter with=20
constexpr. Well, I believe that there was no adopted proposal for that yet.

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/56F0668F.40105%40wanadoo.fr.

.

Le 21/03/2016 04:21, Tony V E a =C3=A9crit :
> Could the member access syntax actually be s[N] for some struct or class =
s?
>
> ie just extend operator[] to allow the return type to be different for di=
fferent constexpr inputs.
>
> Then arrays (and vectors, etc) 'just work'. This assumes you never want t=
o access the actual members of vector (ie v._ptr and v._size or whatever th=
e vector implementation uses). I think it is safe to assume that any class =
that overrides operator[] wants to be array-like and doesn't want its membe=
rs exposed as a tuple.
>
> ?

Nobody has proposed yet the field syntax s.N.

This will allow to have a constexpr index access a.N  and a runtime one=20
a[n] for std::array.

Vicente
> Sent from my BlackBerry portable Babbage Device
>    Original Message
> From: Vicente J. Botet Escriba
> Sent: Sunday, March 20, 2016 7:35 PM
> To: std-proposals@isocpp.org
> Reply To: std-proposals@isocpp.org
> Subject: Re: [std-proposals] Re: [RFC] Call for considering "the big pict=
ure" re: tuples and parameter packs
>
> Le 20/03/2016 18:44, Matthew Woehlke a =C3=A9crit :
>> On 2016-03-20 04:21, Daniel Frey wrote:
>>> On 19.03.2016, at 20:15, Matthew Woehlke wrote:
>>>> On 2016-03-19 06:53, Daniel Frey wrote:
>>>>> On 18.03.2016, at 16:51, Matthew Woehlke wrote:
>>>>>> [paper]
>>>> I'm going to try to keep this brief as it is turning into a discussion
>>>> on your proposal vs. mine, which really isn't the topic. (Parameter pa=
ck
>>>> stuff in general is really only partly on topic; the main topic should
>>>> be P0197.)
>>> In a way, it is the topic. We are both trying to solve problem in a
>>> similar domain, coming from different directions and with different
>>> ideas about how to solve those problems.
>> Well... okay, yes :-). I do go into this direction, and it is a topic
>> that I think needs to be resolved. Eventually. The reason I urgently
>> wanted the paper in the next mailing however is for the sake of P0197,
>> P0144 and their respective interactions.
> 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.
> 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. P0197 depend completely on the library and this
> could be a showstopper to his adoption.
> The adoption of P0144 should be independent of P0197 in particular, but
> we should consider the path to the big picture with pattern matching. I
> believe that the authors of P0144 know already how this should be done.
>
> Davis Sankel has been working on a pattern matching feature for sum
> types and product types [1] . This is not a concrete proposal yet but
> give an idea of how to integrate both kind of types in the language.
> David proposes to add some builtin operators that are used while doing
> pattern matching.
>
> I believe that we need to define the concept of product/sum type in the
> language because we want to provide features at the language level for
> those types.
> * structured binding
> * pattern matching
> * direct access to the parts
>
> 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.
>
> David proposes a single operator extract to extract the elements of a
> product type. This is good when we want to extract all the members, but
> not when we want one member., so I believe that we need 2 operators: one
> to get the size and one to get the n<sup>th</sup> element. The
> name/syntax of these operators needs to be defined, however, until that
> I will name them `operator product_type_size` and `operator
> product_type_nth_element`. I know that finding good names for them would
> be difficult.
>
> 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.
>
> To be compatible with the existing tuple-like types, I would propose to
> update the definition of `tuple_size`, `tuple_element` and
> `get<I>/get<T>` for product-types, and add the customization for those
> operators for the standard tuple-like types `std::tuple`, `std::pair`
> and `std::array`.
>
> 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=
..
>
> If we had the good names/syntax for those operators, P0144 could be
> adapted to them and be included in C++17. We could add PM and default
> product-type access for aggregates and so later on.
>
> What do you think of this path?
>
> Vicente
>
> [1]http://davidsankel.com/uncategorized/c-language-support-for-pattern-ma=
tching-and-variants/
>
>
> P.S. Sorry I'm not considering at all the other part of P0301
> (unpacking) and I consider that those are orthogonal features.
>

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

.

> =E2=80=8E Nobody has proposed yet the field syntax s.N.

> This will allow to have a constexpr index access a.N =C2=A0and a runtime =
one=C2=A0
a[n] for std::array.

=E2=80=8EWorks well for a.5, not so well for a.someConstant. =C2=A0

But a.<5> and a.<someConstant> might work.

Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi=
ce
=C2=A0 Original Message =C2=A0
From: Vicente J. Botet Escriba
Sent: Thursday, March 31, 2016 6:50 PM
To: std-proposals@isocpp.org
Reply To: std-proposals@isocpp.org
Subject: Re: [std-proposals] Re: [RFC] Call for considering "the big pictur=
e" re: tuples and parameter packs

Le 21/03/2016 04:21, Tony V E a =C3=A9crit :
> Could the member access syntax actually be s[N] for some struct or class =
s?
>
> ie just extend operator[] to allow the return type to be different for di=
fferent constexpr inputs.
>
> Then arrays (and vectors, etc) 'just work'. This assumes you never want t=
o access the actual members of vector (ie v._ptr and v._size or whatever th=
e vector implementation uses). I think it is safe to assume that any class =
that overrides operator[] wants to be array-like and doesn't want its membe=
rs exposed as a tuple.
>
> ?

Nobody has proposed yet the field syntax s.N.

This will allow to have a constexpr index access a.N and a runtime one=20
a[n] for std::array.

Vicente
> Sent from my BlackBerry portable Babbage Device
> Original Message
> From: Vicente J. Botet Escriba
> Sent: Sunday, March 20, 2016 7:35 PM
> To: std-proposals@isocpp.org
> Reply To: std-proposals@isocpp.org
> Subject: Re: [std-proposals] Re: [RFC] Call for considering "the big pict=
ure" re: tuples and parameter packs
>
> Le 20/03/2016 18:44, Matthew Woehlke a =C3=A9crit :
>> On 2016-03-20 04:21, Daniel Frey wrote:
>>> On 19.03.2016, at 20:15, Matthew Woehlke wrote:
>>>> On 2016-03-19 06:53, Daniel Frey wrote:
>>>>> On 18.03.2016, at 16:51, Matthew Woehlke wrote:
>>>>>> [paper]
>>>> I'm going to try to keep this brief as it is turning into a discussion
>>>> on your proposal vs. mine, which really isn't the topic. (Parameter pa=
ck
>>>> stuff in general is really only partly on topic; the main topic should
>>>> be P0197.)
>>> In a way, it is the topic. We are both trying to solve problem in a
>>> similar domain, coming from different directions and with different
>>> ideas about how to solve those problems.
>> Well... okay, yes :-). I do go into this direction, and it is a topic
>> that I think needs to be resolved. Eventually. The reason I urgently
>> wanted the paper in the next mailing however is for the sake of P0197,
>> P0144 and their respective interactions.
> 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.
> 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. P0197 depend completely on the library and this
> could be a showstopper to his adoption.
> The adoption of P0144 should be independent of P0197 in particular, but
> we should consider the path to the big picture with pattern matching. I
> believe that the authors of P0144 know already how this should be done.
>
> Davis Sankel has been working on a pattern matching feature for sum
> types and product types [1] . This is not a concrete proposal yet but
> give an idea of how to integrate both kind of types in the language.
> David proposes to add some builtin operators that are used while doing
> pattern matching.
>
> I believe that we need to define the concept of product/sum type in the
> language because we want to provide features at the language level for
> those types.
> * structured binding
> * pattern matching
> * direct access to the parts
>
> 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.
>
> David proposes a single operator extract to extract the elements of a
> product type. This is good when we want to extract all the members, but
> not when we want one member., so I believe that we need 2 operators: one
> to get the size and one to get the n<sup>th</sup> element. The
> name/syntax of these operators needs to be defined, however, until that
> I will name them `operator product_type_size` and `operator
> product_type_nth_element`. I know that finding good names for them would
> be difficult.
>
> 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.
>
> To be compatible with the existing tuple-like types, I would propose to
> update the definition of `tuple_size`, `tuple_element` and
> `get<I>/get<T>` for product-types, and add the customization for those
> operators for the standard tuple-like types `std::tuple`, `std::pair`
> and `std::array`.
>
> 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=
..
>
> If we had the good names/syntax for those operators, P0144 could be
> adapted to them and be included in C++17. We could add PM and default
> product-type access for aggregates and so later on.
>
> What do you think of this path?
>
> Vicente
>
> [1]http://davidsankel.com/uncategorized/c-language-support-for-pattern-ma=
tching-and-variants/
>
>
> P.S. Sorry I'm not considering at all the other part of P0301
> (unpacking) and I consider that those are orthogonal features.
>

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

--=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/20160401045129.4907089.96773.8905%40gmail.com.

.