Topic: Add a "tuple_slice" function in <tuple>
Author: =?UTF-8?B?zp3Ouc66z4zOu86xzr/PgiDOkc64zrHOvc6xz4POr86/z4U=?=
Date: Wed, 30 Nov 2016 13:04:57 -0800 (PST)
Raw View
------=_Part_30_711464416.1480539897551
Content-Type: multipart/alternative;
boundary="----=_Part_31_501765526.1480539897552"
------=_Part_31_501765526.1480539897552
Content-Type: text/plain; charset=UTF-8
Hello all,
Just floating the idea before composing the complete text. I recently *blogged
<https://ngathanasiou.wordpress.com/2016/11/28/want-a-std-slice/>*about a
hypothetical tuple slice functionality (and related design considerations)
and it seems useful & simple enough (conceptually and implementation wise)
to be added in isolation to the Standard library (it may just have been
overlooked in previous versions, I couldn't find related proposals). Long
story short, given "tuple_slice" :
A slice of t can be obtained like so
tuple_slice<I1, I2>(t);
Where [I1, I2) is the *exclusive range* of the subset
Proposed implementation below (please refer to the blog post
<https://ngathanasiou.wordpress.com/2016/11/28/want-a-std-slice/> for more
details):
namespace detail {
template <std::size_t Ofst, class Tuple, std::size_t... I>
constexpr auto slice_impl(Tuple&& t, std::index_sequence<I...>)
{
return std::forward_as_tuple(
std::get<I + Ofst>(std::forward<Tuple>(t))...);
}
}
template <std::size_t I1, std::size_t I2, class Cont>
constexpr auto tuple_slice(Cont&& t)
{
static_assert(I2 >= I1, "invalid slice");
static_assert(std::tuple_size<std::decay_t<Cont>>::value >= I2,
"slice index out of bounds");
return detail::slice_impl<I1>(std::forward<Cont>(t),
std::make_index_sequence<I2 - I1>{});
}
Regards,
Nick
--
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/490cad18-4302-4350-976f-2bc394a1a350%40isocpp.org.
------=_Part_31_501765526.1480539897552
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello all,=C2=A0<div><br></div><div>Just floating the idea=
before composing the complete text. I recently <b><a href=3D"https://ngath=
anasiou.wordpress.com/2016/11/28/want-a-std-slice/">blogged </a></b>about a=
hypothetical tuple slice functionality (and related design considerations)=
and it seems useful & simple enough (conceptually and implementation w=
ise) to be added in isolation to the Standard library (it may just have bee=
n overlooked in previous versions, I couldn't find related proposals). =
Long story short, given "tuple_slice" :=C2=A0</div><div><br></div=
><div>=C2=A0<span style=3D"color: rgb(85, 85, 85); font-family: Lato, "=
;Helvetica Neue", sans-serif; font-size: 18px; text-align: justify;">A=
slice of</span><span style=3D"color: rgb(85, 85, 85); font-family: Lato, &=
quot;Helvetica Neue", sans-serif; font-size: 18px; text-align: justify=
;">=C2=A0</span><code style=3D"color: rgb(85, 85, 85); text-align: justify;=
box-sizing: border-box; font-family: Monaco, Consolas, "Andale Mono&q=
uot;, "DejaVu Sans Mono", monospace; font-size: 1.6rem; outline: =
0px; padding: 5px; vertical-align: baseline; font-stretch: normal; line-hei=
ght: normal; background-color: rgb(238, 238, 238); border-radius: 3px;">t</=
code><span style=3D"color: rgb(85, 85, 85); font-family: Lato, "Helvet=
ica Neue", sans-serif; font-size: 18px; text-align: justify;">=C2=A0</=
span><span style=3D"color: rgb(85, 85, 85); font-family: Lato, "Helvet=
ica Neue", sans-serif; font-size: 18px; text-align: justify;">can be o=
btained like so</span></div><div style=3D"box-sizing: border-box; font-fami=
ly: Lato, "Helvetica Neue", sans-serif; font-size: 18px; outline:=
0px; vertical-align: baseline; color: rgb(85, 85, 85);"><div id=3D"highlig=
hter_134390" class=3D"syntaxhighlighter nogutter cpp" style=3D"box-sizing:=
border-box; font-family: inherit; font-style: inherit; font-weight: inheri=
t; outline: 0px; vertical-align: baseline; width: 662.609px; font-size: 1em=
!important; margin-top: 1em !important; margin-bottom: 1em !important; pos=
ition: relative !important; overflow-x: auto !important; overflow-y: hidden=
!important;"><table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" style=
=3D"border-collapse: collapse; width: 662px; box-sizing: content-box !impor=
tant; font-family: Consolas, "Bitstream Vera Sans Mono", "Co=
urier New", Courier, monospace !important; font-size: 1em !important; =
outline: 0px !important; vertical-align: baseline !important; border-radius=
: 0px !important; background: none !important; bottom: auto !important; flo=
at: none !important; height: auto !important; left: auto !important; line-h=
eight: 1.1em !important; overflow: visible !important; position: static !im=
portant; right: auto !important; top: auto !important; direction: ltr !impo=
rtant; box-shadow: none !important; table-layout: auto !important;"><tbody =
style=3D"box-sizing: content-box !important; font-size: 1em !important; out=
line: 0px !important; vertical-align: baseline !important; border-radius: 0=
px !important; background: none !important; bottom: auto !important; float:=
none !important; height: auto !important; left: auto !important; line-heig=
ht: 1.1em !important; overflow: visible !important; position: static !impor=
tant; right: auto !important; top: auto !important; width: auto !important;=
direction: ltr !important; box-shadow: none !important;"><tr style=3D"box-=
sizing: content-box !important; font-size: 1em !important; outline: 0px !im=
portant; vertical-align: baseline !important; border-radius: 0px !important=
; background: none !important; bottom: auto !important; float: none !import=
ant; height: auto !important; left: auto !important; line-height: 1.1em !im=
portant; overflow: visible !important; position: static !important; right: =
auto !important; top: auto !important; width: auto !important; direction: l=
tr !important; box-shadow: none !important;"><td class=3D"code" style=3D"ba=
ckground: rgb(249, 249, 249); width: 662px; box-sizing: content-box !import=
ant; font-size: 1em !important; outline: 0px !important; vertical-align: ba=
seline !important; line-height: 1.1em !important; overflow: visible !import=
ant; border-radius: 0px !important; bottom: auto !important; float: none !i=
mportant; height: auto !important; left: auto !important; position: static =
!important; right: auto !important; top: auto !important; direction: ltr !i=
mportant; box-shadow: none !important;"><div class=3D"container" style=3D"b=
ox-sizing: content-box !important; font-size: 1em !important; margin-top: 0=
px !important; margin-right: 0px !important; margin-bottom: 0px !important;=
outline: 0px !important; vertical-align: baseline !important; border-radiu=
s: 0px !important; background-image: none !important; background-position: =
initial !important; background-repeat: initial !important; bottom: auto !im=
portant; float: none !important; height: auto !important; left: auto !impor=
tant; line-height: 1.1em !important; overflow: visible !important; position=
: relative !important; right: auto !important; top: auto !important; width:=
auto !important; direction: ltr !important; box-shadow: none !important;">=
<div class=3D"line number1 index0 alt2" style=3D"box-sizing: content-box !i=
mportant; font-size: 1em !important; outline: 0px !important; padding-right=
: 1em !important; padding-left: 0em !important; vertical-align: baseline !i=
mportant; border-radius: 0px !important; background: none white !important;=
bottom: auto !important; float: none !important; height: auto !important; =
left: auto !important; line-height: 1.1em !important; overflow: visible !im=
portant; position: static !important; right: auto !important; top: auto !im=
portant; width: auto !important; direction: ltr !important; box-shadow: non=
e !important; white-space: pre !important;"><code class=3D"cpp plain" style=
=3D"font-stretch: normal; box-sizing: content-box !important; font-family: =
Consolas, "Bitstream Vera Sans Mono", "Courier New", Co=
urier, monospace !important; font-size: 1em !important; outline: 0px !impor=
tant; vertical-align: baseline !important; line-height: 1.1em !important; b=
ackground: none !important; border-radius: 0px !important; bottom: auto !im=
portant; float: none !important; height: auto !important; left: auto !impor=
tant; overflow: visible !important; position: static !important; right: aut=
o !important; top: auto !important; width: auto !important; direction: ltr =
!important; box-shadow: none !important; display: inline !important;">tuple=
_slice<I1, I2>(t);</code></div></div></td></tr></tbody></table></div>=
</div><p style=3D"box-sizing: border-box; font-family: Lato, "Helvetic=
a Neue", sans-serif; font-size: 18px; margin-bottom: 1.1em; outline: 0=
px; vertical-align: baseline; line-height: 1.7; color: rgb(85, 85, 85); tex=
t-align: justify;">Where=C2=A0<code style=3D"box-sizing: border-box; font-f=
amily: Monaco, Consolas, "Andale Mono", "DejaVu Sans Mono&qu=
ot;, monospace; font-size: 1.6rem; outline: 0px; padding: 5px; vertical-ali=
gn: baseline; font-stretch: normal; line-height: normal; background-color: =
rgb(238, 238, 238); border-radius: 3px;">[I1, I2)</code>=C2=A0is the=C2=A0<=
strong style=3D"box-sizing: border-box; font-family: inherit; font-style: i=
nherit; outline: 0px; vertical-align: baseline;">exclusive range</strong>=
=C2=A0of the subset</p><p style=3D"text-align: start; box-sizing: border-bo=
x; margin-bottom: 1.1em; outline: 0px; vertical-align: baseline; line-heigh=
t: 1.7;">Proposed implementation below (please refer to the <a href=3D"http=
s://ngathanasiou.wordpress.com/2016/11/28/want-a-std-slice/">blog post</a> =
for more details):</p><table class=3D"highlight tab-size js-file-line-conta=
iner" data-tab-size=3D"8" style=3D"box-sizing: border-box; font-family: Con=
solas, "Liberation Mono", Menlo, Courier, monospace; font-size: 1=
2px; outline: 0px; vertical-align: baseline; border-collapse: collapse; wid=
th: 660px; line-height: 1.4; color: rgb(51, 51, 51); background-image: init=
ial; background-position: initial; background-size: initial; background-rep=
eat: initial; background-attachment: initial; background-origin: initial; b=
ackground-clip: initial;"><tbody style=3D"box-sizing: border-box; font-fami=
ly: inherit; font-style: inherit; font-weight: inherit; outline: 0px; verti=
cal-align: baseline;"><tr style=3D"box-sizing: border-box; font-family: inh=
erit; font-style: inherit; font-weight: inherit; outline: 0px; vertical-ali=
gn: baseline;"><td id=3D"file-tuple_slice-cpp-LC1" class=3D"blob-code blob-=
code-inner js-file-line" style=3D"box-sizing: border-box; font-style: inher=
it; outline: 0px; padding-top: 4px; vertical-align: top; line-height: 20px;=
overflow: visible; position: relative; word-wrap: normal; white-space: pre=
; background: rgb(249, 249, 249); padding-right: 10px !important; padding-b=
ottom: 1px !important; padding-left: 10px !important;"><span class=3D"pl-k"=
style=3D"box-sizing: border-box; font-family: inherit; font-style: inherit=
; font-weight: inherit; outline: 0px; vertical-align: baseline; color: rgb(=
167, 29, 93);"><table class=3D"highlight tab-size js-file-line-container" d=
ata-tab-size=3D"8" style=3D"box-sizing: border-box; outline: 0px; vertical-=
align: baseline; border-collapse: collapse; width: 660px; line-height: 1.4;=
color: rgb(51, 51, 51); background: rgb(255, 255, 255); white-space: norma=
l;"><tbody style=3D"box-sizing: border-box; font-family: inherit; font-styl=
e: inherit; font-weight: inherit; outline: 0px; vertical-align: baseline;">=
<tr style=3D"box-sizing: border-box; font-family: inherit; font-style: inhe=
rit; font-weight: inherit; outline: 0px; vertical-align: baseline;"><td id=
=3D"file-tuple_slice-cpp-LC1" class=3D"blob-code blob-code-inner js-file-li=
ne" style=3D"box-sizing: border-box; font-style: inherit; outline: 0px; pad=
ding-top: 4px; vertical-align: top; line-height: 20px; overflow: visible; p=
osition: relative; word-wrap: normal; white-space: pre; background: rgb(249=
, 249, 249); padding-right: 10px !important; padding-bottom: 1px !important=
; padding-left: 10px !important;"><br></td></tr><tr style=3D"box-sizing: bo=
rder-box; font-family: inherit; font-style: inherit; font-weight: inherit; =
outline: 0px; vertical-align: baseline;"><td id=3D"file-tuple_slice-cpp-L2"=
class=3D"blob-num js-line-number" data-line-number=3D"2" style=3D"box-sizi=
ng: border-box; border-right: 1px solid rgb(238, 238, 238); border-top-styl=
e: solid; border-bottom-style: solid; border-left-style: solid; border-top-=
color: rgb(238, 238, 238); border-bottom-color: rgb(238, 238, 238); border-=
left-color: rgb(238, 238, 238); font-style: inherit; outline: 0px; vertical=
-align: top; text-align: right; line-height: 20px; overflow: visible; width=
: 34px; min-width: inherit; color: rgba(0, 0, 0, 0.298039); white-space: no=
wrap; cursor: pointer; user-select: none; background: transparent; padding:=
1px 10px !important;"></td><td id=3D"file-tuple_slice-cpp-LC2" class=3D"bl=
ob-code blob-code-inner js-file-line" style=3D"box-sizing: border-box; font=
-style: inherit; outline: 0px; vertical-align: top; line-height: 20px; over=
flow: visible; position: relative; word-wrap: normal; white-space: pre; bac=
kground: transparent; padding: 1px 10px !important;"><span style=3D"color: =
rgb(167, 29, 93);">namespace</span> detail
{</td></tr><tr style=3D"box-sizing: border-box; font-family: inherit; font-=
style: inherit; font-weight: inherit; outline: 0px; vertical-align: baselin=
e;"><td id=3D"file-tuple_slice-cpp-L3" class=3D"blob-num js-line-number" da=
ta-line-number=3D"3" style=3D"box-sizing: border-box; border-right: 1px sol=
id rgb(238, 238, 238); border-top-style: solid; border-bottom-style: solid;=
border-left-style: solid; border-top-color: rgb(238, 238, 238); border-bot=
tom-color: rgb(238, 238, 238); border-left-color: rgb(238, 238, 238); font-=
style: inherit; outline: 0px; vertical-align: top; text-align: right; line-=
height: 20px; overflow: visible; width: 34px; min-width: inherit; color: rg=
ba(0, 0, 0, 0.298039); white-space: nowrap; cursor: pointer; user-select: n=
one; background: rgb(249, 249, 249); padding: 1px 10px !important;"></td><t=
d id=3D"file-tuple_slice-cpp-LC3" class=3D"blob-code blob-code-inner js-fil=
e-line" style=3D"box-sizing: border-box; font-style: inherit; outline: 0px;=
vertical-align: top; line-height: 20px; overflow: visible; position: relat=
ive; word-wrap: normal; white-space: pre; background: rgb(249, 249, 249); p=
adding: 1px 10px !important;"> <span class=3D"pl-k" style=3D"box-sizing: bo=
rder-box; font-family: inherit; font-style: inherit; font-weight: inherit; =
outline: 0px; vertical-align: baseline; color: rgb(167, 29, 93);">template =
</span><std::<span class=3D"pl-c1" style=3D"box-sizing: border-box; font=
-family: inherit; font-style: inherit; font-weight: inherit; outline: 0px; =
vertical-align: baseline; color: rgb(0, 134, 179);">size_t</span> Ofst, <sp=
an class=3D"pl-k" style=3D"box-sizing: border-box; font-family: inherit; fo=
nt-style: inherit; font-weight: inherit; outline: 0px; vertical-align: base=
line; color: rgb(167, 29, 93);">class</span> <span class=3D"pl-en" style=3D=
"box-sizing: border-box; font-family: inherit; font-style: inherit; font-we=
ight: inherit; outline: 0px; vertical-align: baseline; color: rgb(121, 93, =
163);">Tuple</span>, std::<span class=3D"pl-c1" style=3D"box-sizing: border=
-box; font-family: inherit; font-style: inherit; font-weight: inherit; outl=
ine: 0px; vertical-align: baseline; color: rgb(0, 134, 179);">size_t</span>=
.... I></td></tr><tr style=3D"box-sizing: border-box; font-family: inheri=
t; font-style: inherit; font-weight: inherit; outline: 0px; vertical-align:=
baseline;"><td id=3D"file-tuple_slice-cpp-L4" class=3D"blob-num js-line-nu=
mber" data-line-number=3D"4" style=3D"box-sizing: border-box; border-right:=
1px solid rgb(238, 238, 238); border-top-style: solid; border-bottom-style=
: solid; border-left-style: solid; border-top-color: rgb(238, 238, 238); bo=
rder-bottom-color: rgb(238, 238, 238); border-left-color: rgb(238, 238, 238=
); font-style: inherit; outline: 0px; vertical-align: top; text-align: righ=
t; line-height: 20px; overflow: visible; width: 34px; min-width: inherit; c=
olor: rgba(0, 0, 0, 0.298039); white-space: nowrap; cursor: pointer; user-s=
elect: none; background: transparent; padding: 1px 10px !important;"></td><=
td id=3D"file-tuple_slice-cpp-LC4" class=3D"blob-code blob-code-inner js-fi=
le-line" style=3D"box-sizing: border-box; font-style: inherit; outline: 0px=
; vertical-align: top; line-height: 20px; overflow: visible; position: rela=
tive; word-wrap: normal; white-space: pre; background: transparent; padding=
: 1px 10px !important;"> <span class=3D"pl-k" style=3D"box-sizing: border-b=
ox; font-family: inherit; font-style: inherit; font-weight: inherit; outlin=
e: 0px; vertical-align: baseline; color: rgb(167, 29, 93);">constexpr</span=
> <span class=3D"pl-k" style=3D"box-sizing: border-box; font-family: inheri=
t; font-style: inherit; font-weight: inherit; outline: 0px; vertical-align:=
baseline; color: rgb(167, 29, 93);">auto</span> <span class=3D"pl-en" styl=
e=3D"box-sizing: border-box; font-family: inherit; font-style: inherit; fon=
t-weight: inherit; outline: 0px; vertical-align: baseline; color: rgb(121, =
93, 163);">slice_impl</span>(Tuple&& t, std::index_sequence<I...=
>)</td></tr><tr style=3D"box-sizing: border-box; font-family: inherit; f=
ont-style: inherit; font-weight: inherit; outline: 0px; vertical-align: bas=
eline;"><td id=3D"file-tuple_slice-cpp-L5" class=3D"blob-num js-line-number=
" data-line-number=3D"5" style=3D"box-sizing: border-box; border-right: 1px=
solid rgb(238, 238, 238); border-top-style: solid; border-bottom-style: so=
lid; border-left-style: solid; border-top-color: rgb(238, 238, 238); border=
-bottom-color: rgb(238, 238, 238); border-left-color: rgb(238, 238, 238); f=
ont-style: inherit; outline: 0px; vertical-align: top; text-align: right; l=
ine-height: 20px; overflow: visible; width: 34px; min-width: inherit; color=
: rgba(0, 0, 0, 0.298039); white-space: nowrap; cursor: pointer; user-selec=
t: none; background: rgb(249, 249, 249); padding: 1px 10px !important;"></t=
d><td id=3D"file-tuple_slice-cpp-LC5" class=3D"blob-code blob-code-inner js=
-file-line" style=3D"box-sizing: border-box; font-style: inherit; outline: =
0px; vertical-align: top; line-height: 20px; overflow: visible; position: r=
elative; word-wrap: normal; white-space: pre; background: rgb(249, 249, 249=
); padding: 1px 10px !important;"> {</td></tr><tr style=3D"box-sizing: bord=
er-box; font-family: inherit; font-style: inherit; font-weight: inherit; ou=
tline: 0px; vertical-align: baseline;"><td id=3D"file-tuple_slice-cpp-L6" c=
lass=3D"blob-num js-line-number" data-line-number=3D"6" style=3D"box-sizing=
: border-box; border-right: 1px solid rgb(238, 238, 238); border-top-style:=
solid; border-bottom-style: solid; border-left-style: solid; border-top-co=
lor: rgb(238, 238, 238); border-bottom-color: rgb(238, 238, 238); border-le=
ft-color: rgb(238, 238, 238); font-style: inherit; outline: 0px; vertical-a=
lign: top; text-align: right; line-height: 20px; overflow: visible; width: =
34px; min-width: inherit; color: rgba(0, 0, 0, 0.298039); white-space: nowr=
ap; cursor: pointer; user-select: none; background: transparent; padding: 1=
px 10px !important;"></td><td id=3D"file-tuple_slice-cpp-LC6" class=3D"blob=
-code blob-code-inner js-file-line" style=3D"box-sizing: border-box; font-s=
tyle: inherit; outline: 0px; vertical-align: top; line-height: 20px; overfl=
ow: visible; position: relative; word-wrap: normal; white-space: pre; backg=
round: transparent; padding: 1px 10px !important;"> <span class=3D"pl-k" s=
tyle=3D"box-sizing: border-box; font-family: inherit; font-style: inherit; =
font-weight: inherit; outline: 0px; vertical-align: baseline; color: rgb(16=
7, 29, 93);">return</span> <span class=3D"pl-c1" style=3D"box-sizing: borde=
r-box; font-family: inherit; font-style: inherit; font-weight: inherit; out=
line: 0px; vertical-align: baseline; color: rgb(0, 134, 179);">std::forward=
_as_tuple</span>(</td></tr><tr style=3D"box-sizing: border-box; font-family=
: inherit; font-style: inherit; font-weight: inherit; outline: 0px; vertica=
l-align: baseline;"><td id=3D"file-tuple_slice-cpp-L7" class=3D"blob-num js=
-line-number" data-line-number=3D"7" style=3D"box-sizing: border-box; borde=
r-right: 1px solid rgb(238, 238, 238); border-top-style: solid; border-bott=
om-style: solid; border-left-style: solid; border-top-color: rgb(238, 238, =
238); border-bottom-color: rgb(238, 238, 238); border-left-color: rgb(238, =
238, 238); font-style: inherit; outline: 0px; vertical-align: top; text-ali=
gn: right; line-height: 20px; overflow: visible; width: 34px; min-width: in=
herit; color: rgba(0, 0, 0, 0.298039); white-space: nowrap; cursor: pointer=
; user-select: none; background: rgb(249, 249, 249); padding: 1px 10px !imp=
ortant;"></td><td id=3D"file-tuple_slice-cpp-LC7" class=3D"blob-code blob-c=
ode-inner js-file-line" style=3D"box-sizing: border-box; font-style: inheri=
t; outline: 0px; vertical-align: top; line-height: 20px; overflow: visible;=
position: relative; word-wrap: normal; white-space: pre; background: rgb(2=
49, 249, 249); padding: 1px 10px !important;"> std::get<I + Ofst>(s=
td::forward<Tuple>(t))...);</td></tr><tr style=3D"box-sizing: border-=
box; font-family: inherit; font-style: inherit; font-weight: inherit; outli=
ne: 0px; vertical-align: baseline;"><td id=3D"file-tuple_slice-cpp-L8" clas=
s=3D"blob-num js-line-number" data-line-number=3D"8" style=3D"box-sizing: b=
order-box; border-right: 1px solid rgb(238, 238, 238); border-top-style: so=
lid; border-bottom-style: solid; border-left-style: solid; border-top-color=
: rgb(238, 238, 238); border-bottom-color: rgb(238, 238, 238); border-left-=
color: rgb(238, 238, 238); font-style: inherit; outline: 0px; vertical-alig=
n: top; text-align: right; line-height: 20px; overflow: visible; width: 34p=
x; min-width: inherit; color: rgba(0, 0, 0, 0.298039); white-space: nowrap;=
cursor: pointer; user-select: none; background: transparent; padding: 1px =
10px !important;"></td><td id=3D"file-tuple_slice-cpp-LC8" class=3D"blob-co=
de blob-code-inner js-file-line" style=3D"box-sizing: border-box; font-styl=
e: inherit; outline: 0px; vertical-align: top; line-height: 20px; overflow:=
visible; position: relative; word-wrap: normal; white-space: pre; backgrou=
nd: transparent; padding: 1px 10px !important;"> }</td></tr><tr style=3D"bo=
x-sizing: border-box; font-family: inherit; font-style: inherit; font-weigh=
t: inherit; outline: 0px; vertical-align: baseline;"><td id=3D"file-tuple_s=
lice-cpp-L9" class=3D"blob-num js-line-number" data-line-number=3D"9" style=
=3D"box-sizing: border-box; border-right: 1px solid rgb(238, 238, 238); bor=
der-top-style: solid; border-bottom-style: solid; border-left-style: solid;=
border-top-color: rgb(238, 238, 238); border-bottom-color: rgb(238, 238, 2=
38); border-left-color: rgb(238, 238, 238); font-style: inherit; outline: 0=
px; vertical-align: top; text-align: right; line-height: 20px; overflow: vi=
sible; width: 34px; min-width: inherit; color: rgba(0, 0, 0, 0.298039); whi=
te-space: nowrap; cursor: pointer; user-select: none; background: rgb(249, =
249, 249); padding: 1px 10px !important;"></td><td id=3D"file-tuple_slice-c=
pp-LC9" class=3D"blob-code blob-code-inner js-file-line" style=3D"box-sizin=
g: border-box; font-style: inherit; outline: 0px; vertical-align: top; line=
-height: 20px; overflow: visible; position: relative; word-wrap: normal; wh=
ite-space: pre; background: rgb(249, 249, 249); padding: 1px 10px !importan=
t;">}</td></tr><tr style=3D"box-sizing: border-box; font-family: inherit; f=
ont-style: inherit; font-weight: inherit; outline: 0px; vertical-align: bas=
eline;"><td id=3D"file-tuple_slice-cpp-L10" class=3D"blob-num js-line-numbe=
r" data-line-number=3D"10" style=3D"box-sizing: border-box; border-right: 1=
px solid rgb(238, 238, 238); border-top-style: solid; border-bottom-style: =
solid; border-left-style: solid; border-top-color: rgb(238, 238, 238); bord=
er-bottom-color: rgb(238, 238, 238); border-left-color: rgb(238, 238, 238);=
font-style: inherit; outline: 0px; vertical-align: top; text-align: right;=
line-height: 20px; overflow: visible; width: 34px; min-width: inherit; col=
or: rgba(0, 0, 0, 0.298039); white-space: nowrap; cursor: pointer; user-sel=
ect: none; background: transparent; padding: 1px 10px !important;"></td><td=
id=3D"file-tuple_slice-cpp-LC10" class=3D"blob-code blob-code-inner js-fil=
e-line" style=3D"box-sizing: border-box; font-style: inherit; outline: 0px;=
vertical-align: top; line-height: 20px; overflow: visible; position: relat=
ive; word-wrap: normal; white-space: pre; background: transparent; padding:=
1px 10px !important;">
</td></tr><tr style=3D"box-sizing: border-box; font-family: inherit; font-s=
tyle: inherit; font-weight: inherit; outline: 0px; vertical-align: baseline=
;"><td id=3D"file-tuple_slice-cpp-L11" class=3D"blob-num js-line-number" da=
ta-line-number=3D"11" style=3D"box-sizing: border-box; border-right: 1px so=
lid rgb(238, 238, 238); border-top-style: solid; border-bottom-style: solid=
; border-left-style: solid; border-top-color: rgb(238, 238, 238); border-bo=
ttom-color: rgb(238, 238, 238); border-left-color: rgb(238, 238, 238); font=
-style: inherit; outline: 0px; vertical-align: top; text-align: right; line=
-height: 20px; overflow: visible; width: 34px; min-width: inherit; color: r=
gba(0, 0, 0, 0.298039); white-space: nowrap; cursor: pointer; user-select: =
none; background: rgb(249, 249, 249); padding: 1px 10px !important;"></td><=
td id=3D"file-tuple_slice-cpp-LC11" class=3D"blob-code blob-code-inner js-f=
ile-line" style=3D"box-sizing: border-box; font-style: inherit; outline: 0p=
x; vertical-align: top; line-height: 20px; overflow: visible; position: rel=
ative; word-wrap: normal; white-space: pre; background: rgb(249, 249, 249);=
padding: 1px 10px !important;"><span class=3D"pl-k" style=3D"box-sizing: b=
order-box; font-family: inherit; font-style: inherit; font-weight: inherit;=
outline: 0px; vertical-align: baseline; color: rgb(167, 29, 93);">template=
</span><std::<span class=3D"pl-c1" style=3D"box-sizing: border-box; fon=
t-family: inherit; font-style: inherit; font-weight: inherit; outline: 0px;=
vertical-align: baseline; color: rgb(0, 134, 179);">size_t</span> I1, std:=
:<span class=3D"pl-c1" style=3D"box-sizing: border-box; font-family: inheri=
t; font-style: inherit; font-weight: inherit; outline: 0px; vertical-align:=
baseline; color: rgb(0, 134, 179);">size_t</span> I2, <span class=3D"pl-k"=
style=3D"box-sizing: border-box; font-family: inherit; font-style: inherit=
; font-weight: inherit; outline: 0px; vertical-align: baseline; color: rgb(=
167, 29, 93);">class</span> <span class=3D"pl-en" style=3D"box-sizing: bord=
er-box; font-family: inherit; font-style: inherit; font-weight: inherit; ou=
tline: 0px; vertical-align: baseline; color: rgb(121, 93, 163);">Cont</span=
>></td></tr><tr style=3D"box-sizing: border-box; font-family: inherit; f=
ont-style: inherit; font-weight: inherit; outline: 0px; vertical-align: bas=
eline;"><td id=3D"file-tuple_slice-cpp-L12" class=3D"blob-num js-line-numbe=
r" data-line-number=3D"12" style=3D"box-sizing: border-box; border-right: 1=
px solid rgb(238, 238, 238); border-top-style: solid; border-bottom-style: =
solid; border-left-style: solid; border-top-color: rgb(238, 238, 238); bord=
er-bottom-color: rgb(238, 238, 238); border-left-color: rgb(238, 238, 238);=
font-style: inherit; outline: 0px; vertical-align: top; text-align: right;=
line-height: 20px; overflow: visible; width: 34px; min-width: inherit; col=
or: rgba(0, 0, 0, 0.298039); white-space: nowrap; cursor: pointer; user-sel=
ect: none; background: transparent; padding: 1px 10px !important;"></td><td=
id=3D"file-tuple_slice-cpp-LC12" class=3D"blob-code blob-code-inner js-fil=
e-line" style=3D"box-sizing: border-box; font-style: inherit; outline: 0px;=
vertical-align: top; line-height: 20px; overflow: visible; position: relat=
ive; word-wrap: normal; white-space: pre; background: transparent; padding:=
1px 10px !important;"><span class=3D"pl-k" style=3D"box-sizing: border-box=
; font-family: inherit; font-style: inherit; font-weight: inherit; outline:=
0px; vertical-align: baseline; color: rgb(167, 29, 93);">constexpr</span> =
<span class=3D"pl-k" style=3D"box-sizing: border-box; font-family: inherit;=
font-style: inherit; font-weight: inherit; outline: 0px; vertical-align: b=
aseline; color: rgb(167, 29, 93);">auto</span> <span class=3D"pl-en" style=
=3D"box-sizing: border-box; font-family: inherit; font-style: inherit; font=
-weight: inherit; outline: 0px; vertical-align: baseline; color: rgb(121, 9=
3, 163);">tuple_slice</span>(Cont&& t)</td></tr><tr style=3D"box-si=
zing: border-box; font-family: inherit; font-style: inherit; font-weight: i=
nherit; outline: 0px; vertical-align: baseline;"><td id=3D"file-tuple_slice=
-cpp-L13" class=3D"blob-num js-line-number" data-line-number=3D"13" style=
=3D"box-sizing: border-box; border-right: 1px solid rgb(238, 238, 238); bor=
der-top-style: solid; border-bottom-style: solid; border-left-style: solid;=
border-top-color: rgb(238, 238, 238); border-bottom-color: rgb(238, 238, 2=
38); border-left-color: rgb(238, 238, 238); font-style: inherit; outline: 0=
px; vertical-align: top; text-align: right; line-height: 20px; overflow: vi=
sible; width: 34px; min-width: inherit; color: rgba(0, 0, 0, 0.298039); whi=
te-space: nowrap; cursor: pointer; user-select: none; background: rgb(249, =
249, 249); padding: 1px 10px !important;"></td><td id=3D"file-tuple_slice-c=
pp-LC13" class=3D"blob-code blob-code-inner js-file-line" style=3D"box-sizi=
ng: border-box; font-style: inherit; outline: 0px; vertical-align: top; lin=
e-height: 20px; overflow: visible; position: relative; word-wrap: normal; w=
hite-space: pre; background: rgb(249, 249, 249); padding: 1px 10px !importa=
nt;">{</td></tr><tr style=3D"box-sizing: border-box; font-family: inherit; =
font-style: inherit; font-weight: inherit; outline: 0px; vertical-align: ba=
seline;"><td id=3D"file-tuple_slice-cpp-L14" class=3D"blob-num js-line-numb=
er" data-line-number=3D"14" style=3D"box-sizing: border-box; border-right: =
1px solid rgb(238, 238, 238); border-top-style: solid; border-bottom-style:=
solid; border-left-style: solid; border-top-color: rgb(238, 238, 238); bor=
der-bottom-color: rgb(238, 238, 238); border-left-color: rgb(238, 238, 238)=
; font-style: inherit; outline: 0px; vertical-align: top; text-align: right=
; line-height: 20px; overflow: visible; width: 34px; min-width: inherit; co=
lor: rgba(0, 0, 0, 0.298039); white-space: nowrap; cursor: pointer; user-se=
lect: none; background: transparent; padding: 1px 10px !important;"></td><t=
d id=3D"file-tuple_slice-cpp-LC14" class=3D"blob-code blob-code-inner js-fi=
le-line" style=3D"box-sizing: border-box; font-style: inherit; outline: 0px=
; vertical-align: top; line-height: 20px; overflow: visible; position: rela=
tive; word-wrap: normal; white-space: pre; background: transparent; padding=
: 1px 10px !important;"> <span class=3D"pl-c1" style=3D"box-sizing: border-=
box; font-family: inherit; font-style: inherit; font-weight: inherit; outli=
ne: 0px; vertical-align: baseline; color: rgb(0, 134, 179);">static_assert<=
/span>(I2 >=3D I1, <span class=3D"pl-s" style=3D"box-sizing: border-box;=
font-family: inherit; font-style: inherit; font-weight: inherit; outline: =
0px; vertical-align: baseline; color: rgb(24, 54, 145);"><span class=3D"pl-=
pds" style=3D"box-sizing: border-box; font-family: inherit; font-style: inh=
erit; font-weight: inherit; outline: 0px; vertical-align: baseline;">"=
</span>invalid slice<span class=3D"pl-pds" style=3D"box-sizing: border-box;=
font-family: inherit; font-style: inherit; font-weight: inherit; outline: =
0px; vertical-align: baseline;">"</span></span>);</td></tr><tr style=
=3D"box-sizing: border-box; font-family: inherit; font-style: inherit; font=
-weight: inherit; outline: 0px; vertical-align: baseline;"><td id=3D"file-t=
uple_slice-cpp-L15" class=3D"blob-num js-line-number" data-line-number=3D"1=
5" style=3D"box-sizing: border-box; border-right: 1px solid rgb(238, 238, 2=
38); border-top-style: solid; border-bottom-style: solid; border-left-style=
: solid; border-top-color: rgb(238, 238, 238); border-bottom-color: rgb(238=
, 238, 238); border-left-color: rgb(238, 238, 238); font-style: inherit; ou=
tline: 0px; vertical-align: top; text-align: right; line-height: 20px; over=
flow: visible; width: 34px; min-width: inherit; color: rgba(0, 0, 0, 0.2980=
39); white-space: nowrap; cursor: pointer; user-select: none; background: r=
gb(249, 249, 249); padding: 1px 10px !important;"></td><td id=3D"file-tuple=
_slice-cpp-LC15" class=3D"blob-code blob-code-inner js-file-line" style=3D"=
box-sizing: border-box; font-style: inherit; outline: 0px; vertical-align: =
top; line-height: 20px; overflow: visible; position: relative; word-wrap: n=
ormal; white-space: pre; background: rgb(249, 249, 249); padding: 1px 10px =
!important;"> <span class=3D"pl-c1" style=3D"box-sizing: border-box; font-f=
amily: inherit; font-style: inherit; font-weight: inherit; outline: 0px; ve=
rtical-align: baseline; color: rgb(0, 134, 179);">static_assert</span>(std:=
:tuple_size<std::<span class=3D"pl-c1" style=3D"box-sizing: border-box; =
font-family: inherit; font-style: inherit; font-weight: inherit; outline: 0=
px; vertical-align: baseline; color: rgb(0, 134, 179);">decay_t</span><C=
ont>>::value >=3D I2,</td></tr><tr style=3D"box-sizing: border-box=
; font-family: inherit; font-style: inherit; font-weight: inherit; outline:=
0px; vertical-align: baseline;"><td id=3D"file-tuple_slice-cpp-L16" class=
=3D"blob-num js-line-number" data-line-number=3D"16" style=3D"box-sizing: b=
order-box; border-right: 1px solid rgb(238, 238, 238); border-top-style: so=
lid; border-bottom-style: solid; border-left-style: solid; border-top-color=
: rgb(238, 238, 238); border-bottom-color: rgb(238, 238, 238); border-left-=
color: rgb(238, 238, 238); font-style: inherit; outline: 0px; vertical-alig=
n: top; text-align: right; line-height: 20px; overflow: visible; width: 34p=
x; min-width: inherit; color: rgba(0, 0, 0, 0.298039); white-space: nowrap;=
cursor: pointer; user-select: none; background: transparent; padding: 1px =
10px !important;"></td><td id=3D"file-tuple_slice-cpp-LC16" class=3D"blob-c=
ode blob-code-inner js-file-line" style=3D"box-sizing: border-box; font-sty=
le: inherit; outline: 0px; vertical-align: top; line-height: 20px; overflow=
: visible; position: relative; word-wrap: normal; white-space: pre; backgro=
und: transparent; padding: 1px 10px !important;"> <span class=3D"pl-s" sty=
le=3D"box-sizing: border-box; font-family: inherit; font-style: inherit; fo=
nt-weight: inherit; outline: 0px; vertical-align: baseline; color: rgb(24, =
54, 145);"><span class=3D"pl-pds" style=3D"box-sizing: border-box; font-fam=
ily: inherit; font-style: inherit; font-weight: inherit; outline: 0px; vert=
ical-align: baseline;">"</span>slice index out of bounds<span class=3D=
"pl-pds" style=3D"box-sizing: border-box; font-family: inherit; font-style:=
inherit; font-weight: inherit; outline: 0px; vertical-align: baseline;">&q=
uot;</span></span>);</td></tr><tr style=3D"box-sizing: border-box; font-fam=
ily: inherit; font-style: inherit; font-weight: inherit; outline: 0px; vert=
ical-align: baseline;"><td id=3D"file-tuple_slice-cpp-L17" class=3D"blob-nu=
m js-line-number" data-line-number=3D"17" style=3D"box-sizing: border-box; =
border-right: 1px solid rgb(238, 238, 238); border-top-style: solid; border=
-bottom-style: solid; border-left-style: solid; border-top-color: rgb(238, =
238, 238); border-bottom-color: rgb(238, 238, 238); border-left-color: rgb(=
238, 238, 238); font-style: inherit; outline: 0px; vertical-align: top; tex=
t-align: right; line-height: 20px; overflow: visible; width: 34px; min-widt=
h: inherit; color: rgba(0, 0, 0, 0.298039); white-space: nowrap; cursor: po=
inter; user-select: none; background: rgb(249, 249, 249); padding: 1px 10px=
!important;"></td><td id=3D"file-tuple_slice-cpp-LC17" class=3D"blob-code =
blob-code-inner js-file-line" style=3D"box-sizing: border-box; font-style: =
inherit; outline: 0px; vertical-align: top; line-height: 20px; overflow: vi=
sible; position: relative; word-wrap: normal; white-space: pre; background:=
rgb(249, 249, 249); padding: 1px 10px !important;">
</td></tr><tr style=3D"box-sizing: border-box; font-family: inherit; font-s=
tyle: inherit; font-weight: inherit; outline: 0px; vertical-align: baseline=
;"><td id=3D"file-tuple_slice-cpp-L18" class=3D"blob-num js-line-number" da=
ta-line-number=3D"18" style=3D"box-sizing: border-box; border-right: 1px so=
lid rgb(238, 238, 238); border-top-style: solid; border-bottom-style: solid=
; border-left-style: solid; border-top-color: rgb(238, 238, 238); border-bo=
ttom-color: rgb(238, 238, 238); border-left-color: rgb(238, 238, 238); font=
-style: inherit; outline: 0px; vertical-align: top; text-align: right; line=
-height: 20px; overflow: visible; width: 34px; min-width: inherit; color: r=
gba(0, 0, 0, 0.298039); white-space: nowrap; cursor: pointer; user-select: =
none; background: transparent; padding: 1px 10px !important;"></td><td id=
=3D"file-tuple_slice-cpp-LC18" class=3D"blob-code blob-code-inner js-file-l=
ine" style=3D"box-sizing: border-box; font-style: inherit; outline: 0px; ve=
rtical-align: top; line-height: 20px; overflow: visible; position: relative=
; word-wrap: normal; white-space: pre; background: transparent; padding: 1p=
x 10px !important;"> <span class=3D"pl-k" style=3D"box-sizing: border-box; =
font-family: inherit; font-style: inherit; font-weight: inherit; outline: 0=
px; vertical-align: baseline; color: rgb(167, 29, 93);">return</span> detai=
l::slice_impl<I1>(std::forward<Cont>(t),</td></tr><tr style=3D"=
box-sizing: border-box; font-family: inherit; font-style: inherit; font-wei=
ght: inherit; outline: 0px; vertical-align: baseline;"><td id=3D"file-tuple=
_slice-cpp-L19" class=3D"blob-num js-line-number" data-line-number=3D"19" s=
tyle=3D"box-sizing: border-box; border-right: 1px solid rgb(238, 238, 238);=
border-top-style: solid; border-bottom-style: solid; border-left-style: so=
lid; border-top-color: rgb(238, 238, 238); border-bottom-color: rgb(238, 23=
8, 238); border-left-color: rgb(238, 238, 238); font-style: inherit; outlin=
e: 0px; vertical-align: top; text-align: right; line-height: 20px; overflow=
: visible; width: 34px; min-width: inherit; color: rgba(0, 0, 0, 0.298039);=
white-space: nowrap; cursor: pointer; user-select: none; background: rgb(2=
49, 249, 249); padding: 1px 10px !important;"></td><td id=3D"file-tuple_sli=
ce-cpp-LC19" class=3D"blob-code blob-code-inner js-file-line" style=3D"box-=
sizing: border-box; font-style: inherit; outline: 0px; vertical-align: top;=
line-height: 20px; overflow: visible; position: relative; word-wrap: norma=
l; white-space: pre; background: rgb(249, 249, 249); padding: 1px 10px !imp=
ortant;"> std::make_index_sequence<I2 - I1>{});</td></tr><tr style=
=3D"box-sizing: border-box; font-family: inherit; font-style: inherit; font=
-weight: inherit; outline: 0px; vertical-align: baseline;"><td id=3D"file-t=
uple_slice-cpp-L20" class=3D"blob-num js-line-number" data-line-number=3D"2=
0" style=3D"box-sizing: border-box; border-right: 1px solid rgb(238, 238, 2=
38); border-top-style: solid; border-bottom-style: solid; border-left-style=
: solid; border-top-color: rgb(238, 238, 238); border-bottom-color: rgb(238=
, 238, 238); border-left-color: rgb(238, 238, 238); font-style: inherit; ou=
tline: 0px; vertical-align: top; text-align: right; line-height: 20px; over=
flow: visible; width: 34px; min-width: inherit; color: rgba(0, 0, 0, 0.2980=
39); white-space: nowrap; cursor: pointer; user-select: none; background: t=
ransparent; padding: 1px 10px !important;"></td><td id=3D"file-tuple_slice-=
cpp-LC20" class=3D"blob-code blob-code-inner js-file-line" style=3D"box-siz=
ing: border-box; font-style: inherit; outline: 0px; vertical-align: top; li=
ne-height: 20px; overflow: visible; position: relative; word-wrap: normal; =
white-space: pre; background: transparent; padding: 1px 10px !important;">}=
</td></tr></tbody></table> </span></td></tr></tbody></table><p style=3D"tex=
t-align: start; box-sizing: border-box; margin-bottom: 1.1em; outline: 0px;=
vertical-align: baseline; line-height: 1.7;"><br>Regards,=C2=A0</p><p styl=
e=3D"text-align: start; box-sizing: border-box; margin-bottom: 1.1em; outli=
ne: 0px; vertical-align: baseline; line-height: 1.7;">Nick</p></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/490cad18-4302-4350-976f-2bc394a1a350%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/490cad18-4302-4350-976f-2bc394a1a350=
%40isocpp.org</a>.<br />
------=_Part_31_501765526.1480539897552--
------=_Part_30_711464416.1480539897551--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Wed, 30 Nov 2016 16:53:19 -0500
Raw View
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 recently *bl=
ogged=20
> <https://ngathanasiou.wordpress.com/2016/11/28/want-a-std-slice/>*about a=
=20
> hypothetical tuple slice functionality (and related design considerations=
)=20
> and it seems useful & simple enough (conceptually and implementation wise=
)=20
> to be added in isolation to the Standard library (it may just have been=
=20
> overlooked in previous versions, I couldn't find related proposals).
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 well as
on parameter packs, so in at least that sense, it is superior to a
library function that operates only on std::tuple.)
--=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/583F4A4F.7020708%40gmail.com.
.
Author: Nikos Athanasiou <n.g.athanasiou@gmail.com>
Date: Thu, 1 Dec 2016 00:19:03 +0200
Raw View
Please refer to the related material, the proposed function does not=20
operate only on std::tuple. It works on any type/entity that is a valid=20
argument to std::tuple_size and std::get (namely std::array and=20
std::pair) - the reason why it's bound to produce "tuple slices" is=20
described in section 3 "Design consideration". I'm by no means implying=20
this is superior to generalized slicing, but merely more simple and not=20
requiring a language extension (plus it feels like it plays well with=20
the existing tuple toolkit - it doesn't need to introduce extra machinery)
On 30/11/2016 11:53 =CE=BC=CE=BC, Matthew Woehlke wrote:
> 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 recently *b=
logged
>> <https://ngathanasiou.wordpress.com/2016/11/28/want-a-std-slice/>*about =
a
>> hypothetical tuple slice functionality (and related design consideration=
s)
>> and it seems useful & simple enough (conceptually and implementation wis=
e)
>> to be added in isolation to the Standard library (it may just have been
>> overlooked in previous versions, I couldn't find related proposals).
> 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 well as
> on parameter packs, so in at least that sense, it is superior to a
> library function that operates only on std::tuple.)
>
--=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/18998acd-2c2e-713b-29d2-4874400b35b7%40gmail.com=
..
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 30 Nov 2016 14:40:20 -0800 (PST)
Raw View
------=_Part_82_1460773536.1480545621070
Content-Type: multipart/alternative;
boundary="----=_Part_83_606739694.1480545621070"
------=_Part_83_606739694.1480545621070
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, November 30, 2016 at 5:19:13 PM UTC-5, =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=20
wrote:
>
> Please refer to the related material, the proposed function does not=20
> operate only on std::tuple. It works on any type/entity that is a valid=
=20
> argument to std::tuple_size and std::get (namely std::array and=20
> std::pair) - the reason why it's bound to produce "tuple slices" is=20
> described in section 3 "Design consideration". I'm by no means implying=
=20
> this is superior to generalized slicing, but merely more simple and not=
=20
> requiring a language extension (plus it feels like it plays well with=20
> the existing tuple toolkit - it doesn't need to introduce extra machinery=
)=20
>
But if we have a language feature like that, it can do what your=20
tuple-slice function does, plus plenty of other things. Like this:
std::make_tuple(some_func([I1:I2]product_type)...);
You can find ways to make that work with lambdas, function calls, and=20
various other things. But it will never be as easily understandable and=20
easy-to-use as that. Better to go for the language feature, so that tuple=
=20
manipulation can be used by novices, rather than reserving it for complex=
=20
metaprogramming libraries.
--=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/4fd0a3a2-5f0f-4c58-9184-d23827a802d4%40isocpp.or=
g.
------=_Part_83_606739694.1480545621070
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, November 30, 2016 at 5:19:13 PM UTC-5, =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:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">Please refer to the related material, the proposed function does not=
=20
<br>operate only on std::tuple. It works on any type/entity that is a valid=
=20
<br>argument to std::tuple_size and std::get (namely std::array and=20
<br>std::pair) - the reason why it's bound to produce "tuple slice=
s" is=20
<br>described in section 3 "Design consideration". I'm by no =
means implying=20
<br>this is superior to generalized slicing, but merely more simple and not=
=20
<br>requiring a language extension (plus it feels like it plays well with=
=20
<br>the existing tuple toolkit - it doesn't need to introduce extra mac=
hinery)
<br></blockquote><div><br>But if we have a language feature like that, it c=
an do what your tuple-slice function does, plus plenty of other things. Lik=
e this:<br><br><div style=3D"background-color: rgb(250, 250, 250); border-c=
olor: rgb(187, 187, 187); border-style: solid; border-width: 1px; overflow-=
wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div c=
lass=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">make_tup=
le</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">some_func</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">([</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">I1</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">I2</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">]</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">product_type</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">)...);</span></div></code></div><br>You can find ways to m=
ake that work with lambdas, function calls, and various other things. But i=
t will never be as easily understandable and easy-to-use as that. Better to=
go for the language feature, so that tuple manipulation can be used by nov=
ices, rather than reserving it for complex metaprogramming libraries.<br></=
div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4fd0a3a2-5f0f-4c58-9184-d23827a802d4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4fd0a3a2-5f0f-4c58-9184-d23827a802d4=
%40isocpp.org</a>.<br />
------=_Part_83_606739694.1480545621070--
------=_Part_82_1460773536.1480545621070--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 30 Nov 2016 23:41:14 +0100
Raw View
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 recently *b=
logged
>> <https://ngathanasiou.wordpress.com/2016/11/28/want-a-std-slice/>*about =
a
>> hypothetical tuple slice functionality (and related design consideration=
s)
>> and it seems useful & simple enough (conceptually and implementation wis=
e)
>> to be added in isolation to the Standard library (it may just have been
>> overlooked in previous versions, I couldn't find related proposals).
> 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 well 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 is=20
not yet clear to me how we would have the same syntax for ProductTypes=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 efficient,=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 have=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 view?
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/945de37f-352d-008f-a29b-d354999c6c4c%40wanadoo.f=
r.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 30 Nov 2016 16:23:11 -0800 (PST)
Raw View
------=_Part_83_1438348746.1480551791493
Content-Type: multipart/alternative;
boundary="----=_Part_84_91076247.1480551791494"
------=_Part_84_91076247.1480551791494
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, November 30, 2016 at 5:41:18 PM UTC-5, Vicente J. Botet=20
Escriba wrote:
>
> Le 30/11/2016 =C3=A0 22:53, Matthew Woehlke a =C3=A9crit :=20
> > 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:=20
> >> Just floating the idea before composing the complete text. I recently=
=20
> *blogged=20
> >> <https://ngathanasiou.wordpress.com/2016/11/28/want-a-std-slice/>*abou=
t=20
> a=20
> >> hypothetical tuple slice functionality (and related design=20
> considerations)=20
> >> and it seems useful & simple enough (conceptually and implementation=
=20
> wise)=20
> >> to be added in isolation to the Standard library (it may just have bee=
n=20
> >> overlooked in previous versions, I couldn't find related proposals).=
=20
> > If we had generalized slicing, would the proposed library function offe=
r=20
> > anything superior to `std::make_tuple([I1:I2]product_type...)`?=20
> >=20
> > (Generalized slicing would work both on *any* product type, as well as=
=20
> > on parameter packs, so in at least that sense, it is superior to a=20
> > library function that operates only on std::tuple.)=20
> >=20
> I agree that new algorithms should work on ProductTypes [P0327R1]. It is=
=20
> not yet clear to me how we would have the same syntax for ProductTypes=
=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.=20
>
> I believe it is worth defining algorithms that do whatever we want=20
> independently of the precise implementation and the possible language=20
> evolution.=20
>
> 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 efficient,=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 have=20
> neither a draft paper nor an implementation to show yet.=20
>
> What do you think of this suggested product type views?=20
>
> BTW, would slicing [I1,I2]pt... return a pack or a product type? Or a=20
> view?=20
>
It is none of those:
* `pt` is an expression that results in a "product type".
* `[:]pt` is a product type pack, which is behaviorally identical to a=20
parameter pack, save the fact that it unpacks into a sequence of=20
`get<i>(pt)` calls.
* `[I1:I2]pt` is a product type pack that goes from `get<I1>` to `get<I2>`,=
=20
rather than across the entire range of `pt`.
* `[I1:I2]pt...` unpacks the pack, which works exactly like unpacking a=20
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/e3a2acfe-dbb6-4f8f-84da-8debda38a4fc%40isocpp.or=
g.
------=_Part_84_91076247.1480551791494
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, November 30, 2016 at 5:41:18 PM UTC-=
5, Vicente J. Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">Le 30/11/2016 =C3=A0 22:53, Matthew Woehlke a =C3=A9crit :
<br>> 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:
<br>>> Just floating the idea before composing the complete text. I r=
ecently *blogged
<br>>> <<a href=3D"https://ngathanasiou.wordpress.com/2016/11/28/w=
ant-a-std-slice/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fngathanasiou.wordpr=
ess.com%2F2016%2F11%2F28%2Fwant-a-std-slice%2F\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNHKdHZP3i-sb9B8mj2zsgcFU8wugA';return true;" onclick=3D"this=
..href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fngathanasiou.wor=
dpress.com%2F2016%2F11%2F28%2Fwant-a-std-slice%2F\x26sa\x3dD\x26sntz\x3d1\x=
26usg\x3dAFQjCNHKdHZP3i-sb9B8mj2zsgcFU8wugA';return true;">https://ngat=
hanasiou.<wbr>wordpress.com/2016/11/28/want-<wbr>a-std-slice/</a>>*about=
a
<br>>> hypothetical tuple slice functionality (and related design con=
siderations)
<br>>> and it seems useful & simple enough (conceptually and impl=
ementation wise)
<br>>> to be added in isolation to the Standard library (it may just =
have been
<br>>> overlooked in previous versions, I couldn't find related p=
roposals).
<br>> If we had generalized slicing, would the proposed library function=
offer
<br>> anything superior to `std::make_tuple([I1:I2]<wbr>product_type...)=
`?
<br>>
<br>> (Generalized slicing would work both on *any* product type, as wel=
l as
<br>> on parameter packs, so in at least that sense, it is superior to a
<br>> library function that operates only on std::tuple.)
<br>>
<br>I agree that new algorithms should work on ProductTypes [P0327R1]. It i=
s=20
<br>not yet clear =C2=A0to me how we would have the same syntax for Product=
Types=20
<br>and parameter packs. I'm not saying that I'm against, just that=
we don't=20
<br>have yet a clear proposal for this common access. While this could be=
=20
<br>user friendly, it doesn't compose well in generic code.
<br>
<br>I believe it is worth defining algorithms that do whatever we want=20
<br>independently of the precise implementation and the possible language=
=20
<br>evolution.
<br>
<br>I'm considering defining some kind of ProductType views as we could=
have=20
<br>Range views. product_type::slice<I1,I2>(pt) could return a lazy=
=20
<br>product_type::slice_view<I1,<wbr>I2, PT>. This should be more eff=
icient,=20
<br>needs to store a reference to the ProductType instead to a reference to=
=20
<br>each one of the elements of the product type. Sorry, but I don't ha=
ve=20
<br>neither a draft paper nor an implementation to show yet.
<br>
<br>What do you think of this suggested product type views?
<br>
<br>BTW, would slicing [I1,I2]pt... return a pack or a product type? Or a v=
iew?
<br></blockquote><div><br>It is none of those:<br><br>* `pt` is an expressi=
on that results in a "product type".<br><br>* `[:]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.<br><br>* =
`[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`.<br><br>* `[I1:I2]pt=
....` unpacks the pack, which works exactly like unpacking a parameter pack.=
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e3a2acfe-dbb6-4f8f-84da-8debda38a4fc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e3a2acfe-dbb6-4f8f-84da-8debda38a4fc=
%40isocpp.org</a>.<br />
------=_Part_84_91076247.1480551791494--
------=_Part_83_1438348746.1480551791493--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Thu, 1 Dec 2016 13:02:03 -0500
Raw View
On 2016-11-30 17:41, Vicente J. Botet Escriba wrote:
> I agree that new algorithms should work on ProductTypes [P0327R1]. It is
> not yet clear to me how we would have the same syntax for ProductTypes
> and parameter packs.
As a language feature, I don't see the difficulty. The proposed syntax
is a unary operator, thus the generalized form is `<operator> <operand>`
(more specifically, `[<index-expression>]<operand>`, though that may be
subject to bikeshedding). There should be no problem for the compiler to
determine whether or not the operand is a parameter pack, and act
accordingly.
> While this could be user friendly, it doesn't compose well in generic
> code.
Can you elaborate?
> BTW, would slicing [I1,I2]pt... return a pack or a product type? Or a view?
Neither. See Nicol's reply for longer explanation.
If you want that as a product type, you could write e.g.
`make_tuple([I1:I2]pt...)`. You can also write things like:
template <int I1, int I2, typename VectorType>
auto partial_manhattan_distance(VectorType const& v)
{
using std::abs;
return decltype(vec){} + ... + abs([I1:I2]v);
}
This is one area where a language feature is superior. The other, of
course, is that it works on parameter packs also.
In my proposal (which I should probably post :-)), I present this as two
separate features that logically combine. First, I present *parameter
pack* slicing. A language feature is much more desirable for parameter
packs, because there are drawbacks to trying to do slicing as a library
feature (creation of temporary objects being the big one; some cases,
especially involving move-only types, can get *really* awkward trying to
use pure library features vs. a language feature). Second, I present
generalized unpacking, which turns a product type into a parameter pack
(without slicing), which is much more powerful than std::apply (e.g.
above example). However, I use the same syntax for both, such that
combining the two becomes "obvious"; it makes both features more
powerful and is less to learn (two features, only one syntax between them).
--
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/5840659B.7050003%40gmail.com.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 1 Dec 2016 23:25:06 +0100
Raw View
This is a multi-part message in MIME format.
--------------E96931727EE18E9157AA2AE1
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 01/12/2016 =C3=A0 01:23, Nicol Bolas a =C3=A9crit :
>
>
> On Wednesday, November 30, 2016 at 5:41:18 PM UTC-5, Vicente J. Botet=20
> 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
> recently *blogged
> >>
> <https://ngathanasiou.wordpress.com/2016/11/28/want-a-std-slice/
> <https://ngathanasiou.wordpress.com/2016/11/28/want-a-std-slice/>>*ab=
out
> a
> >> hypothetical tuple slice functionality (and related design
> considerations)
> >> and it seems useful & simple enough (conceptually and
> implementation wise)
> >> to be added in isolation to the Standard library (it may just
> have been
> >> overlooked in previous versions, I couldn't find related
> proposals).
> > 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
> well 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 is
> not yet clear to me how we would have the same syntax for
> ProductTypes
> and parameter packs. I'm not saying that I'm against, just that we
> don't
> have yet a clear proposal for this common access. While this could be
> user friendly, it doesn't compose well in generic code.
>
> I believe it is worth defining algorithms that do whatever we want
> independently of the precise implementation and the possible language
> evolution.
>
> I'm considering defining some kind of ProductType views as we
> could have
> Range views. product_type::slice<I1,I2>(pt) could return a lazy
> product_type::slice_view<I1,I2, PT>. This should be more efficient,
> needs to store a reference to the ProductType instead to a
> reference to
> each one of the elements of the product type. Sorry, but I don't have
> 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 view?
>
>
> It is none of those:
>
> * `pt` is an expression that results in a "product type".
>
> * `[:]pt` is a product type pack, which is behaviorally identical to a=20
> parameter pack, save the fact that it unpacks into a sequence of=20
> `get<i>(pt)` calls.
>
> * `[I1:I2]pt` is a product type pack that goes from `get<I1>` to=20
> `get<I2>`, rather than across the entire range of `pt`.
>
> * `[I1:I2]pt...` unpacks the pack, which works exactly like unpacking=20
> a parameter pack.
Sorry, I was thinking on
P0341R0=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0341r0.html>=20
parameter packs outside of templates
where the operator ... can be overloaded for UDT.
And then [I1:I2] taken a slice of the pack expansion, possibly=20
resulting in a product-type again ;-)
I was surely mixing conflicting proposals.
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/db477ff7-beb6-e2de-d4ca-6a3c6a313da5%40wanadoo.f=
r.
--------------E96931727EE18E9157AA2AE1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 01/12/2016 =C3=A0 01:23, Nicol Bolas =
a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:e3a2acfe-dbb6-4f8f-84da-8debda38a4fc@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
<br>
On Wednesday, November 30, 2016 at 5:41:18 PM UTC-5, Vicente J.
Botet Escriba wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Le
30/11/2016 =C3=A0 22:53, Matthew Woehlke a =C3=A9crit :
<br>
> 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:
<br>
>> Just floating the idea before composing the complete
text. I recently *blogged
<br>
>> <<a moz-do-not-send=3D"true"
href=3D"https://ngathanasiou.wordpress.com/2016/11/28/want-a-st=
d-slice/"
target=3D"_blank" rel=3D"nofollow"
onmousedown=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fn=
gathanasiou.wordpress.com%2F2016%2F11%2F28%2Fwant-a-std-slice%2F\x26sa\x3dD=
\x26sntz\x3d1\x26usg\x3dAFQjCNHKdHZP3i-sb9B8mj2zsgcFU8wugA';return
true;"
onclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fngath=
anasiou.wordpress.com%2F2016%2F11%2F28%2Fwant-a-std-slice%2F\x26sa\x3dD\x26=
sntz\x3d1\x26usg\x3dAFQjCNHKdHZP3i-sb9B8mj2zsgcFU8wugA';return
true;">https://ngathanasiou.<wbr>wordpress.com/2016/11/28/want-=
<wbr>a-std-slice/</a>>*about
a
<br>
>> hypothetical tuple slice functionality (and related
design considerations)
<br>
>> and it seems useful & simple enough (conceptually
and implementation wise)
<br>
>> to be added in isolation to the Standard library (it
may just have been
<br>
>> overlooked in previous versions, I couldn't find
related proposals).
<br>
> If we had generalized slicing, would the proposed library
function offer
<br>
> anything superior to `std::make_tuple([I1:I2]<wbr>product_ty=
pe...)`?
<br>
>
<br>
> (Generalized slicing would work both on *any* product
type, as well as
<br>
> on parameter packs, so in at least that sense, it is
superior to a
<br>
> library function that operates only on std::tuple.)
<br>
>
<br>
I agree that new algorithms should work on ProductTypes
[P0327R1]. It is <br>
not yet clear =C2=A0to me how we would have the same syntax for
ProductTypes <br>
and parameter packs. I'm not saying that I'm against, just
that we don't <br>
have yet a clear proposal for this common access. While this
could be <br>
user friendly, it doesn't compose well in generic code.
<br>
<br>
I believe it is worth defining algorithms that do whatever we
want <br>
independently of the precise implementation and the possible
language <br>
evolution.
<br>
<br>
I'm considering defining some kind of ProductType views as we
could have <br>
Range views. product_type::slice<I1,I2>(pt) could return
a lazy <br>
product_type::slice_view<I1,<wbr>I2, PT>. This should be
more efficient, <br>
needs to store a reference to the ProductType instead to a
reference to <br>
each one of the elements of the product type. Sorry, but I
don't have <br>
neither a draft paper nor an implementation to show yet.
<br>
<br>
What do you think of this suggested product type views?
<br>
<br>
BTW, would slicing [I1,I2]pt... return a pack or a product
type? Or a view?
<br>
</blockquote>
<div><br>
It is none of those:<br>
<br>
* `pt` is an expression that results in a "product type".<br>
<br>
* `[:]pt` is a product type pack, which is behaviorally
identical to a parameter pack, save the fact that it unpacks
into a sequence of `get<i>(pt)` calls.<br>
<br>
* `[I1:I2]pt` is a product type pack that goes from
`get<I1>` to `get<I2>`, rather than across the
entire range of `pt`.<br>
<br>
* `[I1:I2]pt...` unpacks the pack, which works exactly like
unpacking a parameter pack.</div>
</div>
</blockquote>
<br>
Sorry, I was thinking on
<meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8=
">
<table border=3D"1">
<tbody>
<tr>
<td><a
href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0341r0.htm=
l">P0341R0</a>
</td>
<td> parameter packs outside of templates</td>
</tr>
</tbody>
</table>
<br>
where the operator ... can be overloaded for UDT.<br>
<br>
And then [I1:I2] taken a slice of=C2=A0 the pack expansion, possibly
resulting in a product-type again ;-)<br>
<br>
I was surely mixing conflicting proposals.<br>
<br>
Vicente<br>
<br>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/db477ff7-beb6-e2de-d4ca-6a3c6a313da5%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/db477ff7-beb6-e2de-d4ca-6a3c6a313da5=
%40wanadoo.fr</a>.<br />
--------------E96931727EE18E9157AA2AE1--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Fri, 2 Dec 2016 00:00:01 +0100
Raw View
This is a multi-part message in MIME format.
--------------AB37B4E37810C129C83207E8
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 01/12/2016 =C3=A0 19:02, Matthew Woehlke a =C3=A9crit :
> On 2016-11-30 17:41, Vicente J. Botet Escriba wrote:
>> I agree that new algorithms should work on ProductTypes [P0327R1]. It is
>> not yet clear to me how we would have the same syntax for ProductTypes
>> and parameter packs.
> As a language feature, I don't see the difficulty. The proposed syntax
> is a unary operator, thus the generalized form is `<operator> <operand>`
> (more specifically, `[<index-expression>]<operand>`, though that may be
> subject to bikeshedding). There should be no problem for the compiler to
> determine whether or not the operand is a parameter pack, and act
> accordingly.
See my other post. There are several proposal (P0341R0=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0341r0.html>).
>
>> While this could be user friendly, it doesn't compose well in generic
>> code.
> Can you elaborate?
What I meant is that some times we need HOF (e.g. pipe composition), and=20
the friendly [I:J] syntax wouldn't provide it, isn't it?
auto x =3D pt | slice<I,J> | filter(cnd) | transform(fct);
>
>> BTW, would slicing [I1,I2]pt... return a pack or a product type? Or a vi=
ew?
> Neither. See Nicol's reply for longer explanation.
>
> If you want that as a product type, you could write e.g.
> `make_tuple([I1:I2]pt...)`.
Now that I'm re-reading myself, my question was more on what is the type=20
of [I1,I2]pt. But you have already responded to this question now.
Then I would prefer make_slice<I1,I2>(pt) in my production code and let=20
the implementation to provide the best implementation.
> You can also write things like:
>
> template <int I1, int I2, typename VectorType>
> auto partial_manhattan_distance(VectorType const& v)
> {
> using std::abs;
> return decltype(vec){} + ... + abs([I1:I2]v);
> }
Could you expand? What will be the result of this expression with a=20
concrete example?
Is abs variadic? What are we expanding on the fold expression?
> This is one area where a language feature is superior. The other, of
> course, is that it works on parameter packs also.
So you are saying that an slice on a product type is a parameter pack=20
and a slice of a parameter pack is also a parameter pack, isn't it?
I would find more logical that an slice on a ProductType is a=20
ProductType whenever possible.
>
> In my proposal (which I should probably post :-)), I present this as two
> separate features that logically combine. First, I present *parameter
> pack* slicing. A language feature is much more desirable for parameter
> packs, because there are drawbacks to trying to do slicing as a library
> feature (creation of temporary objects being the big one; some cases,
> especially involving move-only types, can get *really* awkward trying to
> use pure library features vs. a language feature).
I'm all for this feature.
> Second, I present
> generalized unpacking, which turns a product type into a parameter pack
> (without slicing), which is much more powerful than std::apply (e.g.
> above example). However, I use the same syntax for both, such that
> combining the two becomes "obvious"; it makes both features more
> powerful and is less to learn (two features, only one syntax between them=
).
>
I'm all for unpacking a product type. An even unpacking and then slicing.
What the OP was proposing was to slice a product type and get another=20
product type, not a parameter pack.
As I said the implementation is not important. What is important is the=20
function specification, and the function can not return a parameter=20
pack, at least I have not seen any proposal that will allow to return=20
parameter packs. P0341R0=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0341r0.html>=20
talks about literal pack types, but they are IMO closer to product types=20
than to parameter packs.
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/fbfba60b-f7a7-2a41-6e09-0cbe7e6378c0%40wanadoo.f=
r.
--------------AB37B4E37810C129C83207E8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 01/12/2016 =C3=A0 19:02, Matthew Woeh=
lke
a =C3=A9crit=C2=A0:<br>
</div>
<blockquote cite=3D"mid:5840659B.7050003@gmail.com" type=3D"cite">
<pre wrap=3D"">On 2016-11-30 17:41, Vicente J. Botet Escriba wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">I agree that new algorithms should work on ProductTy=
pes [P0327R1]. It is
not yet clear to me how we would have the same syntax for ProductTypes
and parameter packs.
</pre>
</blockquote>
<pre wrap=3D"">
As a language feature, I don't see the difficulty. The proposed syntax
is a unary operator, thus the generalized form is `<operator> <ope=
rand>`
(more specifically, `[<index-expression>]<operand>`, though tha=
t may be
subject to bikeshedding). There should be no problem for the compiler to
determine whether or not the operand is a parameter pack, and act
accordingly.</pre>
</blockquote>
See my other post. There are several proposal (<a
href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0341r0.htm=
l">P0341R0</a>).<br>
<blockquote cite=3D"mid:5840659B.7050003@gmail.com" type=3D"cite">
<pre wrap=3D"">
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">While this could be user friendly, it doesn't compos=
e well in generic
code.
</pre>
</blockquote>
<pre wrap=3D"">
Can you elaborate?</pre>
</blockquote>
What I meant is that some times we need HOF (e.g. pipe composition),
and the friendly [I:J] syntax wouldn't provide it, isn't it?<br>
<br>
auto x =3D pt | slice<I,J> | filter(cnd) | transform(fct);<br>
<blockquote cite=3D"mid:5840659B.7050003@gmail.com" type=3D"cite">
<pre wrap=3D"">
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">BTW, would slicing [I1,I2]pt... return a pack or a p=
roduct type? Or a view?
</pre>
</blockquote>
<pre wrap=3D"">
Neither. See Nicol's reply for longer explanation.
If you want that as a product type, you could write e.g.
`make_tuple([I1:I2]pt...)`. </pre>
</blockquote>
Now that I'm re-reading myself, my question was more on what is the
type of [I1,I2]pt. But you have already responded to this question
now.<br>
<br>
Then I would prefer make_slice<I1,I2>(pt) in my production
code=C2=A0 and let the implementation to provide the best implementatio=
n.<br>
<blockquote cite=3D"mid:5840659B.7050003@gmail.com" type=3D"cite">
<pre wrap=3D"">You can also write things like:
template <int I1, int I2, typename VectorType>
auto partial_manhattan_distance(VectorType const& v)
{
using std::abs;
return decltype(vec){} + ... + abs([I1:I2]v);
}
</pre>
</blockquote>
Could you expand? What will be the result of this expression with a
concrete example?<br>
Is abs variadic? What are we expanding on the fold expression?<br>
<blockquote cite=3D"mid:5840659B.7050003@gmail.com" type=3D"cite">
<pre wrap=3D"">
This is one area where a language feature is superior. The other, of
course, is that it works on parameter packs also.</pre>
</blockquote>
So you are saying that an slice on a product type is a parameter
pack and a slice of a parameter pack is also a parameter pack, isn't
it?<br>
<br>
I would find more logical that an slice on a ProductType is a
ProductType whenever possible.<br>
<blockquote cite=3D"mid:5840659B.7050003@gmail.com" type=3D"cite">
<pre wrap=3D"">
In my proposal (which I should probably post :-)), I present this as two
separate features that logically combine. First, I present *parameter
pack* slicing. A language feature is much more desirable for parameter
packs, because there are drawbacks to trying to do slicing as a library
feature (creation of temporary objects being the big one; some cases,
especially involving move-only types, can get *really* awkward trying to
use pure library features vs. a language feature). </pre>
</blockquote>
I'm all for this feature.<br>
<blockquote cite=3D"mid:5840659B.7050003@gmail.com" type=3D"cite">
<pre wrap=3D"">Second, I present
generalized unpacking, which turns a product type into a parameter pack
(without slicing), which is much more powerful than std::apply (e.g.
above example). However, I use the same syntax for both, such that
combining the two becomes "obvious"; it makes both features more
powerful and is less to learn (two features, only one syntax between them).
</pre>
</blockquote>
<p>I'm all for unpacking a product type. An even unpacking and then
slicing.</p>
<p>What the OP was proposing was to slice a product type and get
another product type, not a parameter pack.</p>
<p>As I said the implementation is not important. What is important
is the function specification, and the function can not return a
parameter pack, at least I have not seen any proposal that will
allow to return parameter packs. <a
href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0341r0.htm=
l">P0341R0</a>=C2=A0
talks about literal pack types, but they are IMO closer to product
types than to parameter packs.<br>
</p>
<p><br>
</p>
<p>Vicente<br>
</p>
<p><br>
</p>
<p><br>
</p>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fbfba60b-f7a7-2a41-6e09-0cbe7e6378c0%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fbfba60b-f7a7-2a41-6e09-0cbe7e6378c0=
%40wanadoo.fr</a>.<br />
--------------AB37B4E37810C129C83207E8--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Fri, 2 Dec 2016 10:53:59 -0500
Raw View
On 2016-12-01 18:00, Vicente J. Botet Escriba wrote:
> Le 01/12/2016 =C3=A0 19:02, Matthew Woehlke a =C3=A9crit :
>> On 2016-11-30 17:41, Vicente J. Botet Escriba wrote:
>>> While this could be user friendly, it doesn't compose well in generic
>>> code.
>>
>> Can you elaborate?
>
> What I meant is that some times we need HOF (e.g. pipe composition), and
> the friendly [I:J] syntax wouldn't provide it, isn't it?
Sorry, what is "HOF"?
> auto x =3D pt | slice<I,J> | filter(cnd) | transform(fct);
Ah... I guess you could do this with a library function. It would be
trivial to write your own with the proposed language feature, though:
template <int I1, int I2, typename T>
auto slice(T const& t) { return std::make_tuple([I1:I2]t); }
> Now that I'm re-reading myself, my question was more on what is the type
> of [I1,I2]pt. But you have already responded to this question now.
>=20
> Then I would prefer make_slice<I1,I2>(pt) in my production code and let
> the implementation to provide the best implementation.
How would that work?
The "type" of `[l:u]pt` is a parameter pack. If you need it as a
concrete type, you can wrap a constructor for *whatever* concrete type
is desired around it. A library function would necessarily dictate the
type, e.g. std::tuple. The language feature is strictly *more* powerful,
even ignoring the ability to employ *arbitrary* fold expressions.
The implementation is not free to make an optimal choice in this matter;
it is constrained by the API.
>> You can also write things like:
>>
>> template <int I1, int I2, typename VectorType>
>> auto partial_manhattan_distance(VectorType const& v)
>> {
>> using std::abs;
>> return decltype(vec){} + ... + abs([I1:I2]v);
>> }
Arf... just realized, the `decltype(vec){}` is nonsense (intended to be
a zero-element, but obtaining that is actually rather convoluted and
subject to some icky corner cases...). Ignoring that for the remainder
of my reply...
In fact, a better expression is:
template <int I1, int I2, typename VectorType>
auto partial_manhattan_distance(VectorType const& v)
{
using std::abs;
if constexpr (sizeof...([I1:I2]v))
return abs([I1:I2]v) + ...;
else
// here be dragons
}
> Could you expand? What will be the result of this expression with a
> concrete example?
The result type depends on the inputs, as it should. To employ a
particularly esoteric - but still valid - example, consider:
auto t =3D tuple<double, int, complex<int>, double, char>{
1.5, -3, {3, -4}, 2.0, 'a' };
auto d =3D partial_manhattan_distance<1,99>(t);
// d has type double, value 107
(Normally you would use such a function on a product type of homogeneous
types, e.g. an array, but so long as the addition operations and calls
to `abs` are well formed...)
> Is abs variadic? What are we expanding on the fold expression?
No; in the above example, the expression expands to (types elided):
abs(-3) + abs({3, 4}) + abs(2.0) + abs('a');
....as it would for any parameter pack.
> So you are saying that an slice on a product type is a parameter pack
> and a slice of a parameter pack is also a parameter pack, isn't it?
Exactly.
> I would find more logical that an slice on a ProductType is a
> ProductType whenever possible.
No. First, because you then run afoul of trying to solve *what* product
type it should be (very hard), and second because it defeats the entire
purpose, which is *generalized unpacking*.
Again, the intent is a) to unpack product types into a parameter packs,
and b) to be able to slice *parameter packs*. They are combined because
IMO it makes more sense than to combine them than to not combine them.
IOW:
[:]pt -> unpack product type
[l:u]([:]pt) -> slice product type
[l:u]pt -> combine redundant syntax
(Also, the latter may be slightly more optimization friendly, since it's
obvious that the compiler never needs to generate get<> for the
untouched elements.)
> What the OP was proposing was to slice a product type and get another
> product type, not a parameter pack.
....and you can do that by wrapping the slice in a product type ctor,
which avoids the hard problem of solving (or enforcing) *what* product
type is returned.
Consider:
struct Foo { int a; int b; string c; double d; };
auto bar =3D make_slice<1,3>(Foo{...});
....what is the type of `bar`? It can't be a Foo, for obvious reasons,
and it can't be e.g. a std::array... but if we slice a std::array, we
would want a std::array back, wouldn't we? What about slicing an
Eigen::Vector4d; will make_slice give back an Eigen::Vector#d of
appropriate `#`? The OP's proposal either has to always return e.g.
std::tuple, or solve the complicated problem of picking an "appropriate"
type based on the input. In either case, it is likely that the decision
will be wrong for someone, somewhere. Producing a parameter pack avoids
this by deferring the problem to the user at point of use, where likely
the user *knows* what type is desired.
> P0341R0
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0341r0.html>
> talks about literal pack types, but they are IMO closer to product types
> than to parameter packs.
Somewhat off topic, but P0341R0 seems like a worse version of P0222R0
:-). (Well, the relevant part of it, anyway.)
--=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/58419917.8000105%40gmail.com.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 2 Dec 2016 18:07:51 +0200
Raw View
On 2 December 2016 at 17:53, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
>> What I meant is that some times we need HOF (e.g. pipe composition), and
>> the friendly [I:J] syntax wouldn't provide it, isn't it?
>
> Sorry, what is "HOF"?
https://en.wikipedia.org/wiki/Higher-order_function
--
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/CAFk2RUZQOhiEKTqoHgp3aDOGZ3H9XGrb3puz40%2B%2BPKOa5iF-ZQ%40mail.gmail.com.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Mon, 5 Dec 2016 22:21:42 +0100
Raw View
Le 02/12/2016 =C3=A0 16:53, Matthew Woehlke a =C3=A9crit :
> On 2016-12-01 18:00, Vicente J. Botet Escriba wrote:
>> Le 01/12/2016 =C3=A0 19:02, Matthew Woehlke a =C3=A9crit :
>>> On 2016-11-30 17:41, Vicente J. Botet Escriba wrote:
>>>> While this could be user friendly, it doesn't compose well in generic
>>>> code.
>>> Can you elaborate?
>> What I meant is that some times we need HOF (e.g. pipe composition), and
>> the friendly [I:J] syntax wouldn't provide it, isn't it?
> Sorry, what is "HOF"?
>
>> auto x =3D pt | slice<I,J> | filter(cnd) | transform(fct);
> Ah... I guess you could do this with a library function. It would be
> trivial to write your own with the proposed language feature, though:
>
> template <int I1, int I2, typename T>
> auto slice(T const& t) { return std::make_tuple([I1:I2]t); }
You need an additional indirection as slice has no template parameter T,=20
but yes we can define them using a language feature, but this is an=20
implementation detail.
Note that the result of slice could be view on a product type and so=20
there is no need to copy on another product type as std::tuple.
I don't think we want each user to define them as it is not so simple.=20
See range-v3.
>> Now that I'm re-reading myself, my question was more on what is the type
>> of [I1,I2]pt. But you have already responded to this question now.
>>
>> Then I would prefer make_slice<I1,I2>(pt) in my production code and let
>> the implementation to provide the best implementation.
> How would that work?
>
> The "type" of `[l:u]pt` is a parameter pack. If you need it as a
> concrete type, you can wrap a constructor for *whatever* concrete type
> is desired around it. A library function would necessarily dictate the
> type, e.g. std::tuple.
It could be an optional parameter(see below) :)
> The language feature is strictly *more* powerful,
> even ignoring the ability to employ *arbitrary* fold expressions.
>
> The implementation is not free to make an optimal choice in this matter;
> it is constrained by the API.
>
>>> You can also write things like:
>>>
>>> template <int I1, int I2, typename VectorType>
>>> auto partial_manhattan_distance(VectorType const& v)
>>> {
>>> using std::abs;
>>> return decltype(vec){} + ... + abs([I1:I2]v);
>>> }
> Arf... just realized, the `decltype(vec){}` is nonsense (intended to be
> a zero-element, but obtaining that is actually rather convoluted and
> subject to some icky corner cases...). Ignoring that for the remainder
> of my reply...
I see now where it was done the expansion.
> In fact, a better expression is:
>
> template <int I1, int I2, typename VectorType>
> auto partial_manhattan_distance(VectorType const& v)
> {
> using std::abs;
> if constexpr (sizeof...([I1:I2]v))
> return abs([I1:I2]v) + ...;
> else
> // here be dragons
> }
v | stride<I1,I2> | accumulate
The goal been that the previous expression is as efficient as if it was=20
hand written using whatever feature in the language.
I we cannot do that, there is something wrong on the ability to make=20
high abstractions.
>
>> I would find more logical that an slice on a ProductType is a
>> ProductType whenever possible.
> No. First, because you then run afoul of trying to solve *what* product
> type it should be (very hard), and second because it defeats the entire
> purpose, which is *generalized unpacking*.
>
> Again, the intent is a) to unpack product types into a parameter packs,
> and b) to be able to slice *parameter packs*. They are combined because
> IMO it makes more sense than to combine them than to not combine them.
>
> IOW:
>
> [:]pt -> unpack product type
> [l:u]([:]pt) -> slice product type
> [l:u]pt -> combine redundant syntax
>
> (Also, the latter may be slightly more optimization friendly, since it's
> obvious that the compiler never needs to generate get<> for the
> untouched elements.)
I'll need to check once we have a compiler providing the feature ;-)
>> What the OP was proposing was to slice a product type and get another
>> product type, not a parameter pack.
> ...and you can do that by wrapping the slice in a product type ctor,
> which avoids the hard problem of solving (or enforcing) *what* product
> type is returned.
>
> Consider:
>
> struct Foo { int a; int b; string c; double d; };
> auto bar =3D make_slice<1,3>(Foo{...});
>
> ...what is the type of `bar`?
Compile error.
auto bar =3D make_slice<1,3, std::tuple>(Foo{...});
The result is a tuple here.
The same applies to transform a product type
auto bar =3D pt::transform<std::tuple>(Foo{...}, NFct);
When the product type is a template as tuple, pair
auto bar =3D transform(aTuple, NFct);
the result is a tuple, pair.
The same could apply to std::array.
> It can't be a Foo, for obvious reasons,
> and it can't be e.g. a std::array... but if we slice a std::array, we
> would want a std::array back, wouldn't we? What about slicing an
> Eigen::Vector4d; will make_slice give back an Eigen::Vector#d of
> appropriate `#`? The OP's proposal either has to always return e.g.
> std::tuple, or solve the complicated problem of picking an "appropriate"
> type based on the input. In either case, it is likely that the decision
> will be wrong for someone, somewhere. Producing a parameter pack avoids
> this by deferring the problem to the user at point of use, where likely
> the user *knows* what type is desired.
Maybe you are right. The problem I see is that functions cannot return=20
parameter packs as them are no types and so this makes composition more=20
difficult.
>
>> P0341R0
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0341r0.html>
>> talks about literal pack types, but they are IMO closer to product types
>> than to parameter packs.
> Somewhat off topic, but P0341R0 seems like a worse version of P0222R0
> :-). (Well, the relevant part of it, anyway.)
>
I like P0341 mainly on how it transforms a parameter pack on a pack type=20
that we can return from a function. I believe it is essential to have a=20
type associated to an aggregate expression.
There are parts that are yet on a draft more in this proposal so I can=20
not comment yet.
Up to you to elaborate on a comparison of both proposals.
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/b6286db3-251a-d59e-acf7-f5b1daa624bd%40wanadoo.f=
r.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Thu, 8 Dec 2016 12:52:45 -0500
Raw View
On 2016-12-05 16:21, Vicente J. Botet Escriba wrote:
> Maybe you are right. The problem I see is that functions cannot return
> parameter packs as them are no types and so this makes composition more
> difficult.
Yes, I can see where composition might make it desirable to have a
library feature in addition. This seems similar to the case where the
proposed feature does not entirely obviate the need for std::apply; it
just means that 90% of the time you will use the language feature, and
in some corner cases you will still use std::apply.
--
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/58499DED.3010506%40gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 8 Dec 2016 14:46:54 -0800 (PST)
Raw View
------=_Part_371_1638032783.1481237214665
Content-Type: multipart/alternative;
boundary="----=_Part_372_2044462109.1481237214665"
------=_Part_372_2044462109.1481237214665
Content-Type: text/plain; charset=UTF-8
On Thursday, December 8, 2016 at 12:52:48 PM UTC-5, Matthew Woehlke wrote:
>
> On 2016-12-05 16:21, Vicente J. Botet Escriba wrote:
> > Maybe you are right. The problem I see is that functions cannot return
> > parameter packs as them are no types and so this makes composition more
> > difficult.
>
> Yes, I can see where composition might make it desirable to have a
> library feature in addition. This seems similar to the case where the
> proposed feature does not entirely obviate the need for std::apply; it
> just means that 90% of the time you will use the language feature, and
> in some corner cases you will still use std::apply.
>
I don't think I'd use the library feature ever. Better to just use `return
tuple{[I1:I2]tpl...};`.
--
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/54f08727-b6f2-4d8f-9de9-e40d87ecc2cd%40isocpp.org.
------=_Part_372_2044462109.1481237214665
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, December 8, 2016 at 12:52:48 PM UTC-5=
, Matthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 201=
6-12-05 16:21, Vicente J. Botet Escriba wrote:
<br>> Maybe you are right. The problem I see is that functions cannot re=
turn
<br>> parameter packs as them are no types and so this makes composition=
more
<br>> difficult.
<br>
<br>Yes, I can see where composition might make it desirable to have a
<br>library feature in addition. This seems similar to the case where the
<br>proposed feature does not entirely obviate the need for std::apply; it
<br>just means that 90% of the time you will use the language feature, and
<br>in some corner cases you will still use std::apply.<br></blockquote><di=
v><br>I don't think I'd use the library feature ever. Better to jus=
t use `return tuple{[I1:I2]tpl...};`.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/54f08727-b6f2-4d8f-9de9-e40d87ecc2cd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/54f08727-b6f2-4d8f-9de9-e40d87ecc2cd=
%40isocpp.org</a>.<br />
------=_Part_372_2044462109.1481237214665--
------=_Part_371_1638032783.1481237214665--
.