------=_Part_110_16973475.1369272910802
Content-Type: text/plain; charset=ISO-8859-1

Hello,

With the arrival of dynarray, it will now be preferable to use this new
container instead of vector in some situations. One problem is that
currently, considering functions taking vectors as parameters and/or
returning vectors, should these have overloads created to support
taking/returning dynarray as well? Let's see how we could support both
vectors and dynarrays while avoiding duplicates of all those functions.
(note that the same question could be asked regarding std::array but let's
ignore it for now)

Note that concepts will sometimes be a viable solution to this problem.
However, concepts will not always be a possible solution; think about
virtual functions for example. One could not define a template virtual
function (even if constrained by concepts).

We know that it would not make sense to provide a move constructor for
dynarray (moving a dynarray in a dynarray). This is because the dynarray
being moved could have its data located on the stack (we can never be sure,
when receiving a dynarray as a parameter, if it is holding its data on the
stack or on the heap).

However, a vector always has its data on the heap. Well, I know that's not
entirely true because it depends on the allocator (an allocator doesn't
necessarily use the heap), but nevertheless a vector can always be moved.
So why not add a dynarray constructor that would take a rvalue vector as an
argument?

Technically, this should be possible since both containers store data
contiguously.

// Suppose there is a function returning a vector
vector<T> GetElems(/*...*/) { /*...*/ }

// The returned vector could then be stored in a dynarray
dynarray<T> Elems{GetElems()};

The thing is that returning a dynarray from a function is not a really good
idea since it cannot be moved (I know that the not-movable aspect of
dynarray is a bit controversial but my goal is not to debate about it;
let's just assume this will not change). So returning vectors remain the
best option. But sometimes it could be better to move the returned vector
in a dynarray:
- Because sometimes it could actually make more sense (conceptually) to
hold a dynarray rather than a vector (if the container may not be resized)
- Functions taking dynarray as a parameter could then be used

One thing that would not be entirely solved by this approach would be the
ability to pass a vector to a function expecting a dynarray as a parameter.
Well, with the proposed approach it would work if you move the vector but
there would be no way to move back the dynarray to a vector back again. So
this approach is not sufficient and ideas would be welcome.

What I would ideally like to achieve is to have the following policy work:
- When returning, use vector (not dynarray) --> the returned vector could
be moved to a dynarray if needed
- When defining function parameter, use dynarray (not vector) --> the
argument could be a vector "interpreted" as a dynarray

What I'm asking myself is what would be the best way to interpret/cast a
vector to a dynarray (and that dynarray should not "own" the data; just
refer to it). Any ideas? Note that std::array could as well be considered.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_110_16973475.1369272910802
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,<div><br></div><div>With the arrival of dynarray, it will now be pref=
erable to use this new container instead of vector in some situations. One =
problem is that currently, considering functions taking vectors as paramete=
rs and/or returning vectors, should these have overloads created to support=
 taking/returning dynarray as well? Let's see how we could support both vec=
tors and dynarrays while avoiding duplicates of all those functions. (note =
that the same question could be asked regarding std::array but let's ignore=
 it for now)</div><div><br></div><div>Note that concepts will sometimes be =
a viable solution to this problem. However, concepts will not always be a p=
ossible solution; think about virtual functions for example. One could not =
define a template virtual function (even if constrained by concepts).</div>=
<div><br></div><div>We know that it would not make sense to provide a move =
constructor for dynarray (moving a dynarray in a dynarray). This is because=
 the dynarray being moved could have its data located on the stack (we can =
never be sure, when receiving a dynarray as a parameter, if it is holding i=
ts data on the stack or on the heap).</div><div><br></div><div>However, a v=
ector always has its data on the heap. Well, I know that's not entirely tru=
e because it depends on the allocator (an allocator doesn't necessarily use=
 the heap), but nevertheless a vector can always be moved. So why not add a=
 dynarray constructor that would take a rvalue vector as an argument?</div>=
<div><br></div><div>Technically, this should be possible since both contain=
ers store data contiguously.</div><div><br></div><div style=3D"background-c=
olor: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: =
break-word; " class=3D"prettyprint"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #800;" class=3D"styled-by-prettif=
y">// Suppose there is a function returning a vector</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>vector</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-b=
y-prettify">GetElems</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #800;" class=3D"styled-by-prettify"=
>/*...*/</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #800;" class=3D"styled-by-prettify">/*...*/</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br><br></span><span style=3D"color: #800;" class=3D"style=
d-by-prettify">// The returned vector could then be stored in a dynarray</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>dynarray<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
06;" class=3D"styled-by-prettify">Elems</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">{</span><span style=3D"color: #606;" class=3D"=
styled-by-prettify">GetElems</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">()};</span></div></code></div><div><br></div><div>The thi=
ng is that returning a dynarray from a function is not a really good idea s=
ince it cannot be moved (I know that the not-movable aspect of dynarray is =
a bit controversial but my goal is not to debate about it; let's just assum=
e this will not change). So returning vectors remain the best option. But s=
ometimes it could be better to move the returned vector in a dynarray:</div=
><div>- Because sometimes it could actually make more sense (conceptually) =
to hold a dynarray rather than a vector (if the container may not be resize=
d)</div><div>- Functions taking dynarray as a parameter could then be used<=
/div><div><br></div><div>One thing that would not be entirely solved by thi=
s approach would be the ability to pass a vector to a function expecting a =
dynarray as a parameter. Well, with the proposed approach it would work if =
you move the vector but there would be no way to move back the dynarray to =
a vector back again. So this approach is not sufficient and ideas would be =
welcome.</div><div><br></div><div>What I would ideally like to achieve is t=
o have the following policy work:</div><div>- When returning, use vector (n=
ot dynarray) --&gt; the returned vector could be moved to a dynarray if nee=
ded</div><div>- When defining function parameter, use dynarray (not vector)=
 --&gt; the argument could be a vector "interpreted" as a dynarray</div><di=
v><br></div><div>What I'm asking myself is what would be the best way to in=
terpret/cast a vector to a dynarray (and that dynarray should not "own" the=
 data; just refer to it). Any ideas? Note that std::array could as well be =
considered.</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_110_16973475.1369272910802--

.

------=_Part_336_23065682.1369295834300
Content-Type: text/plain; charset=ISO-8859-1

On Wednesday, May 22, 2013 6:35:10 PM UTC-7, Alex B wrote:
>
> What I'm asking myself is what would be the best way to interpret/cast a
> vector to a dynarray (and that dynarray should not "own" the data; just
> refer to it). Any ideas? Note that std::array could as well be considered.
>

The "best way" to do this would have been for the committee to accept the
`array_ref` proposal. However, in their "wisdom", they did not. They
believed that the range study group would come up with something similar in
their development of ranges, so they didn't feel it was important.

So just write one yourself. It'll only take you 5 minutes or so.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_336_23065682.1369295834300
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wednesday, May 22, 2013 6:35:10 PM UTC-7, Alex B wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div>What I'm asking myself is what would be th=
e best way to interpret/cast a vector to a dynarray (and that dynarray shou=
ld not "own" the data; just refer to it). Any ideas? Note that std::array c=
ould as well be considered.</div></blockquote><div><br>The "best way" to do=
 this would have been for the committee to accept the `array_ref` proposal.=
 However, in their "wisdom", they did not. They believed that the range stu=
dy group would come up with something similar in their development of range=
s, so they didn't feel it was important.<br><br>So just write one yourself.=
 It'll only take you 5 minutes or so.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_336_23065682.1369295834300--

.

2013/5/23 Nicol Bolas <jmckesson@gmail.com>:
> On Wednesday, May 22, 2013 6:35:10 PM UTC-7, Alex B wrote:
>>
>> What I'm asking myself is what would be the best way to interpret/cast a
>> vector to a dynarray (and that dynarray should not "own" the data; just
>> refer to it). Any ideas? Note that std::array could as well be considered.

Personally I'm strongly against mixing this kind of ownership
responsibilities for fundamental types like std::array and
std::dynarray. I think it is very important that a user can rely on
that copies of std::(dyn)array will *always* be independent. This kind
of abstraction should IMO be moved to a separate thingee and Nicol's
reference to array_ref looks exactly right to me.

> The "best way" to do this would have been for the committee to accept the
> `array_ref` proposal. However, in their "wisdom", they did not.

I cannot judge whether it would have been wise to accept the array_ref
proposal *as written*, but I can say the following for sure: It is
sometimes better to defer accepting a proposal if not enough time had
been given to reconsider the design.

std::dynarray has been accepted *very* early (one could say "hasty")
and the effect is that we have now several library issues with it.
There are already three issues in the current list,

http://cplusplus.github.io/LWG/lwg-active.html

and more will follow soon. Especially

http://cplusplus.github.io/LWG/lwg-active.html#2255

is one, where presumably the "best" P/R would be one that breaks the
CD, because it would change the uses-allocator overloads.

Library issues (by itself) aren't bad, but possibly breaking
implementations would be.

I'm not saying that deferring is a solution for everything, but having
a bit more time to check the consequences is IMO a good thing.

> They
> believed that the range study group would come up with something similar in
> their development of ranges, so they didn't feel it was important.

Not being present at that discussion I do agree with that for the
*current point in time*: There was extremely limited time for all
proposals and it was clear that not everything could become accepted
for the CD unless you want to accept the risk that responding to all
NB comments to the CD will have the effect that the committee will be
occupied for a very long time. Lets see what the Chicago meeting will
give us (which also will dependent on the concrete NB comments).

- Daniel

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

------=_Part_535_28406706.1369316921302
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thursday, May 23, 2013 1:40:08 AM UTC-7, Daniel Kr=FCgler wrote:
>
> 2013/5/23 Nicol Bolas <jmck...@gmail.com <javascript:>>:=20
> > On Wednesday, May 22, 2013 6:35:10 PM UTC-7, Alex B wrote:=20
> >>=20
> >> What I'm asking myself is what would be the best way to interpret/cast=
=20
> a=20
> >> vector to a dynarray (and that dynarray should not "own" the data; jus=
t=20
> >> refer to it). Any ideas? Note that std::array could as well be=20
> considered.=20
>
> Personally I'm strongly against mixing this kind of ownership=20
> responsibilities for fundamental types like std::array and=20
> std::dynarray. I think it is very important that a user can rely on=20
> that copies of std::(dyn)array will *always* be independent. This kind=20
> of abstraction should IMO be moved to a separate thingee and Nicol's=20
> reference to array_ref looks exactly right to me.=20
>
> > The "best way" to do this would have been for the committee to accept=
=20
> the=20
> > `array_ref` proposal. However, in their "wisdom", they did not.=20
>
> I cannot judge whether it would have been wise to accept the array_ref=20
> proposal *as written*, but I can say the following for sure: It is=20
> sometimes better to defer accepting a proposal if not enough time had=20
> been given to reconsider the design.
>

Before I begin, I just want to make sure we're talking about the same thing=
=20
here. I was suggesting `array_ref` as the solution to the OP's problem: a=
=20
class that could be built from a dynarray or std::vector or any other=20
contiguous array class, and thus would be useable as a non-owning container=
=20
of array elements by functions. A lingua franca for non-template code that=
=20
has to deal with contiguous array ranges.

I was not suggesting that `array_ref` *replace* `dynarray`; they don't do=
=20
the same thing. Therefore, I'm going to assume that what you said was in=20
response to `array_ref` as I intended, not as a replacement for `dynarray`.=
=20
If that was not your intent (and, given some of the things you said, I=20
suspect it was not), then please disregard the following.

Not enough time to reconsider the design? `array_ref` has known=20
implementations in both Google's internal stuff and LLVM, and those are=20
just the ones mentioned in the proposal. It's an incredibly simple class; I=
=20
wrote a version of it in 5 minutes.

We know exactly what it does and how it will be used. We have tons of=20
practical experience using it. So the "consequences" are well understood.=
=20
So what is there to "reconsider" in the design?

> They=20
> > believed that the range study group would come up with something simila=
r=20
> in=20
> > their development of ranges, so they didn't feel it was important.=20
>
> Not being present at that discussion I do agree with that for the=20
> *current point in time*: There was extremely limited time for all=20
> proposals and it was clear that not everything could become accepted=20
> for the CD unless you want to accept the risk that responding to all=20
> NB comments to the CD will have the effect that the committee will be=20
> occupied for a very long time. Lets see what the Chicago meeting will=20
> give us (which also will dependent on the concrete NB comments).
>

Again, I get the feeling that we're talking about two different things.=20
`array_ref` is a minor class, proposed at the same time as its companion=20
`string_ref`. `array_ref` was dismissed for reasons that I fail to=20
understand, while `string_ref` was allowed to continue.

If there were some issues with `array_ref`, some concerns about the=20
implementation, those could have been easily ironed out if the committee=20
had simply allowed the `array_ref` class another chance. But they didn't;=
=20
they said "get rid of it;" they had interest in `string_ref` but not in=20
`array_ref`.

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_535_28406706.1369316921302
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thursday, May 23, 2013 1:40:08 AM UTC-7, Daniel Kr=FCgler wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">2013/5/23 Nicol Bolas &lt;<a href=3D"j=
avascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"f6d299xLaQgJ">jmck..=
..@gmail.com</a>&gt;:
<br>&gt; On Wednesday, May 22, 2013 6:35:10 PM UTC-7, Alex B wrote:
<br>&gt;&gt;
<br>&gt;&gt; What I'm asking myself is what would be the best way to interp=
ret/cast a
<br>&gt;&gt; vector to a dynarray (and that dynarray should not "own" the d=
ata; just
<br>&gt;&gt; refer to it). Any ideas? Note that std::array could as well be=
 considered.
<br>
<br>Personally I'm strongly against mixing this kind of ownership
<br>responsibilities for fundamental types like std::array and
<br>std::dynarray. I think it is very important that a user can rely on
<br>that copies of std::(dyn)array will *always* be independent. This kind
<br>of abstraction should IMO be moved to a separate thingee and Nicol's
<br>reference to array_ref looks exactly right to me.
<br>
<br>&gt; The "best way" to do this would have been for the committee to acc=
ept the
<br>&gt; `array_ref` proposal. However, in their "wisdom", they did not.
<br>
<br>I cannot judge whether it would have been wise to accept the array_ref
<br>proposal *as written*, but I can say the following for sure: It is
<br>sometimes better to defer accepting a proposal if not enough time had
<br>been given to reconsider the design.<br></blockquote><div><br>Before I =
begin, I just want to make sure we're talking about the same thing here. I =
was suggesting `array_ref` as the solution to the OP's problem: a class tha=
t could be built from a dynarray or std::vector or any other contiguous arr=
ay class, and thus would be useable as a non-owning container of array elem=
ents by functions. A lingua franca for non-template code that has to deal w=
ith contiguous array ranges.<br><br>I was not suggesting that `array_ref` <=
i>replace</i> `dynarray`; they don't do the same thing. Therefore, I'm goin=
g to assume that what you said was in response to `array_ref` as I intended=
, not as a replacement for `dynarray`. If that was not your intent (and, gi=
ven some of the things you said, I suspect it was not), then please disrega=
rd the following.<br><br>Not enough time to reconsider the design? `array_r=
ef` has known implementations in both Google's internal stuff and LLVM, and=
 those are just the ones mentioned in the proposal. It's an incredibly simp=
le class; I wrote a version of it in 5 minutes.<br><br>We know exactly what=
 it does and how it will be used. We have tons of practical experience usin=
g it. So the "consequences" are well understood. So what is there to "recon=
sider" in the design?<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">&gt; They
<br>&gt; believed that the range study group would come up with something s=
imilar in
<br>&gt; their development of ranges, so they didn't feel it was important.
<br>
<br>Not being present at that discussion I do agree with that for the
<br>*current point in time*: There was extremely limited time for all
<br>proposals and it was clear that not everything could become accepted
<br>for the CD unless you want to accept the risk that responding to all
<br>NB comments to the CD will have the effect that the committee will be
<br>occupied for a very long time. Lets see what the Chicago meeting will
<br>give us (which also will dependent on the concrete NB comments).<br></b=
lockquote><div><br>Again, I get the feeling that we're talking about two di=
fferent things. `array_ref` is a minor class, proposed at the same time as =
its companion `string_ref`. `array_ref` was dismissed for reasons that I fa=
il to understand, while `string_ref` was allowed to continue.<br><br>If the=
re were some issues with `array_ref`, some concerns about the implementatio=
n, those could have been easily ironed out if the committee had simply allo=
wed the `array_ref` class another chance. But they didn't; they said "get r=
id of it;" they had interest in `string_ref` but not in `array_ref`.<br></d=
iv>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_535_28406706.1369316921302--

.

2013/5/23 Nicol Bolas <jmckesson@gmail.com>:
> On Thursday, May 23, 2013 1:40:08 AM UTC-7, Daniel Kr=FCgler wrote:
>>
>> 2013/5/23 Nicol Bolas <jmck...@gmail.com>:
>> > On Wednesday, May 22, 2013 6:35:10 PM UTC-7, Alex B wrote:
>> >>
>> >> What I'm asking myself is what would be the best way to interpret/cas=
t
>> >> a
>> >> vector to a dynarray (and that dynarray should not "own" the data; ju=
st
>> >> refer to it). Any ideas? Note that std::array could as well be
>> >> considered.
>>
>> Personally I'm strongly against mixing this kind of ownership
>> responsibilities for fundamental types like std::array and
>> std::dynarray. I think it is very important that a user can rely on
>> that copies of std::(dyn)array will *always* be independent. This kind
>> of abstraction should IMO be moved to a separate thingee and Nicol's
>> reference to array_ref looks exactly right to me.

Nicol, this part of my answer was mainly attributed to Alex. I thought
this was clear from quoting you here. Yes, he should you array_ref.

>> > The "best way" to do this would have been for the committee to accept
>> > the
>> > `array_ref` proposal. However, in their "wisdom", they did not.
>>
>> I cannot judge whether it would have been wise to accept the array_ref
>> proposal *as written*, but I can say the following for sure: It is
>> sometimes better to defer accepting a proposal if not enough time had
>> been given to reconsider the design.
>
> Before I begin, I just want to make sure we're talking about the same thi=
ng
> here. I was suggesting `array_ref` as the solution to the OP's problem: a
> class that could be built from a dynarray or std::vector or any other
> contiguous array class, and thus would be useable as a non-owning contain=
er
> of array elements by functions. A lingua franca for non-template code tha=
t
> has to deal with contiguous array ranges.

Yes, clearly.

> I was not suggesting that `array_ref` replace `dynarray`; they don't do t=
he
> same thing.

Yes - I have not understood you the way you seem to assume here.

> Therefore, I'm going to assume that what you said was in
> response to `array_ref` as I intended, not as a replacement for `dynarray=
`.

Yes. Unfortunately I was responding to two different things in one
message - bad idea.

> If that was not your intent (and, given some of the things you said, I
> suspect it was not), then please disregard the following.
>
> Not enough time to reconsider the design? `array_ref` has known
> implementations in both Google's internal stuff and LLVM, and those are j=
ust
> the ones mentioned in the proposal. It's an incredibly simple class; I wr=
ote
> a version of it in 5 minutes.

I do believe that and I certainly think that array_ref is not one of
the hardest things to specify. What I was referring to was questioning
whether it was "unwise" not to standardize array_ref exactly now. The
reason I was doing that was because *actually* dynarray is also quite
a simple thing, but causes this additional work. I found it also
amazing that a "simple thing" like the very simple runtime arrays that
we have now in the core language did need about five(!) revisions (but
it was for some reason!).

Just to make that clear: I'm strongly in favour for array_ref (and for
dynarray), but I would like to point out that "leaving something
incredibly useful" out will always happen, because the committee has
finite resources and quality of the standard is an important goal to
*intend* to get.

> We know exactly what it does and how it will be used. We have tons of
> practical experience using it. So the "consequences" are well understood.=
 So
> what is there to "reconsider" in the design?

I'm not questioning that std::array_ref works. In reality we often
have to consider some detail questions that have to be resolved. I'm
not saying that this necessarily happens here, but if you don't have
*any* time to let settle things a bit, the chances increase that you
overlook something "obvious". Again, my reaction was mostly related to
the question whether deferring something can be helpful or not. It can
be wise, yes, especially, if your bucket has reached some limits.

> Again, I get the feeling that we're talking about two different things.
> `array_ref` is a minor class, proposed at the same time as its companion
> `string_ref`. `array_ref` was dismissed for reasons that I fail to
> understand, while `string_ref` was allowed to continue.
>
> If there were some issues with `array_ref`, some concerns about the
> implementation, those could have been easily ironed out if the committee =
had
> simply allowed the `array_ref` class another chance. But they didn't; the=
y
> said "get rid of it;" they had interest in `string_ref` but not in
> `array_ref`.

From a far point I agree with you that it seemed not to be good reason
to remove array_ref. It really seems useful. I cannot answer to the
why, but I can understand that during a very intense meeting not all
decisions are perfect. The default correction mechanism are issues,
but probably not for a feature like array_ref.

Let me end with: We should have had std::array in C++03, so people
used boost::array or the similar popular implementations that were
published (or not) for years. It is unfortunate, but it is not
possible to standardize everything useful at a given point. Maybe we
should collect the examples, where std::array_ref makes sense as a
standard tool, and maybe an NB comment can give good arguments why
missing it is a kind of defect. In this case a "ready-to-go" proposal
can be valid response. If not, we need another round.

- Daniel

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



.

--047d7b6783acc3d37904dd6462c6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 23 May 2013 10:04, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wrote:

> I do believe that and I certainly think that array_ref is not one of
> the hardest things to specify. What I was referring to was questioning
> whether it was "unwise" not to standardize array_ref exactly now.


Note:  it was rejected in Kona, back when the next release vehicle was
C++17 (or possibly a TS), so I take that to mean that LWG just didn't want
it (I wasn't in the room, so I don't know for sure).

Just to make that clear: I'm strongly in favour for array_ref (and for
> dynarray), but I would like to point out that "leaving something
> incredibly useful" out will always happen, because the committee has
> finite resources and quality of the standard is an important goal to
> *intend* to get.
>

+1.  But I'm pretty sure we could have ironed out array_ref between 2012
and 2017, had we so chosen.


> From a far point I agree with you that it seemed not to be good reason
>
to remove array_ref. It really seems useful. I cannot answer to the
> why, but I can understand that during a very intense meeting not all
> decisions are perfect. The default correction mechanism are issues,
> but probably not for a feature like array_ref.
>

To be fair, in Kona EWG had just opened up, LEWG didn't exist, and
participation in LWG was relatively small compared with other meetings.


I'd like to see array_ref as well, but I have no idea how to get it back
into consideration.
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



--047d7b6783acc3d37904dd6462c6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 23 May 2013 10:04, Daniel Kr=FCgler <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:daniel.kruegler@gmail.com" target=3D"_blank">daniel.kruegler@gmail.com<=
/a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">

I do believe that and I certainly think that array_ref is not one of<br>
the hardest things to specify. What I was referring to was questioning<br>
whether it was &quot;unwise&quot; not to standardize array_ref exactly now.=
 </blockquote><div><br></div><div>Note: =A0it was rejected in Kona, back wh=
en the next release vehicle was C++17 (or possibly a TS), so I take that to=
 mean that LWG just didn&#39;t want it (I wasn&#39;t in the room, so I don&=
#39;t know for sure).</div>

<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
Just to make that clear: I&#39;m strongly in favour for array_ref (and for<=
br>
dynarray), but I would like to point out that &quot;leaving something<br>
incredibly useful&quot; out will always happen, because the committee has<b=
r>
finite resources and quality of the standard is an important goal to<br>
*intend* to get.<br></blockquote><div><br></div><div>+1. =A0But I&#39;m pre=
tty sure we could have ironed out array_ref between 2012 and 2017, had we s=
o chosen.</div><div>=A0=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"im">From a far point I agree with you that it seemed not to b=
e good reason</div></blockquote><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
to remove array_ref. It really seems useful. I cannot answer to the<br>
why, but I can understand that during a very intense meeting not all<br>
decisions are perfect. The default correction mechanism are issues,<br>
but probably not for a feature like array_ref.<br></blockquote><div><br></d=
iv><div>To be fair, in Kona EWG had just opened up, LEWG didn&#39;t exist, =
and participation in LWG was relatively small compared with other meetings.=
</div>

<div><br></div><div><br></div><div>I&#39;d like to see array_ref as well, b=
ut I have no idea how to get it back into consideration.</div></div>-- <br>=
=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin@evilov=
erlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 (847) 691-1=
404

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b6783acc3d37904dd6462c6--

.

------=_Part_762_1649333.1369328878742
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thursday, May 23, 2013 8:04:30 AM UTC-7, Daniel Kr=FCgler wrote:
>
> 2013/5/23 Nicol Bolas <jmck...@gmail.com>:=20
> > On Thursday, May 23, 2013 1:40:08 AM UTC-7, Daniel Kr=FCgler wrote:=20
> >>=20
> >> 2013/5/23 Nicol Bolas <jmck...@gmail.com>:=20
> > If that was not your intent (and, given some of the things you said, I=
=20
> > suspect it was not), then please disregard the following.=20
> >=20
> > Not enough time to reconsider the design? `array_ref` has known=20
> > implementations in both Google's internal stuff and LLVM, and those are=
=20
> just=20
> > the ones mentioned in the proposal. It's an incredibly simple class; I=
=20
> wrote=20
> > a version of it in 5 minutes.=20
>
> I do believe that and I certainly think that array_ref is not one of=20
> the hardest things to specify. What I was referring to was questioning=20
> whether it was "unwise" not to standardize array_ref exactly now. The=20
> reason I was doing that was because *actually* dynarray is also quite=20
> a simple thing, but causes this additional work. I found it also=20
> amazing that a "simple thing" like the very simple runtime arrays that=20
> we have now in the core language did need about five(!) revisions (but=20
> it was for some reason!).
>

Runtime-sized arrays are a very complex feature to standardize due to the=
=20
nature of C++. So I understand why it would take several iterations to get=
=20
right.

dynarray is complex because it's a class that can have radically different=
=20
behavior depending on where it gets used. That's entirely new territory,=20
and I don't think it's been implemented anywhere. There are also questions=
=20
of allocator usage, move support, etc. So again, I understand that it could=
=20
be difficult to put one together (and I personally agree with you that it=
=20
was accepted too soon. I was rather shocked the committee voted it in).

array_ref is neither of those. It's very simple in both the concept for the=
=20
user and for C++. It lacks the major design questions that dynarray brings=
=20
up, and it has zero language impact. We have broad implementation=20
experience. The implications of the class are very well understood.

It's the sort of thing that's such a no-brainer that, if the standards=20
committee couldn't find the time to standardize it, then there's something=
=20
wrong with the process.

Just to make that clear: I'm strongly in favour for array_ref (and for=20
> dynarray), but I would like to point out that "leaving something=20
> incredibly useful" out will always happen, because the committee has=20
> finite resources and quality of the standard is an important goal to=20
> *intend* to get.=20
>

I appreciate that perspective, but it would be a lot easier to accept if=20
the standards committee's processes actually *achieved* that "quality of=20
the standard" more often than it currently does. I'm working on a proposal=
=20
right now who's sole purpose is filling in a lot of holes in iostreams that=
=20
the standards committee forgot when they added various features to C++11.

It's wonderful that the committee wants the standard to be of high quality.=
=20
But they don't actually get that high quality often enough to justify using=
=20
the desire for high quality as some kind of shield from criticism. They not=
=20
only frequently leave out useful features, they also frequently forget to *
finish* features and propagate them to all appropriate corners of the=20
standard.

There's virtually no way to standardize array_ref that would leave the=20
class in a non-functional state. You might not be able to do certain things=
=20
with it. And there may be some issues down the road when ranges come out.=
=20
Even merely adopting the original proposal exactly as written (thus taking=
=20
virtually no time from the committee) would have left the standard no worse=
=20
off overall than, for example, forgetting to add stateful allocator support=
=20
to std::stringstream.

Also, I thought the whole TS thing was supposed to make small library-only=
=20
changes (like array_ref) more reasonable and easier to get done. Whatever=
=20
happened to that?

Lastly, if time is a factor for the committee, then maybe the process needs=
=20
to be changed to provide more time. They used to have 3 meetings a year=20
during the hard-and-heavy days of C++0x standardization. Maybe they need to=
=20
go back to that. Or maybe there need to be 2 informal meetings between=20
actual meetings, perhaps over teleconference, where papers can be presented=
=20
and commentary can be obtained to improve them. That way, they can make the=
=20
most of the formal standardization meetings, where you just say, "here's=20
paper X. We all know what it is, we've already talked about it, so let's=20
vote on it".

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_762_1649333.1369328878742
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thursday, May 23, 2013 8:04:30 AM UTC-7, Daniel Kr=FCgler wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">2013/5/23 Nicol Bolas &lt;<a target=3D=
"_blank">jmck...@gmail.com</a>&gt;:
<br>&gt; On Thursday, May 23, 2013 1:40:08 AM UTC-7, Daniel Kr=FCgler wrote=
:
<br>&gt;&gt;
<br>&gt;&gt; 2013/5/23 Nicol Bolas &lt;<a>jmck...@gmail.com</a>&gt;:
<br>&gt; If that was not your intent (and, given some of the things you sai=
d, I
<br>&gt; suspect it was not), then please disregard the following.
<br>&gt;
<br>&gt; Not enough time to reconsider the design? `array_ref` has known
<br>&gt; implementations in both Google's internal stuff and LLVM, and thos=
e are just
<br>&gt; the ones mentioned in the proposal. It's an incredibly simple clas=
s; I wrote
<br>&gt; a version of it in 5 minutes.
<br>
<br>I do believe that and I certainly think that array_ref is not one of
<br>the hardest things to specify. What I was referring to was questioning
<br>whether it was "unwise" not to standardize array_ref exactly now. The
<br>reason I was doing that was because *actually* dynarray is also quite
<br>a simple thing, but causes this additional work. I found it also
<br>amazing that a "simple thing" like the very simple runtime arrays that
<br>we have now in the core language did need about five(!) revisions (but
<br>it was for some reason!).<br></blockquote><div><br>Runtime-sized=20
arrays are a very complex feature to standardize due to the nature of=20
C++. So I understand why it would take several iterations to get right.<br>=
<br>dynarray
 is complex because it's a class that can have radically different=20
behavior depending on where it gets used. That's entirely new territory,
 and I don't think it's been implemented anywhere. There are also=20
questions of allocator usage, move support, etc. So again, I understand=20
that it could be difficult to put one together (and I personally agree=20
with you that it was accepted too soon. I was rather shocked the=20
committee voted it in).<br><br>array_ref is neither of those. It's very=20
simple in both the concept for the user and for C++. It lacks the major=20
design questions that dynarray brings up, and it has zero language=20
impact. We have broad implementation experience. The implications of the
 class are very well understood.<br><br>It's the sort of thing that's=20
such a no-brainer that, if the standards committee couldn't find the=20
time to standardize it, then there's something wrong with the process.<br><=
/div><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Just to make that cle=
ar: I'm strongly in favour for array_ref (and for
<br>dynarray), but I would like to point out that "leaving something
<br>incredibly useful" out will always happen, because the committee has
<br>finite resources and quality of the standard is an important goal to
<br>*intend* to get.
<br></blockquote><div><br>I appreciate that perspective, but it would be a =
lot easier to accept if the standards committee's processes actually <i>ach=
ieved</i> that "quality of the standard" more often than it currently does.=
 I'm working on a proposal right now who's sole purpose is filling in a lot=
 of holes in iostreams that the standards committee forgot when they added =
various features to C++11.<br><br>It's wonderful that the committee wants t=
he standard to be of high quality. But they don't actually get that high qu=
ality often enough to justify using the desire for high quality as some kin=
d of shield from criticism. They not only frequently leave out useful featu=
res, they also frequently forget to <i>finish</i> features and propagate th=
em to all appropriate corners of the standard.<br><br>There's virtually no =
way to standardize array_ref that would leave the class in a non-functional=
 state. You might not be able to do certain things with it. And there may b=
e some issues down the road when ranges come out. Even merely adopting the =
original proposal exactly as written (thus taking virtually no time from th=
e committee) would have left the standard no worse off overall than, for ex=
ample, forgetting to add stateful allocator support to std::stringstream.<b=
r><br>Also, I thought the whole TS thing was supposed to make small library=
-only changes (like array_ref) more reasonable and easier to get done. What=
ever happened to that?<br><br>Lastly, if time is a factor for the committee=
, then maybe the process needs to be changed to provide more time. They use=
d to have 3 meetings a year during the hard-and-heavy days of C++0x standar=
dization. Maybe they need to go back to that. Or maybe there need to be 2 i=
nformal meetings between actual meetings, perhaps over teleconference, wher=
e papers can be presented and commentary can be obtained to improve them. T=
hat way, they can make the most of the formal standardization meetings, whe=
re you just say, "here's paper X. We all know what it is, we've already tal=
ked about it, so let's vote on it".<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_762_1649333.1369328878742--

.

On Thu, May 23, 2013 at 8:31 AM, Nevin Liber <nevin@eviloverlord.com> wrote=
:
> On 23 May 2013 10:04, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wrote:
>>
>> I do believe that and I certainly think that array_ref is not one of
>> the hardest things to specify. What I was referring to was questioning
>> whether it was "unwise" not to standardize array_ref exactly now.
>
>
> Note:  it was rejected in Kona, back when the next release vehicle was C+=
+17
> (or possibly a TS), so I take that to mean that LWG just didn't want it (=
I
> wasn't in the room, so I don't know for sure).
>
>> Just to make that clear: I'm strongly in favour for array_ref (and for
>> dynarray), but I would like to point out that "leaving something
>> incredibly useful" out will always happen, because the committee has
>> finite resources and quality of the standard is an important goal to
>> *intend* to get.
>
>
> +1.  But I'm pretty sure we could have ironed out array_ref between 2012 =
and
> 2017, had we so chosen.
>
>>
>> From a far point I agree with you that it seemed not to be good reason
>>
>> to remove array_ref. It really seems useful. I cannot answer to the
>> why, but I can understand that during a very intense meeting not all
>> decisions are perfect. The default correction mechanism are issues,
>> but probably not for a feature like array_ref.
>
>
> To be fair, in Kona EWG had just opened up, LEWG didn't exist, and
> participation in LWG was relatively small compared with other meetings.
>
>
> I'd like to see array_ref as well, but I have no idea how to get it back
> into consideration.

I think we'll get iterator_range first, through the Ranges study
group. I think Marshall's actively working on that proposal?

If someone can propose a contiguous_iterator_tag (I don't plan to work
on it, but it should capture the 4 places the standard talks about
elements being "stored contiguously"), then I'll try to convince
people that iterator_range<T*> should have an implicit conversion from
any "traversable" (N3686) with contiguous iterators. At that point,
array_ref is just "template<typename T> using
array_ref=3Diterator_range<T*>;"

Nicol, I hear you talk a lot, but I haven't seen any papers from you.
Would you like to write up contiguous_iterator_tag?

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



.

------=_Part_338_30415847.1369329215445
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, May 23, 2013 6:07:58 PM UTC+1, Nicol Bolas wrote:
>
>
> Lastly, if time is a factor for the committee, then maybe the process
> needs to be changed to provide more time. They used to have 3 meetings a
> year during the hard-and-heavy days of C++0x standardization. Maybe they
> need to go back to that. Or maybe there need to be 2 informal meetings
> between actual meetings, perhaps over teleconference, where papers can be
> presented and commentary can be obtained to improve them. That way, they
> can make the most of the formal standardization meetings, where you just
> say, "here's paper X. We all know what it is, we've already talked about
> it, so let's vote on it".
>

"We all know what it is" will never be true. The committee is not a fixed
group of people who all attend every meeting and every teleconference and
read every post, so there will *always* be someone new to ask questions,
some of which have been covered already by "the committee" and some
haven't.   "They" do not have one mind and "they" are not all able to
attend two meetings a year, let alone three.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_338_30415847.1369329215445
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Thursday, May 23, 2013 6:07:58 PM UTC+1, Nicol Bolas wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><br><div>Lastly, if time is a facto=
r for the committee, then maybe the process needs to be changed to provide =
more time. They used to have 3 meetings a year during the hard-and-heavy da=
ys of C++0x standardization. Maybe they need to go back to that. Or maybe t=
here need to be 2 informal meetings between actual meetings, perhaps over t=
eleconference, where papers can be presented and commentary can be obtained=
 to improve them. That way, they can make the most of the formal standardiz=
ation meetings, where you just say, "here's paper X. We all know what it is=
, we've already talked about it, so let's vote on it".<br></div></blockquot=
e><div><br>"We all know what it is" will never be true. The committee is no=
t a fixed group of people who all attend every meeting and every teleconfer=
ence and read every post, so there will *always* be someone new to ask ques=
tions, some of which have been covered already by "the committee" and some =
haven't.&nbsp;&nbsp; "They" do not have one mind and "they" are not all abl=
e to attend two meetings a year, let alone three.<br><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_338_30415847.1369329215445--

.

--001a11c35aca79baba04dd677a4a
Content-Type: text/plain; charset=ISO-8859-1

On 23 May 2013 12:12, Jeffrey Yasskin <jyasskin@google.com> wrote:

>
> If someone can propose a contiguous_iterator_tag (I don't plan to work
> on it, but it should capture the 4 places the standard talks about
> elements being "stored contiguously"), then I'll try to convince
> people that iterator_range<T*> should have an implicit conversion from
> any "traversable" (N3686) with contiguous iterators. At that point,
> array_ref is just "template<typename T> using
> array_ref=iterator_range<T*>;"
>

FYI:  I was supposed to have done it for Bristol, but a fractured wrist
thwarted those plans. :-(  I'm still looking to do it for Chicago, but if
someone else wants to take over, I'm happy to let them.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--001a11c35aca79baba04dd677a4a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 23 May 2013 12:12, Jeffrey Yasskin <span dir=3D"ltr">&lt;<a href=3D"mail=
to:jyasskin@google.com" target=3D"_blank">jyasskin@google.com</a>&gt;</span=
> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
If someone can propose a contiguous_iterator_tag (I don&#39;t plan to work<=
br>
on it, but it should capture the 4 places the standard talks about<br>
elements being &quot;stored contiguously&quot;), then I&#39;ll try to convi=
nce<br>
people that iterator_range&lt;T*&gt; should have an implicit conversion fro=
m<br>
any &quot;traversable&quot; (N3686) with contiguous iterators. At that poin=
t,<br>
array_ref is just &quot;template&lt;typename T&gt; using<br>
array_ref=3Diterator_range&lt;T*&gt;;&quot;<br></blockquote><div><br>FYI:=
=A0 I was supposed to have done it for Bristol, but a fractured wrist thwar=
ted those plans. :-(=A0 I&#39;m still looking to do it for Chicago, but if =
someone else wants to take over, I&#39;m happy to let them.<br>

</div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
&gt;=A0 (847) 691-1404

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c35aca79baba04dd677a4a--

.

--0023543329e61a249a04dd679e5a
Content-Type: text/plain; charset=ISO-8859-1

On 23 May 2013 12:07, Nicol Bolas <jmckesson@gmail.com> wrote:

> Lastly, if time is a factor for the committee, then maybe the process
> needs to be changed to provide more time. They used to have 3 meetings a
> year during the hard-and-heavy days of C++0x standardization. Maybe they
> need to go back to that.


"They"?  How about "we"?  After all, it's easy to ask others to doing work;
much harder to commit yourself to doing work.  If we move to three meetings
a year, will you commit to attending them?

The committee is already considering this, but I have serious reservations
on whether it will help or hinder.  It is hard enough for most volunteers
to make it to two meetings a year; three meetings a year may just ending up
reducing the number of attendees at any given meeting w/o reducing the
workload.

Or maybe there need to be 2 informal meetings between actual meetings,
> perhaps over teleconference, where papers can be presented and commentary
> can be obtained to improve them.


Doing more "informal" work between meetings is also being considered.


> That way, they can make the most of the formal standardization meetings,
> where you just say, "here's paper X. We all know what it is, we've already
> talked about it, so let's vote on it".


That won't happen, for the reasons Jonathan has outlined.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--0023543329e61a249a04dd679e5a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 23 May 2013 12:07, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto:j=
mckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span> wr=
ote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Lastly, if time is a factor for the committee, then maybe the process needs=
 to be changed to provide more time. They used to have 3 meetings a year du=
ring the hard-and-heavy days of C++0x standardization. Maybe they need to g=
o back to that. </blockquote>

<div><br>&quot;They&quot;?=A0 How about &quot;we&quot;?=A0 After all, it&#3=
9;s easy to ask others to doing work; much harder to commit yourself to doi=
ng work.=A0 If we move to three meetings a year, will you commit to attendi=
ng them?<br>

<br>The committee is already considering this, but I have serious reservati=
ons on whether it will help or hinder.=A0 It is hard enough for most volunt=
eers to make it to two meetings a year; three meetings a year may just endi=
ng up reducing the number of attendees at any given meeting w/o reducing th=
e workload.<br>

<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">Or maybe there need to be 2 inform=
al meetings between actual meetings, perhaps over teleconference, where pap=
ers can be presented and commentary can be obtained to improve them.</block=
quote>

<div><br>Doing more &quot;informal&quot; work between meetings is also bein=
g considered.<br>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> That way, they ca=
n make the most of the formal standardization meetings, where you just say,=
 &quot;here&#39;s paper X. We all know what it is, we&#39;ve already talked=
 about it, so let&#39;s vote on it&quot;.</blockquote>

</div><br>That won&#39;t happen, for the reasons Jonathan has outlined.<br>=
-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin=
@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 (847=
) 691-1404

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--0023543329e61a249a04dd679e5a--

.

------=_Part_1_26404170.1369365483104
Content-Type: text/plain; charset=ISO-8859-1

I was not aware of the original array_ref proposal (which got dumped) nor
of the upcoming proposal allowing iterator_range<T*>. That really sound
like what I was looking for (at least for the second part of the problem in
my original post) and might really change the way users define their
functions and overloads. For example, we could replace those overloads:
void Func(const vector<int>& x);
void Func(const dynarray<int>& x);
void Func(initializer_list<int> x);
//void Func(array<int, ???> x); // cannot be passed directly without using
template
void Func(const int* x, size_t n); // std::array would probably need to use
this overload instead

by this one:
void Func(array_ref<int> x);

It makes everything clean and simple for everyone: *just define the type of
your function parameters as array_ref instead of vector, dynarray, array,
initializer_list and raw pointers*. It wasn't a big problem when only
vector and raw pointers existed, but with new classes from C++11/C++14,
having this is really becoming a need. And since we all seem to agree on
this, let's push for it :)

Now allow me to come back to the first half of the problem in my original
post which led me to propose moving vectors into dynarrays. The problem
remains for return values. Consider the following function returning all
prime numbers in a specific interval:
vector<int> GetPrimeNumbersInInterval(int lower_bound, int upper_bound);

In that case, is returning a vector the best idea? Let's explore the
possibilities using containers:
- array<int, ???>: Clearly, this is often not an option since the size
could not always be known at compile-time (which is the case in the
example).
- dynarray<int>: Bad idea because dynarray cannot be moved.
- vector<int>: Better idea since it can be moved and is more flexible.

So if the return value should be a container, vector would be the best
option. But what if the one calling the function prefers storing the result
in a dynarray? That's why I proposed adding the ability to move a vector in
a dynarray. But I am willing to explore other possibilities.

So instead of returning a container, one could also consider returning a
pointer-size pair. The pointer could be of the following types:
- int*: Bad idea because the caller might not manage the ownership properly.
- shared_ptr<int[]>: Could be an interesting idea. Note that this is from
N3640 proposal (not valid in actual standard).
- unique_ptr<int[]>: Even better than shared_ptr since a unique_ptr can be
moved in both shared and unique pointers. Just throwing an idea: What if
such a unique_ptr could be moved to/from a vector/dynarray?

I don't see any obvious solution according to what we currently have. Maybe
what we need is a new array class that would be almost exactly the same as
dynarray except that it would always allocate on the heap (or where the
specified allocator actually allocates). I would be tempted to call it a
shared_array (although I admit this is not ideal since it could be confused
with shared_ptr). A shared_array would also have the ability to move itself
to a vector or dynarray. A vector could also move itself to a shared_array.

shared_array<int> GetPrimeNumbersInInterval(int lower_bound, int upper_bound
)
{
   vector<int> prime_numbers;
   ...
   for (...)
   {
      ...
      prime_numbers.push_back(i);
      ...
   }
   ...
   return prime_numbers; // here the vector is moved in the returned
shared_array
}

User calling this function could then store the result in either a vector
or a dynarray:
vector<int> prime_numbers_vector{GetPrimeNumbersInInterval(x,y)};
dynarray<int> prime_numbers_dynarray{GetPrimeNumbersInInterval(x,y)};

Your thoughts?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_1_26404170.1369365483104
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I was not aware of the original array_ref proposal (which got dumped) nor o=
f the upcoming proposal allowing iterator_range&lt;T*&gt;. That really soun=
d like what I was looking for (at least for the second part of the problem =
in my original post) and might really change the way users define their fun=
ctions and overloads. For example, we could&nbsp;<span style=3D"font-size: =
small; font-family: arial;">replace those overloads:</span><div class=3D"pr=
ettyprint" style=3D"border: 1px solid rgb(187, 187, 187); background-color:=
 rgb(250, 250, 250); word-wrap: break-word;"><code class=3D"prettyprint"><d=
iv class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by=
-prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Func=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> vector</span><span styl=
e=3D"color: #080;" class=3D"styled-by-prettify">&lt;int&gt;</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> x</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-p=
rettify">Func</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">const<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> dynarray</=
span><span style=3D"color: #080;" class=3D"styled-by-prettify">&lt;int&gt;<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color:=
 #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Func</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">initializer_list</span><span style=3D"color: #080;" class=3D"style=
d-by-prettify">&lt;int&gt;</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> x</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span><span style=3D"color: #800;" class=3D"styled-by-prettify">//void=
 Func(array&lt;int, ???&gt; x); // cannot be passed directly without using =
template</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></span><span style=3D"color: #008;" class=3D"styled-by-prettify">void</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #606;" class=3D"styled-by-prettify">Func</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">const</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> size_t n=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #800;" class=3D"styled-by-prettify">// std::array would probabl=
y need to use this overload instead</span></div></code></div><div style=3D"=
font-size: small; font-family: arial;"><br></div><div style=3D"font-size: s=
mall; font-family: arial;">by this one:</div><div style=3D"font-size: small=
; font-family: arial;"><div class=3D"prettyprint" style=3D"border: 1px soli=
d rgb(187, 187, 187); background-color: rgb(250, 250, 250); word-wrap: brea=
k-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
606;" class=3D"styled-by-prettify">Func</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">array_ref</span><span style=3D"color: #080;" class=3D"s=
tyled-by-prettify">&lt;int&gt;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> x</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">);</span></div></code></div></div><div style=3D"font-size: smal=
l; font-family: arial;"><br></div><div style=3D"font-size: small; font-fami=
ly: arial;">It makes everything clean and simple for everyone:&nbsp;<i>just=
 define the type of your function parameters as array_ref instead of vector=
, dynarray, array, initializer_list and raw pointers</i>. It wasn't a big p=
roblem when only vector and raw pointers existed, but with new classes from=
 C++11/C++14, having this is really becoming a need. And since we all seem =
to agree on this, let's push for it :)</div><div style=3D"font-size: small;=
 font-family: arial;"><br></div><div style=3D"font-size: small; font-family=
: arial;">Now allow me to come back to the first half of the problem in my =
original post which led me to propose moving vectors into dynarrays. The pr=
oblem remains for return values. Consider the following function returning =
all prime numbers in a specific interval:</div><div style=3D"font-size: sma=
ll; font-family: arial;"><div class=3D"prettyprint" style=3D"border: 1px so=
lid rgb(187, 187, 187); background-color: rgb(250, 250, 250); word-wrap: br=
eak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span =
style=3D"color: #000;" class=3D"styled-by-prettify">vector</span><span styl=
e=3D"color: #080;" class=3D"styled-by-prettify">&lt;int&gt;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #606;" class=3D"styled-by-prettify">GetPrimeNumbersInInterval</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> lower_bound</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> upper_bound</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">);</span></div></code></div></div><div style=3D"font-siz=
e: small; font-family: arial;"><br></div><div style=3D"font-size: small; fo=
nt-family: arial;">In that case, is returning a vector the best idea? Let's=
 explore the possibilities using containers:</div><div style=3D"font-size: =
small; font-family: arial;">- array&lt;int, ???&gt;: Clearly, this is often=
 not an option since the size could not always be known at compile-time (wh=
ich is the case in the example).</div><div style=3D"font-size: small; font-=
family: arial;">- dynarray&lt;int&gt;: Bad idea because dynarray cannot be =
moved.</div><div style=3D"font-size: small; font-family: arial;">- vector&l=
t;int&gt;: Better idea since it can be moved and is more flexible.</div><di=
v style=3D"font-size: small; font-family: arial;"><br></div><div style=3D"f=
ont-size: small; font-family: arial;">So if the return value should be a co=
ntainer, vector would be the best option. But what if the one calling the f=
unction prefers storing the result in a dynarray? That's why I proposed add=
ing the ability to move a vector in a dynarray. But I am willing to explore=
 other possibilities.</div><div style=3D"font-size: small; font-family: ari=
al;"><br></div><div style=3D"font-size: small; font-family: arial;">So inst=
ead of returning a container, one could also consider returning a pointer-s=
ize pair. The pointer could be of the following types:</div><div style=3D"f=
ont-size: small; font-family: arial;">- int*: Bad idea because the caller m=
ight not manage the ownership properly.</div><div style=3D"font-size: small=
; font-family: arial;">- shared_ptr&lt;int[]&gt;: Could be an interesting i=
dea. Note that this is from N3640 proposal (not valid in actual standard).<=
/div><div style=3D"font-size: small; font-family: arial;">- unique_ptr&lt;i=
nt[]&gt;: Even better than shared_ptr since a unique_ptr can be moved in bo=
th shared and unique pointers. Just throwing an idea: What if such a unique=
_ptr could be moved to/from a vector/dynarray?</div><div style=3D"font-size=
: small; font-family: arial;"><br></div><div style=3D"font-size: small; fon=
t-family: arial;">I don't see any obvious solution according to what we cur=
rently have. Maybe what we need is a new array class that would be almost e=
xactly the same as dynarray except that it would always allocate on the hea=
p (or where the specified allocator actually allocates). I would be tempted=
 to call it a shared_array (although I admit this is not ideal since it cou=
ld be confused with shared_ptr). A shared_array would also have the ability=
 to move itself to a vector or dynarray. A vector could also move itself to=
 a shared_array.</div><div style=3D"font-size: small; font-family: arial;">=
<br></div><div style=3D"font-size: small; font-family: arial;"><div style=
=3D"background-color: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 1=
87); word-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettypri=
nt"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">shared_array</span><span style=3D"color: #080;" class=3D"s=
tyled-by-prettify">&lt;int&gt;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by=
-prettify">GetPrimeNumbersInInterval</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> lower_bound</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> upper_bound<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp;vector</span><span=
 style=3D"color: #080;" class=3D"styled-by-prettify">&lt;int&gt;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> prime_numbers</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp;</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">...</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp;</span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">for</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">(...)</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp;</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">...</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; prime_num=
bers</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">push_back</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">i</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">...</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp;</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp;</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">...</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp;</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">return</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> prime_numbers</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" =
class=3D"styled-by-prettify">// here the vector is moved in the returned sh=
ared_array</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</spa=
n></div></code></div><span class=3D"styled-by-prettify" style=3D"font-famil=
y: monospace; background-color: rgb(250, 250, 250); color: rgb(102, 102, 0)=
;"><div style=3D"font-size: small; font-family: arial;"><br></div></span></=
div><div style=3D"font-size: small; font-family: arial;">User calling this =
function could then store the result in either a vector or a dynarray:</div=
><div style=3D"background-color: rgb(250, 250, 250); border: 1px solid rgb(=
187, 187, 187); word-wrap: break-word;" class=3D"prettyprint"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">vector</span><span style=3D"color: #080;" cla=
ss=3D"styled-by-prettify">&lt;int&gt;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> prime_numbers_vector</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #606;" =
class=3D"styled-by-prettify">GetPrimeNumbersInInterval</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">x</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">y</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">)};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br>dynarray</span><span style=3D"color: #080;" class=3D"styled-by-prettif=
y">&lt;int&gt;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> prime_numbers_dynarray</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">{</span><span style=3D"color: #606;" class=3D"styled-by-pr=
ettify">GetPrimeNumbersInInterval</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">x</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify">y</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">)};</span></=
div></code></div><div style=3D"font-size: small; font-family: arial;"><br><=
/div><div style=3D"font-size: small; font-family: arial;">Your thoughts?</d=
iv>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1_26404170.1369365483104--

.

On May 23, 2013, at 10:18 PM, Alex B <devalexb@gmail.com> wrote:

> Maybe what we need is a new array class that would be almost exactly the same as dynarray except that it would always allocate on the heap (or where the specified allocator actually allocates).

How is that any different than vector?
 --
 Nevin ":-)" Liber
 <mailto:nevin@eviloverlord.com>
 (847) 691-1404
(sent from my iPad)

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

------=_Part_10_4524576.1369368372194
Content-Type: text/plain; charset=ISO-8859-1



> How is that any different than vector?
>

That is why I originally proposed allowing a vector to be moved in a
dynarray. But Daniel seemed to be against this idea and I have to admit it
is not the most flexible way. First, you can consider a shared_array to be
a bit more lightweight than a vector (cannot be resized). More importantly,
what if you have your own custom contiguous container class? Let's call it
MyVectorClass. It would not be possible for you to implement a constructor
taking an rvalue vector&& because you need to have access to the internal
representation of the vector to be able to move it.

Now let's assume that the shared_array class has a function that release
the ownership, allowing the move to be done:

template <class T>
class shared_array
{
   unique_ptr<T[]> data;
   size_t size;
public:
   ...
   pair<unique_ptr<T[]>, size_t> release_ownership() { return {move(data),size
}; }
   ...
};


template <class T>
class MyVectorClass
{
   ...
public:
   ...
   MyVectorClass(shared_array<T>&& a)
   {
      auto p = a.release_ownership();
      ... = move(a.first);
      ... = a.second;
   }
   ...
   operator shared_array<T> () && { ... }
   ...
};

Then again, you could say that the release_owership method could simply be
part of the vector class and your would be right. Personally, from this
point I am not really sure what would be the best design (having a
shared_array or extending the vector class) and I would be satisfied with
any.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_10_4524576.1369368372194
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">How is that any different =
than vector?<br></blockquote><div><br></div><div>That is why I originally p=
roposed allowing a vector to be moved in a dynarray. But Daniel seemed to b=
e against this idea and I have to admit it is not the most flexible way. Fi=
rst, you can consider a shared_array to be a bit more lightweight than a ve=
ctor (cannot be resized). More importantly, what if you have your own custo=
m contiguous container class? Let's call it MyVectorClass. It would not be =
possible for you to implement a constructor taking an rvalue vector&amp;&am=
p; because you need to have access to the internal representation of the ve=
ctor to be able to move it.</div><div><br></div><div>Now let's assume that =
the shared_array class has a function that release the ownership, allowing =
the move to be done:</div><div><br></div><div style=3D"background-color: rg=
b(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-wo=
rd;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subpre=
ttyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">templat=
e</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> shared_array<br></span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>&nbsp; &nbsp;unique_ptr</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">[]&gt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> data</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br>&nbsp; &nbsp;size_t size</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">public</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>&nbsp; &nbsp;</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">...</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>&nbsp; &nbsp;pair</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">unique_ptr</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[]&gt;,</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> size_t</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> release_ownership</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">move</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">data</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">),</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> size</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br>&nbsp; &nbsp;</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">...</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br><br><br></span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">template</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&l=
t;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">class</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">class</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" c=
lass=3D"styled-by-prettify">MyVectorClass</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>&nbsp; &nbsp;</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">...</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">public</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r>&nbsp; &nbsp;</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">...</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r>&nbsp; &nbsp;</span><span style=3D"color: #606;" class=3D"styled-by-prett=
ify">MyVectorClass</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">s=
hared_array</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;&amp;&amp;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> a</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp;</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> p </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> a</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">release_ownership</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">...</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> move</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">first</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">...</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> a</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">second</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br>&nbsp; &nbsp;</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>&nbsp; &nbsp;</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">...</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>&nbsp; &nbsp;</span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">operator</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> shared_array</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">T</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&amp;&amp;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">...</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&=
nbsp; &nbsp;</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">...</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span></=
div></code></div><div><br></div><div>Then again, you could say that the rel=
ease_owership method could simply be part of the vector class and your woul=
d be right.&nbsp;Personally, from this point I am not really sure what woul=
d be the best design (having a shared_array or extending the vector class) =
and I would be satisfied with any.</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_10_4524576.1369368372194--

.

2013/5/24 Alex B <devalexb@gmail.com>:
> I was not aware of the original array_ref proposal (which got dumped) nor of
> the upcoming proposal allowing iterator_range<T*>. That really sound like
> what I was looking for (at least for the second part of the problem in my
> original post) and might really change the way users define their functions
> and overloads. For example, we could replace those overloads:
> void Func(const vector<int>& x);
> void Func(const dynarray<int>& x);
> void Func(initializer_list<int> x);
> //void Func(array<int, ???> x); // cannot be passed directly without using
> template
> void Func(const int* x, size_t n); // std::array would probably need to use
> this overload instead
>
> by this one:
> void Func(array_ref<int> x);
>
> It makes everything clean and simple for everyone: just define the type of
> your function parameters as array_ref instead of vector, dynarray, array,
> initializer_list and raw pointers.

Yes, exactly.

> Now allow me to come back to the first half of the problem in my original
> post which led me to propose moving vectors into dynarrays. The problem
> remains for return values. Consider the following function returning all
> prime numbers in a specific interval:
> vector<int> GetPrimeNumbersInInterval(int lower_bound, int upper_bound);
>
> In that case, is returning a vector the best idea? Let's explore the
> possibilities using containers:
> - array<int, ???>: Clearly, this is often not an option since the size could
> not always be known at compile-time (which is the case in the example).
> - dynarray<int>: Bad idea because dynarray cannot be moved.
> - vector<int>: Better idea since it can be moved and is more flexible.
>
> So if the return value should be a container, vector would be the best
> option. But what if the one calling the function prefers storing the result
> in a dynarray? That's why I proposed adding the ability to move a vector in
> a dynarray. But I am willing to explore other possibilities.

I think that dynarray is not a good container for this kind of
example, because it would be returned out of a function. Yes,
technically it it possible to return a dynarray, but it really would
not take advantage of the most important use-case for that type: To be
used in block scope as variable with automatic storage duration and
taking the memory from the stack.

> I don't see any obvious solution according to what we currently have. Maybe
> what we need is a new array class that would be almost exactly the same as
> dynarray except that it would always allocate on the heap (or where the
> specified allocator actually allocates).

Why is that type not std::vector?

- Daniel

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

------=_Part_110_31213503.1369377195359
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thursday, May 23, 2013 10:12:18 AM UTC-7, Jeffrey Yasskin wrote:
>
> On Thu, May 23, 2013 at 8:31 AM, Nevin Liber <ne...@eviloverlord.com<java=
script:>>=20
> wrote:=20
> > On 23 May 2013 10:04, Daniel Kr=FCgler <daniel....@gmail.com <javascrip=
t:>>=20
> wrote:=20
> >>=20
> >> I do believe that and I certainly think that array_ref is not one of=
=20
> >> the hardest things to specify. What I was referring to was questioning=
=20
> >> whether it was "unwise" not to standardize array_ref exactly now.=20
> >=20
> >=20
> > Note:  it was rejected in Kona, back when the next release vehicle was=
=20
> C++17=20
> > (or possibly a TS), so I take that to mean that LWG just didn't want it=
=20
> (I=20
> > wasn't in the room, so I don't know for sure).=20
> >=20
> >> Just to make that clear: I'm strongly in favour for array_ref (and for=
=20
> >> dynarray), but I would like to point out that "leaving something=20
> >> incredibly useful" out will always happen, because the committee has=
=20
> >> finite resources and quality of the standard is an important goal to=
=20
> >> *intend* to get.=20
> >=20
> >=20
> > +1.  But I'm pretty sure we could have ironed out array_ref between 201=
2=20
> and=20
> > 2017, had we so chosen.=20
> >=20
> >>=20
> >> From a far point I agree with you that it seemed not to be good reason=
=20
> >>=20
> >> to remove array_ref. It really seems useful. I cannot answer to the=20
> >> why, but I can understand that during a very intense meeting not all=
=20
> >> decisions are perfect. The default correction mechanism are issues,=20
> >> but probably not for a feature like array_ref.=20
> >=20
> >=20
> > To be fair, in Kona EWG had just opened up, LEWG didn't exist, and=20
> > participation in LWG was relatively small compared with other meetings.=
=20
> >=20
> >=20
> > I'd like to see array_ref as well, but I have no idea how to get it bac=
k=20
> > into consideration.=20
>
> I think we'll get iterator_range first, through the Ranges study=20
> group. I think Marshall's actively working on that proposal?=20
>
> If someone can propose a contiguous_iterator_tag (I don't plan to work=20
> on it, but it should capture the 4 places the standard talks about=20
> elements being "stored contiguously"), then I'll try to convince=20
> people that iterator_range<T*> should have an implicit conversion from=20
> any "traversable" (N3686) with contiguous iterators. At that point,=20
> array_ref is just "template<typename T> using=20
> array_ref=3Diterator_range<T*>;"=20
>
> Nicol, I hear you talk a lot, but I haven't seen any papers from you.=20
> Would you like to write up contiguous_iterator_tag?=20
>

No; I don't want to see it done this way. Ranges are a *long* way from=20
standardization (unless discussions are happening outside of the range=20
study group's mailing list that I'm not aware of).

array_ref is too simple and useful to directly associate it with ranges or=
=20
some other proposal. We don't even know what this "iterator_range" will=20
look like, or if it will even *exist* (there was a lot of talk on the ML=20
about not building ranges around iterator pairs and such). We have no idea=
=20
what functionality such a class would have, so there's no way to evaluate=
=20
if such a class could adequately encompass all of the features of array_ref=
=20
in a tight package.

Whereas array_ref is a concrete proposal with real-world utility. I see no=
=20
reason to delay array_ref for ranges.

As others are so fond of saying (though curiously, usually when only when=
=20
it's in favor of something they like), perfect is the enemy of good.=20
array_ref is good; we should have that.

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_110_31213503.1369377195359
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thursday, May 23, 2013 10:12:18 AM UTC-7, Jeffrey Yasskin wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">On Thu, May 23, 2013 at 8:31 AM, Nevin=
 Liber &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"pPAmeyuoG4IJ">ne...@eviloverlord.com</a>&gt; wrote:
<br>&gt; On 23 May 2013 10:04, Daniel Kr=FCgler &lt;<a href=3D"javascript:"=
 target=3D"_blank" gdf-obfuscated-mailto=3D"pPAmeyuoG4IJ">daniel....@gmail.=
com</a>&gt; wrote:
<br>&gt;&gt;
<br>&gt;&gt; I do believe that and I certainly think that array_ref is not =
one of
<br>&gt;&gt; the hardest things to specify. What I was referring to was que=
stioning
<br>&gt;&gt; whether it was "unwise" not to standardize array_ref exactly n=
ow.
<br>&gt;
<br>&gt;
<br>&gt; Note: &nbsp;it was rejected in Kona, back when the next release ve=
hicle was C++17
<br>&gt; (or possibly a TS), so I take that to mean that LWG just didn't wa=
nt it (I
<br>&gt; wasn't in the room, so I don't know for sure).
<br>&gt;
<br>&gt;&gt; Just to make that clear: I'm strongly in favour for array_ref =
(and for
<br>&gt;&gt; dynarray), but I would like to point out that "leaving somethi=
ng
<br>&gt;&gt; incredibly useful" out will always happen, because the committ=
ee has
<br>&gt;&gt; finite resources and quality of the standard is an important g=
oal to
<br>&gt;&gt; *intend* to get.
<br>&gt;
<br>&gt;
<br>&gt; +1. &nbsp;But I'm pretty sure we could have ironed out array_ref b=
etween 2012 and
<br>&gt; 2017, had we so chosen.
<br>&gt;
<br>&gt;&gt;
<br>&gt;&gt; From a far point I agree with you that it seemed not to be goo=
d reason
<br>&gt;&gt;
<br>&gt;&gt; to remove array_ref. It really seems useful. I cannot answer t=
o the
<br>&gt;&gt; why, but I can understand that during a very intense meeting n=
ot all
<br>&gt;&gt; decisions are perfect. The default correction mechanism are is=
sues,
<br>&gt;&gt; but probably not for a feature like array_ref.
<br>&gt;
<br>&gt;
<br>&gt; To be fair, in Kona EWG had just opened up, LEWG didn't exist, and
<br>&gt; participation in LWG was relatively small compared with other meet=
ings.
<br>&gt;
<br>&gt;
<br>&gt; I'd like to see array_ref as well, but I have no idea how to get i=
t back
<br>&gt; into consideration.
<br>
<br>I think we'll get iterator_range first, through the Ranges study
<br>group. I think Marshall's actively working on that proposal?
<br>
<br>If someone can propose a contiguous_iterator_tag (I don't plan to work
<br>on it, but it should capture the 4 places the standard talks about
<br>elements being "stored contiguously"), then I'll try to convince
<br>people that iterator_range&lt;T*&gt; should have an implicit conversion=
 from
<br>any "traversable" (N3686) with contiguous iterators. At that point,
<br>array_ref is just "template&lt;typename T&gt; using
<br>array_ref=3Diterator_range&lt;T*&gt;;"
<br>
<br>Nicol, I hear you talk a lot, but I haven't seen any papers from you.
<br>Would you like to write up contiguous_iterator_tag?
<br></blockquote><div><br>No; I don't want to see it done this way. Ranges =
are a *long* way from standardization (unless discussions are happening out=
side of the range study group's mailing list that I'm not aware of).<br><br=
>array_ref is too simple and useful to directly associate it with ranges or=
 some other proposal. We don't even know what this "iterator_range" will lo=
ok like, or if it will even <i>exist</i> (there was a lot of talk on the ML=
 about not building ranges around iterator pairs and such). We have no idea=
 what functionality such a class would have, so there's no way to evaluate =
if such a class could adequately encompass all of the features of array_ref=
 in a tight package.<br><br>Whereas array_ref is a concrete proposal with r=
eal-world utility. I see no reason to delay array_ref for ranges.<br><br>As=
 others are so fond of saying (though curiously, usually when only when it'=
s in favor of something they like), perfect is the enemy of good. array_ref=
 is good; we should have that.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_110_31213503.1369377195359--

.

------=_Part_103_3674457.1369377938125
Content-Type: text/plain; charset=ISO-8859-1

On Thursday, May 23, 2013 10:13:35 AM UTC-7, Jonathan Wakely wrote:
>
> On Thursday, May 23, 2013 6:07:58 PM UTC+1, Nicol Bolas wrote:
>>
>>
>> Lastly, if time is a factor for the committee, then maybe the process
>> needs to be changed to provide more time. They used to have 3 meetings a
>> year during the hard-and-heavy days of C++0x standardization. Maybe they
>> need to go back to that. Or maybe there need to be 2 informal meetings
>> between actual meetings, perhaps over teleconference, where papers can be
>> presented and commentary can be obtained to improve them. That way, they
>> can make the most of the formal standardization meetings, where you just
>> say, "here's paper X. We all know what it is, we've already talked about
>> it, so let's vote on it".
>>
>
> "We all know what it is" will never be true. The committee is not a fixed
> group of people who all attend every meeting and every teleconference and
> read every post, so there will *always* be someone new to ask questions,
> some of which have been covered already by "the committee" and some
> haven't.   "They" do not have one mind and "they" are not all able to
> attend two meetings a year, let alone three.
>

Well, maybe that's part of the problem.

If a particular committee member did not get involved in the primary
discussion for a particular proposal, then they should not be able to delay
the process by asking questions *later* about it. If the rest of the
committee, who did decide to incorporate it, decided that it was ready to
go, it shouldn't stop because of a couple of people who weren't there for
the main discussion.

Think of it as a "speak now or forever hold your peace" kind of thing. This
would make the process more efficient, as we would know when the discussion
phase for a proposal has begun and ended. There would be a clear record of
the discussion, so that later groups can read the discussions and see what
points have been dealt with (the minutes that I've seen from meetings thus
far don't seem to work as a record of significant issues for discussion. I
couldn't even find the record for when the array_ref proposal was rejected,
let along the criticisms for it).

This sort of thing is where I think that the Study Group stuff has a real
problem. Take, for example, reflection. They're doing their work in their
own time. These experts come up with a solid, concrete proposal and spend
lots of time iterating over it.

Why should they then present all of that work to the Evolution Working
Group for the sole purpose of talking about issues that were almost
certainly well-covered in the SG? If these SGs are expert groups focused on
a particular concept, then we should accept that they're *experts* and
assume that they've done the diligence on their proposals. And if they
haven't, CWG can always simply reject the proposal, with commentary
(written outside of the actual meetings) from those dissenting members.

By forcing their proposals through the EWG/LEWG before standardization, it
just makes the process take that much longer for no material gain.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_103_3674457.1369377938125
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thursday, May 23, 2013 10:13:35 AM UTC-7, Jonathan Wakely wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">On Thursday, May 23, 2013 6:07:58 PM U=
TC+1, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0=
;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br><div>La=
stly, if time is a factor for the committee, then maybe the process needs t=
o be changed to provide more time. They used to have 3 meetings a year duri=
ng the hard-and-heavy days of C++0x standardization. Maybe they need to go =
back to that. Or maybe there need to be 2 informal meetings between actual =
meetings, perhaps over teleconference, where papers can be presented and co=
mmentary can be obtained to improve them. That way, they can make the most =
of the formal standardization meetings, where you just say, "here's paper X=
.. We all know what it is, we've already talked about it, so let's vote on i=
t".<br></div></blockquote><div><br>"We all know what it is" will never be t=
rue. The committee is not a fixed group of people who all attend every meet=
ing and every teleconference and read every post, so there will *always* be=
 someone new to ask questions, some of which have been covered already by "=
the committee" and some haven't.&nbsp;&nbsp; "They" do not have one mind an=
d "they" are not all able to attend two meetings a year, let alone three.<b=
r></div></blockquote><div><br>Well, maybe that's part of the problem.<br><b=
r>If a particular committee member did not get involved in the primary disc=
ussion for a particular proposal, then they should not be able to delay the=
 process by asking questions <i>later</i> about it. If the rest of the comm=
ittee, who did decide to incorporate it, decided that it was ready to go, i=
t shouldn't stop because of a couple of people who weren't there for the ma=
in discussion.<br><br>Think of it as a "speak now or forever hold your peac=
e" kind of thing. This would make the process more efficient, as we would k=
now when the discussion phase for a proposal has begun and ended. There wou=
ld be a clear record of the discussion, so that later groups can read the d=
iscussions and see what points have been dealt with (the minutes that I've =
seen from meetings thus far don't seem to work as a record of significant i=
ssues for discussion. I couldn't even find the record for when the array_re=
f proposal was rejected, let along the criticisms for it).<br><br>This sort=
 of thing is where I think that the Study Group stuff has a real problem. T=
ake, for example, reflection. They're doing their work in their own time. T=
hese experts come up with a solid, concrete proposal and spend lots of time=
 iterating over it.<br><br>Why should they then present all of that work to=
 the Evolution Working Group for the sole purpose of talking about issues t=
hat were almost certainly well-covered in the SG? If these SGs are expert g=
roups focused on a particular concept, then we should accept that they're <=
i>experts</i> and assume that they've done the diligence on their proposals=
.. And if they haven't, CWG can always simply reject the proposal, with comm=
entary (written outside of the actual meetings) from those dissenting membe=
rs.<br><br>By forcing their proposals through the EWG/LEWG before standardi=
zation, it just makes the process take that much longer for no material gai=
n.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_103_3674457.1369377938125--

.

------=_Part_114_8093476.1369378028624
Content-Type: text/plain; charset=ISO-8859-1

On Thursday, May 23, 2013 8:29:16 PM UTC-7, Nevin ":-)" Liber wrote:
>
> On May 23, 2013, at 10:18 PM, Alex B <deva...@gmail.com <javascript:>>
> wrote:
>
> > Maybe what we need is a new array class that would be almost exactly the
> same as dynarray except that it would always allocate on the heap (or where
> the specified allocator actually allocates).
>
> How is that any different than vector?
>

It is exactly like std::vector except that it must be created with an
explicit size, and it cannot be resized at all.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_114_8093476.1369378028624
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thursday, May 23, 2013 8:29:16 PM UTC-7, Nevin ":-)" Liber wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">On May 23, 2013, at 10:18 PM, Alex B =
&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"GcKg=
N1bX4KcJ">deva...@gmail.com</a>&gt; wrote:
<br>
<br>&gt; Maybe what we need is a new array class that would be almost exact=
ly the same as dynarray except that it would always allocate on the heap (o=
r where the specified allocator actually allocates).
<br>
<br>How is that any different than vector?<br></blockquote><div><br>It is e=
xactly like std::vector except that it must be created with an explicit siz=
e, and it cannot be resized at all.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_114_8093476.1369378028624--

.

2013/5/24 Nicol Bolas <jmckesson@gmail.com>:
> On Thursday, May 23, 2013 8:29:16 PM UTC-7, Nevin ":-)" Liber wrote:
>>
>> On May 23, 2013, at 10:18 PM, Alex B <deva...@gmail.com> wrote:
>>
>> > Maybe what we need is a new array class that would be almost exactly the
>> > same as dynarray except that it would always allocate on the heap (or where
>> > the specified allocator actually allocates).
>>
>> How is that any different than vector?
>
> It is exactly like std::vector except that it must be created with an
> explicit size, and it cannot be resized at all.

This looks like a adaptor for std::vector for me, so wouldn't
necessarily require a full-fledged container.

- Daniel

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

--001a11c2f4bc5d266e04dd7186b2
Content-Type: text/plain; charset=ISO-8859-1

On 24 May 2013 09:33, Nicol Bolas <jmckesson@gmail.com> wrote:

>
> I think we'll get iterator_range first, through the Ranges study
>> group. I think Marshall's actively working on that proposal?
>>
>> If someone can propose a contiguous_iterator_tag (I don't plan to work
>> on it, but it should capture the 4 places the standard talks about
>> elements being "stored contiguously"), then I'll try to convince
>> people that iterator_range<T*> should have an implicit conversion from
>> any "traversable" (N3686) with contiguous iterators. At that point,
>> array_ref is just "template<typename T> using
>> array_ref=iterator_range<T*>;"
>>
>> Nicol, I hear you talk a lot, but I haven't seen any papers from you.
>> Would you like to write up contiguous_iterator_tag?
>>
>
> No; I don't want to see it done this way. Ranges are a *long* way from
> standardization (unless discussions are happening outside of the range
> study group's mailing list that I'm not aware of).
>
> array_ref is too simple and useful to directly associate it with ranges or
> some other proposal. We don't even know what this "iterator_range" will
> look like, or if it will even *exist* (there was a lot of talk on the ML
> about not building ranges around iterator pairs and such). We have no idea
> what functionality such a class would have, so there's no way to evaluate
> if such a class could adequately encompass all of the features of array_ref
> in a tight package.
>
> Whereas array_ref is a concrete proposal with real-world utility. I see no
> reason to delay array_ref for ranges.
>
> As others are so fond of saying (though curiously, usually when only when
> it's in favor of something they like), perfect is the enemy of good.
> array_ref is good; we should have that.
>

I happen to agree. Just because we're exploring ranges, we shouldn't punt
simple things like array_ref
or string-split to a far unknown future because we may or may not have some
range solution to the
same problems. I already have std::mismatch on top of which I can build
splitting functionality, but
doing so is infeasible for non-experts.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--001a11c2f4bc5d266e04dd7186b2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 24 May 2013 09:33, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><div><div class=3D"h5"><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex">
I think we&#39;ll get iterator_range first, through the Ranges study
<br>group. I think Marshall&#39;s actively working on that proposal?
<br>
<br>If someone can propose a contiguous_iterator_tag (I don&#39;t plan to w=
ork
<br>on it, but it should capture the 4 places the standard talks about
<br>elements being &quot;stored contiguously&quot;), then I&#39;ll try to c=
onvince
<br>people that iterator_range&lt;T*&gt; should have an implicit conversion=
 from
<br>any &quot;traversable&quot; (N3686) with contiguous iterators. At that =
point,
<br>array_ref is just &quot;template&lt;typename T&gt; using
<br>array_ref=3Diterator_range&lt;T*&gt;;&quot;
<br>
<br>Nicol, I hear you talk a lot, but I haven&#39;t seen any papers from yo=
u.
<br>Would you like to write up contiguous_iterator_tag?
<br></blockquote></div></div><div><br>No; I don&#39;t want to see it done t=
his way. Ranges are a *long* way from standardization (unless discussions a=
re happening outside of the range study group&#39;s mailing list that I&#39=
;m not aware of).<br>
<br>array_ref is too simple and useful to directly associate it with ranges=
 or some other proposal. We don&#39;t even know what this &quot;iterator_ra=
nge&quot; will look like, or if it will even <i>exist</i> (there was a lot =
of talk on the ML about not building ranges around iterator pairs and such)=
.. We have no idea what functionality such a class would have, so there&#39;=
s no way to evaluate if such a class could adequately encompass all of the =
features of array_ref in a tight package.<br>
<br>Whereas array_ref is a concrete proposal with real-world utility. I see=
 no reason to delay array_ref for ranges.<br><br>As others are so fond of s=
aying (though curiously, usually when only when it&#39;s in favor of someth=
ing they like), perfect is the enemy of good. array_ref is good; we should =
have that.<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">



</div></div></blockquote></div><br></div><div class=3D"gmail_extra">I happe=
n to agree. Just because we&#39;re exploring ranges, we shouldn&#39;t punt =
simple things like array_ref<br></div><div class=3D"gmail_extra">or string-=
split to a far unknown future because we may or may not have some range sol=
ution to the<br>
same problems. I already have std::mismatch on top of which I can build spl=
itting functionality, but<br>doing so is infeasible for non-experts.<br></d=
iv></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c2f4bc5d266e04dd7186b2--

.

--001a11c3311233c13204dd719c5b
Content-Type: text/plain; charset=ISO-8859-1

On 24 May 2013 09:45, Nicol Bolas <jmckesson@gmail.com> wrote:

> If a particular committee member did not get involved in the primary
> discussion for a particular proposal, then they should not be able to delay
> the process by asking questions *later* about it. If the rest of the
> committee, who did decide to incorporate it, decided that it was ready to
> go, it shouldn't stop because of a couple of people who weren't there for
> the main discussion.
>

That's an interesting wish, but its chance of becoming true is next to nil.
The aforementioned committee members
have the liberty to speak their mind at the ballot phase anyway, so trying
to sneak past them will not happen,
and will not work.


>
> Think of it as a "speak now or forever hold your peace" kind of thing.
> This would make the process more efficient, as we would know when the
> discussion phase for a proposal has begun and ended. There would be a clear
> record of the discussion, so that later groups can read the discussions and
> see what points have been dealt with (the minutes that I've seen from
> meetings thus far don't seem to work as a record of significant issues for
> discussion. I couldn't even find the record for when the array_ref proposal
> was rejected, let along the criticisms for it).
>

The plenary minutes capture most, but not all of the technical discussion
of the plenary meetings. There are more
detailed minutes, but those aren't open to the general public. Even so,
they are not a substitute for being present
in the actual discussion.


> This sort of thing is where I think that the Study Group stuff has a real
> problem. Take, for example, reflection. They're doing their work in their
> own time. These experts come up with a solid, concrete proposal and spend
> lots of time iterating over it.
>
> Why should they then present all of that work to the Evolution Working
> Group for the sole purpose of talking about issues that were almost
> certainly well-covered in the SG? If these SGs are expert groups focused on
> a particular concept, then we should
>

It's called "review". :)


> accept that they're *experts* and assume that they've done the diligence
> on their proposals. And if they haven't, CWG can always simply reject the
> proposal, with commentary (written outside of the actual meetings) from
> those dissenting members.
>
> By forcing their proposals through the EWG/LEWG before standardization, it
> just makes the process take that much longer for no material gain.
>
>
>
>
It's not the bailiwick of CWG or LWG to reject proposals based on design
concerns, their responsibility is to review
the wording and make the proposals otherwise fit the rest of the standard.
The EWGs perform design reviews. If
a SG is unsure about direction, they can present preliminary work to (L)EWG
as early as they wish, provided that
such discussions fit the schedules. I very much doubt that we want to
short-circuit this process, so if SGs want
to speed it up, they need to come up with better proposals that answer the
questions people have.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--001a11c3311233c13204dd719c5b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 24 May 2013 09:45, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">If a particular committee member did not get=
 involved in the primary discussion for a particular proposal, then they sh=
ould not be able to delay the process by asking questions <i>later</i> abou=
t it. If the rest of the committee, who did decide to incorporate it, decid=
ed that it was ready to go, it shouldn&#39;t stop because of a couple of pe=
ople who weren&#39;t there for the main discussion.<br>
</blockquote><div><br></div><div>That&#39;s an interesting wish, but its ch=
ance of becoming true is next to nil. The aforementioned committee members<=
br></div><div>have the liberty to speak their mind at the ballot phase anyw=
ay, so trying to sneak past them will not happen,<br>
and will not work.<br>=A0<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br=
>Think of it as a &quot;speak now or forever hold your peace&quot; kind of =
thing. This would make the process more efficient, as we would know when th=
e discussion phase for a proposal has begun and ended. There would be a cle=
ar record of the discussion, so that later groups can read the discussions =
and see what points have been dealt with (the minutes that I&#39;ve seen fr=
om meetings thus far don&#39;t seem to work as a record of significant issu=
es for discussion. I couldn&#39;t even find the record for when the array_r=
ef proposal was rejected, let along the criticisms for it).<br>
</div></blockquote><div><br></div><div>The plenary minutes capture most, bu=
t not all of the technical discussion of the plenary meetings. There are mo=
re<br>detailed minutes, but those aren&#39;t open to the general public. Ev=
en so, they are not a substitute for being present<br>
in the actual discussion.<br><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>=
<br>This sort of thing is where I think that the Study Group stuff has a re=
al problem. Take, for example, reflection. They&#39;re doing their work in =
their own time. These experts come up with a solid, concrete proposal and s=
pend lots of time iterating over it.<br>
<br>Why should they then present all of that work to the Evolution Working =
Group for the sole purpose of talking about issues that were almost certain=
ly well-covered in the SG? If these SGs are expert groups focused on a part=
icular concept, then we should </div>
</blockquote><div><br></div><div>It&#39;s called &quot;review&quot;. :)<br>=
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div>accept that they&#39;re <i=
>experts</i> and assume that they&#39;ve done the diligence on their propos=
als. And if they haven&#39;t, CWG can always simply reject the proposal, wi=
th commentary (written outside of the actual meetings) from those dissentin=
g members.<br>
<br>By forcing their proposals through the EWG/LEWG before standardization,=
 it just makes the process take that much longer for no material gain.<br><=
/div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

<br><br></div></div></blockquote><div><br></div><div>It&#39;s not the baili=
wick of CWG or LWG to reject proposals based on design concerns, their resp=
onsibility is to review<br>the wording and make the proposals otherwise fit=
 the rest of the standard. The EWGs perform design reviews. If<br>
a SG is unsure about direction, they can present preliminary work to (L)EWG=
 as early as they wish, provided that<br>such discussions fit the schedules=
.. I very much doubt that we want to short-circuit this process, so if SGs w=
ant<br>
to speed it up, they need to come up with better proposals that answer the =
questions people have.<br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c3311233c13204dd719c5b--

.

------=_Part_173_26854900.1369380093415
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thursday, May 23, 2013 11:57:48 PM UTC-7, Daniel Kr=FCgler wrote:
>
> 2013/5/24 Nicol Bolas <jmck...@gmail.com <javascript:>>:=20
> > On Thursday, May 23, 2013 8:29:16 PM UTC-7, Nevin ":-)" Liber wrote:=20
> >>=20
> >> On May 23, 2013, at 10:18 PM, Alex B <deva...@gmail.com> wrote:=20
> >>=20
> >> > Maybe what we need is a new array class that would be almost exactly=
=20
> the=20
> >> > same as dynarray except that it would always allocate on the heap (o=
r=20
> where=20
> >> > the specified allocator actually allocates).=20
> >>=20
> >> How is that any different than vector?=20
> >=20
> > It is exactly like std::vector except that it must be created with an=
=20
> > explicit size, and it cannot be resized at all.=20
>
> This looks like a adaptor for std::vector for me, so wouldn't=20
> necessarily require a full-fledged container.=20
>

Hmm. I hadn't thought of that, but that sounds incredibly reasonable. It=20
would also by definition solve the move-ability issue, since it would be=20
adapting vector.

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_173_26854900.1369380093415
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thursday, May 23, 2013 11:57:48 PM UTC-7, Daniel Kr=FCgler wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">2013/5/24 Nicol Bolas &lt;<a href=3D"=
javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"NypXfZgFbjUJ">jmck.=
...@gmail.com</a>&gt;:
<br>&gt; On Thursday, May 23, 2013 8:29:16 PM UTC-7, Nevin ":-)" Liber wrot=
e:
<br>&gt;&gt;
<br>&gt;&gt; On May 23, 2013, at 10:18 PM, Alex B &lt;<a>deva...@gmail.com<=
/a>&gt; wrote:
<br>&gt;&gt;
<br>&gt;&gt; &gt; Maybe what we need is a new array class that would be alm=
ost exactly the
<br>&gt;&gt; &gt; same as dynarray except that it would always allocate on =
the heap (or where
<br>&gt;&gt; &gt; the specified allocator actually allocates).
<br>&gt;&gt;
<br>&gt;&gt; How is that any different than vector?
<br>&gt;
<br>&gt; It is exactly like std::vector except that it must be created with=
 an
<br>&gt; explicit size, and it cannot be resized at all.
<br>
<br>This looks like a adaptor for std::vector for me, so wouldn't
<br>necessarily require a full-fledged container.
<br></blockquote><div><br>Hmm. I hadn't thought of that, but that sounds in=
credibly reasonable. It would also by definition solve the move-ability iss=
ue, since it would be adapting vector.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_173_26854900.1369380093415--

.

--047d7bea2fdc35ee5804dd732a15
Content-Type: text/plain; charset=ISO-8859-1

On 24 May 2013 01:47, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Thursday, May 23, 2013 8:29:16 PM UTC-7, Nevin ":-)" Liber wrote:
>
>> On May 23, 2013, at 10:18 PM, Alex B <deva...@gmail.com> wrote:
>>
>> > Maybe what we need is a new array class that would be almost exactly
>> the same as dynarray except that it would always allocate on the heap (or
>> where the specified allocator actually allocates).
>>
>> How is that any different than vector?
>>
>
> It is exactly like std::vector except that it must be created with an
> explicit size, and it cannot be resized at all.
>

Why should that be a decision the callee gets to make?  Normally, it is not
any of the callee's business what one does with a returned by value object.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--047d7bea2fdc35ee5804dd732a15
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 24 May 2013 01:47, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto:j=
mckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span> wr=
ote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

On Thursday, May 23, 2013 8:29:16 PM UTC-7, Nevin &quot;:-)&quot; Liber wro=
te:<div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On May 23, 201=
3, at 10:18 PM, Alex B &lt;<a>deva...@gmail.com</a>&gt; wrote:
<br>
<br>&gt; Maybe what we need is a new array class that would be almost exact=
ly the same as dynarray except that it would always allocate on the heap (o=
r where the specified allocator actually allocates).
<br>
<br>How is that any different than vector?<br></blockquote></div><div><br>I=
t is exactly like std::vector except that it must be created with an explic=
it size, and it cannot be resized at all.</div></blockquote><div><br></div>

<div>Why should that be a decision the callee gets to make? =A0Normally, it=
 is not any of the callee&#39;s business what one does with a returned by v=
alue object.=A0</div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mai=
lto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evilo=
verlord.com</a>&gt;=A0 (847) 691-1404

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7bea2fdc35ee5804dd732a15--

.

------=_Part_215_22273055.1369387533818
Content-Type: text/plain; charset=ISO-8859-1

On Friday, May 24, 2013 2:09:24 AM UTC-7, Nevin ":-)" Liber wrote:
>
> On 24 May 2013 01:47, Nicol Bolas <jmck...@gmail.com <javascript:>> wrote:
>
>> On Thursday, May 23, 2013 8:29:16 PM UTC-7, Nevin ":-)" Liber wrote:
>>
>>> On May 23, 2013, at 10:18 PM, Alex B <deva...@gmail.com> wrote:
>>>
>>> > Maybe what we need is a new array class that would be almost exactly
>>> the same as dynarray except that it would always allocate on the heap (or
>>> where the specified allocator actually allocates).
>>>
>>> How is that any different than vector?
>>>
>>
>> It is exactly like std::vector except that it must be created with an
>> explicit size, and it cannot be resized at all.
>>
>
> Why should that be a decision the callee gets to make?  Normally, it is
> not any of the callee's business what one does with a returned by value
> object.
>

For the same reason that the callee gets to return `unique_ptr` or
`shared_ptr` for objects they allocate. The function you call dictates the
value it returns; it's part of the API design.

And again, the point of this thread is to allow such an object to be able
to be moved into a `vector` (or to move a `vector` into such an object), if
you indeed want to change the semantics of the object you're using. So the
idea is that, if you want to change the semantics (resizing vs.
no-resizing), then you can do so without copying. Just like you can
`release` a `unique_ptr` return value and stick it in a `shared_ptr` if you
want different pointer semantics.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_215_22273055.1369387533818
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Friday, May 24, 2013 2:09:24 AM UTC-7, Nevin ":-)" Liber wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;">On 24 May 2013 01:47, Nicol Bolas <span=
 dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"n8aZyBayU7sJ">jmck...@gmail.com</a>&gt;</span> wrote:<br><div clas=
s=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">

On Thursday, May 23, 2013 8:29:16 PM UTC-7, Nevin ":-)" Liber wrote:<div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex">On May 23, 2013, at 10:18 PM, Alex B =
&lt;<a>deva...@gmail.com</a>&gt; wrote:
<br>
<br>&gt; Maybe what we need is a new array class that would be almost exact=
ly the same as dynarray except that it would always allocate on the heap (o=
r where the specified allocator actually allocates).
<br>
<br>How is that any different than vector?<br></blockquote></div><div><br>I=
t is exactly like std::vector except that it must be created with an explic=
it size, and it cannot be resized at all.</div></blockquote><div><br></div>

<div>Why should that be a decision the callee gets to make? &nbsp;Normally,=
 it is not any of the callee's business what one does with a returned by va=
lue object.<br></div></div></blockquote><div><br>For the same reason that t=
he callee gets to return `unique_ptr` or `shared_ptr` for objects they allo=
cate. The function you call dictates the value it returns; it's part of the=
 API design.<br><br>And again, the point of this thread is to allow such an=
 object to be able to be moved into a `vector` (or to move a `vector` into =
such an object), if you indeed want to change the semantics of the object y=
ou're using. So the idea is that, if you want to change the semantics (resi=
zing vs. no-resizing), then you can do so without copying. Just like you ca=
n `release` a `unique_ptr` return value and stick it in a `shared_ptr` if y=
ou want different pointer semantics.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_215_22273055.1369387533818--

.

--001a11c3cdc859e27704dd769821
Content-Type: text/plain; charset=ISO-8859-1

> I happen to agree. Just because we're exploring ranges, we shouldn't punt
> simple things like array_ref
> or string-split to a far unknown future because we may or may not have
> some range solution to the
> same problems.
>

I tend to agree as well. If you look at the current standard library, there
has been std::pair for quite a while and it never prevented adding
std::tuple. We could have said "let's wait until we have tuple (if we have
it someday) before defining a pair because a pair may be defined as *template
<class T1, class T2> using pair = tuple<T1, T2>*".
So, like Nicol, I don't see why it would be a problem to add array_ref. And
since it would not use ranges, we should not rely on the SG9 group to
provide it (although their input would still be welcome).

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--001a11c3cdc859e27704dd769821
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
I happen to agree. Just because we&#39;re exploring ranges, we shouldn&#39;=
t punt simple things like array_ref<br>
</div><div class=3D"gmail_extra">or string-split to a far unknown future be=
cause we may or may not have some range solution to the<br>
same problems.</div></div></blockquote><div><br></div><div style>I tend to =
agree as well. If you look at the current standard library, there has been =
std::pair for quite a while and it never prevented adding std::tuple. We co=
uld have said &quot;let&#39;s wait until we have tuple (if we have it somed=
ay) before defining a pair because a pair may be defined as <i>template &lt=
;class T1, class T2&gt; using pair =3D tuple&lt;T1, T2&gt;</i>&quot;.</div>
<div style>So, like Nicol, I don&#39;t see why it would be a problem to add=
 array_ref. And since it would not use ranges, we should not rely on the SG=
9 group to provide it (although their input would still be welcome).</div>
</div></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c3cdc859e27704dd769821--

.

--001a11c3cdc8cf5f8f04dd7766f4
Content-Type: text/plain; charset=ISO-8859-1

> And again, the point of this thread is to allow such an object to be able
> to be moved into a `vector` (or to move a `vector` into such an object), if
> you indeed want to change the semantics of the object you're using. So the
> idea is that, if you want to change the semantics (resizing vs.
> no-resizing), then you can do so without copying. Just like you can
> `release` a `unique_ptr` return value and stick it in a `shared_ptr` if you
> want different pointer semantics.
>
> That is exactly my point. The goal is to define a way to return a
continuous data container that could be moved into *any* contiguous data
container (without making the function a template function).

We need to be able to 'release' the ownership from a vector (or any similar
user-defined container) the same way we can release the ownership from a
unique_ptr.

The adaptor idea is interesting. But I'm not sure to understand how it
would allow moving to a dynarray or any user-made container. Can
somebody elaborate?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--001a11c3cdc8cf5f8f04dd7766f4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>And again, the point of this thread is =
to allow such an object to be able to be moved into a `vector` (or to move =
a `vector` into such an object), if you indeed want to change the semantics=
 of the object you&#39;re using. So the idea is that, if you want to change=
 the semantics (resizing vs. no-resizing), then you can do so without copyi=
ng. Just like you can `release` a `unique_ptr` return value and stick it in=
 a `shared_ptr` if you want different pointer semantics.<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p></div></div></blockquote></div>That is exactly my point. The goal is=
 to define a way to return a continuous data container that could be moved =
into=A0<i>any</i>=A0contiguous data container (without making the function =
a template function).</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra" style>We ne=
ed to be able to &#39;release&#39; the ownership from a vector (or any simi=
lar user-defined container) the same way we can release the ownership from =
a unique_ptr.</div>
<div class=3D"gmail_extra" style><br></div><div class=3D"gmail_extra" style=
>The adaptor idea is interesting. But I&#39;m not sure to understand how it=
 would allow moving to a dynarray or any user-made container. Can somebody=
=A0elaborate?</div>
</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c3cdc8cf5f8f04dd7766f4--

.

--e89a8ff2511cba7ada04dd7780f9
Content-Type: text/plain; charset=ISO-8859-1

On 24 May 2013 17:13, Alex B <devalexb@gmail.com> wrote:

>
> And again, the point of this thread is to allow such an object to be able
>> to be moved into a `vector` (or to move a `vector` into such an object), if
>> you indeed want to change the semantics of the object you're using. So the
>> idea is that, if you want to change the semantics (resizing vs.
>> no-resizing), then you can do so without copying. Just like you can
>> `release` a `unique_ptr` return value and stick it in a `shared_ptr` if you
>> want different pointer semantics.
>>
>> That is exactly my point. The goal is to define a way to return a
> continuous data container that could be moved into *any* contiguous data
> container (without making the function a template function).
>
> We need to be able to 'release' the ownership from a vector (or any
> similar user-defined container) the same way we can release the ownership
> from a unique_ptr.
>
>
>
Well, some time ago I asked LWG for feedback on having buffer
adoption/releasing support added to vector and string. In general,
it depends on the allocator so much that it seems that this way of
releasing ownership from a vector
would involve an allocator that can perform the releasing.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--e89a8ff2511cba7ada04dd7780f9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 24 May 2013 17:13, Alex B <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:devalexb@gmail.com" target=3D"_blank">devalexb@gmail.com</a>&gt;</span> w=
rote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><div class=3D"im"><div class=3D"gmail_quote"><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">
<div>And again, the point of this thread is to allow such an object to be a=
ble to be moved into a `vector` (or to move a `vector` into such an object)=
, if you indeed want to change the semantics of the object you&#39;re using=
.. So the idea is that, if you want to change the semantics (resizing vs. no=
-resizing), then you can do so without copying. Just like you can `release`=
 a `unique_ptr` return value and stick it in a `shared_ptr` if you want dif=
ferent pointer semantics.<br>

</div><div><div>

<p></p></div></div></blockquote></div></div>That is exactly my point. The g=
oal is to define a way to return a continuous data container that could be =
moved into=A0<i>any</i>=A0contiguous data container (without making the fun=
ction a template function).</div>

<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">We need to =
be able to &#39;release&#39; the ownership from a vector (or any similar us=
er-defined container) the same way we can release the ownership from a uniq=
ue_ptr.</div>

<div class=3D"gmail_extra"><br><br></div></div></blockquote><div><br></div>=
<div>Well, some time ago I asked LWG for feedback on having buffer adoption=
/releasing support added to vector and string. In general,<br>it depends on=
 the allocator so much that it seems that this way of releasing ownership f=
rom a vector<br>
would involve an allocator that can perform the releasing. <br></div></div>=
<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--e89a8ff2511cba7ada04dd7780f9--

.

--e89a8f83a6593cb68904dd77e00f
Content-Type: text/plain; charset=ISO-8859-1

So when releasing a vector, the caller would also have to carry along the
allocator and make sure to use the allocator to delete the data later on.

To me, it is as dangerous as releasing a unique_ptr having a custom
deleter, so it does not seem like a show stopper to me.

One (possible) way to go around it in a safer way would be to have a
vector::release method that would return a unique_ptr with a custom
deleter. That custom deleter would actually use the allocator to delete.


On Fri, May 24, 2013 at 10:20 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

>
>
>
> On 24 May 2013 17:13, Alex B <devalexb@gmail.com> wrote:
>
>>
>> And again, the point of this thread is to allow such an object to be able
>>> to be moved into a `vector` (or to move a `vector` into such an object), if
>>> you indeed want to change the semantics of the object you're using. So the
>>> idea is that, if you want to change the semantics (resizing vs.
>>> no-resizing), then you can do so without copying. Just like you can
>>> `release` a `unique_ptr` return value and stick it in a `shared_ptr` if you
>>> want different pointer semantics.
>>>
>>> That is exactly my point. The goal is to define a way to return a
>> continuous data container that could be moved into *any* contiguous data
>> container (without making the function a template function).
>>
>> We need to be able to 'release' the ownership from a vector (or any
>> similar user-defined container) the same way we can release the ownership
>> from a unique_ptr.
>>
>>
>>
> Well, some time ago I asked LWG for feedback on having buffer
> adoption/releasing support added to vector and string. In general,
> it depends on the allocator so much that it seems that this way of
> releasing ownership from a vector
> would involve an allocator that can perform the releasing.
>
>  --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/q7fOf5JUknk/unsubscribe?hl=en
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>
>
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--e89a8f83a6593cb68904dd77e00f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">So when releasing a vector, the caller would also have to =
carry along the allocator and make sure to use the allocator to delete the =
data later on.<div><br></div><div style>To me, it is as dangerous as releas=
ing a unique_ptr having a custom deleter, so it does not seem like a show s=
topper to me.</div>
<div style><br></div><div style>One (possible) way to go=A0around=A0it in a=
 safer way would be to have a vector::release method that would return a un=
ique_ptr with a custom deleter. That custom deleter would actually use the =
allocator to delete.</div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Fri,=
 May 24, 2013 at 10:20 AM, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=
=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen=
@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote"><div class=3D"im">On 24 May 2013 17:=
13, Alex B <span dir=3D"ltr">&lt;<a href=3D"mailto:devalexb@gmail.com" targ=
et=3D"_blank">devalexb@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>And again, the point of this thread is to allow such an object to be a=
ble to be moved into a `vector` (or to move a `vector` into such an object)=
, if you indeed want to change the semantics of the object you&#39;re using=
.. So the idea is that, if you want to change the semantics (resizing vs. no=
-resizing), then you can do so without copying. Just like you can `release`=
 a `unique_ptr` return value and stick it in a `shared_ptr` if you want dif=
ferent pointer semantics.<br>


</div><div><div>

<p></p></div></div></blockquote></div></div>That is exactly my point. The g=
oal is to define a way to return a continuous data container that could be =
moved into=A0<i>any</i>=A0contiguous data container (without making the fun=
ction a template function).</div>


<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">We need to =
be able to &#39;release&#39; the ownership from a vector (or any similar us=
er-defined container) the same way we can release the ownership from a uniq=
ue_ptr.</div>


<div class=3D"gmail_extra"><br><br></div></div></blockquote><div><br></div>=
</div><div>Well, some time ago I asked LWG for feedback on having buffer ad=
option/releasing support added to vector and string. In general,<br>it depe=
nds on the allocator so much that it seems that this way of releasing owner=
ship from a vector<br>

would involve an allocator that can perform the releasing. <br></div></div>=
<br></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/q7fOf5JUknk/unsubscribe?hl=3Den" target=
=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/q7=
fOf5JUknk/unsubscribe?hl=3Den</a>.<br>

To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
=A0<br>
=A0<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--e89a8f83a6593cb68904dd77e00f--

.

--bcaec53f907bcf5e9604dd77e853
Content-Type: text/plain; charset=ISO-8859-1

On 24 May 2013 04:25, Nicol Bolas <jmckesson@gmail.com> wrote:

> For the same reason that the callee gets to return `unique_ptr` or
> `shared_ptr` for objects they allocate. The function you call dictates the
> value it returns; it's part of the API design.
>

But one doesn't try to limit what the caller can do with the result.  It
would be more like returning a unique_ptr where the caller wasn't allowed
to put it into a shared_ptr if he so desired.

If you really want the adaptor:

template<typename... Ts>
using silly_vector_adaptor  = const std::vector<Ts...>;

Callee uses a vector internally and returns silly_vector_adaptor.  Problem
solved.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--bcaec53f907bcf5e9604dd77e853
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 24 May 2013 04:25, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto:j=
mckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span> wr=
ote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>For the same reason that the callee gets to return `unique_ptr` or `sh=
ared_ptr` for objects they allocate. The function you call dictates the val=
ue it returns; it&#39;s part of the API design.<br></div></blockquote>
<div>
<br></div><div>But one doesn&#39;t try to limit what the caller can do with=
 the result. =A0It would be more like returning a unique_ptr where the call=
er wasn&#39;t allowed to put it into a shared_ptr if he so desired.=A0</div=
>

<div><br></div><div>If you really want the adaptor:</div><div><br></div><di=
v>template&lt;typename... Ts&gt;</div><div>using silly_vector_adaptor =A0=
=3D const std::vector&lt;Ts...&gt;;</div><div><br></div><div>Callee uses a =
vector internally and returns silly_vector_adaptor. =A0Problem solved.</div=
>

</div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto=
:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=
=A0 (847) 691-1404

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--bcaec53f907bcf5e9604dd77e853--

.

--e89a8f83a6591210dd04dd78abed
Content-Type: text/plain; charset=ISO-8859-1

The goal is exactly the opposite; it is not to limit what the caller can do
with the result but actually allow him to do what he wants *without the
need to copy the result*.

Consider that you have to implement the following function in a specific
library:

MyVectorType<int> MyFunction();

Just consider MyVectorType to be very similar to std::vector (contiguous
array). A lot of projects/libraries do implement their own container types
(I'll let you judge if it's a good or a bad thing but the point is that it
actually happens in real life).

Now, it just happens that internally, you want to call the following
function to do the job and just *move* the result in the returned value :

vector<int> AnotherFunctionInAnotherLibrary();

MyVectorType<int> MyFunction()
{
   return AnotherFunctionInAnotherLibrary();
}

Right now (and with the said adaptor that would "solve the problem"), you
can only *copy* the result in the return value (in my example I assume
there is a constructor doing it). You currently cannot move (transfer
ownership of) a vector into any other type (including dynarray), and *that* is
the problem.


On Fri, May 24, 2013 at 10:49 AM, Nevin Liber <nevin@eviloverlord.com>wrote:

> On 24 May 2013 04:25, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>> For the same reason that the callee gets to return `unique_ptr` or
>> `shared_ptr` for objects they allocate. The function you call dictates the
>> value it returns; it's part of the API design.
>>
>
> But one doesn't try to limit what the caller can do with the result.  It
> would be more like returning a unique_ptr where the caller wasn't allowed
> to put it into a shared_ptr if he so desired.
>
> If you really want the adaptor:
>
> template<typename... Ts>
> using silly_vector_adaptor  = const std::vector<Ts...>;
>
> Callee uses a vector internally and returns silly_vector_adaptor.  Problem
> solved.
> --
>  Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/q7fOf5JUknk/unsubscribe?hl=en
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>
>
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--e89a8f83a6591210dd04dd78abed
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The goal is exactly the opposite; it is not to limit what =
the caller can do with the result but actually allow him to do what he want=
s <b>without the need to copy the result</b>.<div><br></div><div style>Cons=
ider that you have to implement the following function in a specific librar=
y:</div>
<div style><br></div><div style><font face=3D"courier new, monospace">MyVec=
torType&lt;int&gt; MyFunction();</font></div><div style><br></div><div styl=
e>Just consider MyVectorType to be very similar to std::vector (contiguous =
array). A lot of projects/libraries do implement their own container types =
(I&#39;ll let you judge if it&#39;s a good or a bad thing but the point is =
that it actually happens in real life).</div>
<div style><br></div><div style>Now, it just happens that internally, you w=
ant to call the following function to do the job and just <b>move</b> the r=
esult in the returned value :</div><div style><br></div><div style><font fa=
ce=3D"courier new, monospace">vector&lt;int&gt; AnotherFunctionInAnotherLib=
rary();</font></div>
<div style><font face=3D"courier new, monospace"><br></font></div><div styl=
e><span style=3D"font-family:&#39;courier new&#39;,monospace">MyVectorType&=
lt;int&gt; MyFunction()</span><font face=3D"courier new, monospace"><br></f=
ont></div>
<div style><span style=3D"font-family:&#39;courier new&#39;,monospace">{</s=
pan></div><div style><span style=3D"font-family:&#39;courier new&#39;,monos=
pace">=A0 =A0return=A0</span><span style=3D"font-family:&#39;courier new&#3=
9;,monospace">AnotherFunctionInAnotherLibrary();</span></div>
<div style><span style=3D"font-family:&#39;courier new&#39;,monospace">}</s=
pan></div><div style><br></div><div style>Right now (and with the said adap=
tor that would &quot;solve the problem&quot;), you can only <b>copy</b>=A0t=
he result in the return value (in my example I assume there is a constructo=
r doing it). You currently cannot move (transfer ownership of) a vector int=
o any other type (including dynarray), and <i>that</i>=A0is the problem.</d=
iv>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Fri,=
 May 24, 2013 at 10:49 AM, Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt=
;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 24 May 2013 04:25, Nico=
l Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=
=3D"_blank">jmckesson@gmail.com</a>&gt;</span> wrote:<br>
</div><div class=3D"gmail_quote"><div class=3D"im"><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">

<div>For the same reason that the callee gets to return `unique_ptr` or `sh=
ared_ptr` for objects they allocate. The function you call dictates the val=
ue it returns; it&#39;s part of the API design.<br></div></blockquote>

<div>
<br></div></div><div>But one doesn&#39;t try to limit what the caller can d=
o with the result. =A0It would be more like returning a unique_ptr where th=
e caller wasn&#39;t allowed to put it into a shared_ptr if he so desired.=
=A0</div>


<div><br></div><div>If you really want the adaptor:</div><div><br></div><di=
v>template&lt;typename... Ts&gt;</div><div>using silly_vector_adaptor =A0=
=3D const std::vector&lt;Ts...&gt;;</div><div><br></div><div>Callee uses a =
vector internally and returns silly_vector_adaptor. =A0Problem solved.</div=
>


</div><div class=3D"im">-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto=
:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evilover=
lord.com</a>&gt;=A0 <a href=3D"tel:%28847%29%20691-1404" value=3D"+18476911=
404" target=3D"_blank">(847) 691-1404</a>

<p></p></div>

-- <br><div class=3D"HOEnZb"><div class=3D"h5">
=A0<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/q7fOf5JUknk/unsubscribe?hl=3Den" target=
=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/q7=
fOf5JUknk/unsubscribe?hl=3Den</a>.<br>

To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
=A0<br>
=A0<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--e89a8f83a6591210dd04dd78abed--

.

--001a11c35aca33f39404dd7905d8
Content-Type: text/plain; charset=ISO-8859-1

On 24 May 2013 10:44, Alex B <devalexb@gmail.com> wrote:

> The goal is exactly the opposite; it is not to limit what the caller can
> do with the result but actually allow him to do what he wants *without
> the need to copy the result*.
>

1.  I have no idea what it means to move between two unrelated types.

2.  The stated invariant was that the size of the container couldn't change
after construction.  I have no idea how you implement an efficient move and
maintain that invariant.

3.  People concerned about performance when returning expensive data
structures tend to concentrate on RVO first and then r-value references.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--001a11c35aca33f39404dd7905d8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 24 May 2013 10:44, Alex B <span dir=3D"ltr">&lt;<a href=3D"mailto:devale=
xb@gmail.com" target=3D"_blank">devalexb@gmail.com</a>&gt;</span> wrote:<br=
><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr">The goal is exactly the opposite; it is not to limit what =
the caller can do with the result but actually allow him to do what he want=
s <b>without the need to copy the result</b>.</div></blockquote><div><br>

</div><div>1. =A0I have no idea what it means to move between two unrelated=
 types.</div><div><br></div><div>2. =A0The stated invariant was that the si=
ze of the container couldn&#39;t change after construction. =A0I have no id=
ea how you implement an efficient move and maintain that invariant.</div>

<div><br></div><div>3. =A0People concerned about performance when returning=
 expensive data structures tend to concentrate on RVO first and then r-valu=
e references.</div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailt=
o:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evilove=
rlord.com</a>&gt;=A0 (847) 691-1404

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c35aca33f39404dd7905d8--

.

--e89a8f838e89bc301e04dd79f17f
Content-Type: text/plain; charset=ISO-8859-1

> 1.  I have no idea what it means to move between two unrelated types.
>
>
You can call it "transfer ownership" instead of "move" if you prefer. Just
consider this:

   template <class T>
   class MyVectorType
   {
   ...
   public:
      ...
      MyVectorType(vector<T>&& other) { ??? } // cannot currently be
implemented properly without being a friend of vector
      ...
   };

   vector<int> vec;
   ...
   MyVectorType<int> myvec{*move*(vec)};



> 2.  The stated invariant was that the size of the container couldn't
> change after construction.  I have no idea how you implement an efficient
> move and maintain that invariant.
>
>
The goal is not to maintain that invariant. The invariant is only valid
with the semantic of the current owning object. If the ownership
is transferred back to a vector, yes, the invariant is lost but I don't see
the problem.

3.  People concerned about performance when returning expensive data
> structures tend to concentrate on RVO first and then r-value references.
>
>
Please explain how I could benefit from RVO if two types are involved
(vector vs MyVectorType). Can you correct the example in my previous post
to benefit from RVO? (without changing the return types of the functions,
which are imposed in this context)

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--e89a8f838e89bc301e04dd79f17f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"gmail_quote"><div>1. =A0I have=
 no idea what it means to move between two unrelated types.</div>
<div><br></div></div></blockquote><div><br></div><div style>You can call it=
 &quot;transfer ownership&quot; instead of &quot;move&quot; if you prefer. =
Just consider this:</div><div style><br></div><div style><font face=3D"cour=
ier new, monospace">=A0 =A0template &lt;class T&gt;</font></div>
<div style><font face=3D"courier new, monospace">=A0 =A0class MyVectorType<=
/font></div><div style><font face=3D"courier new, monospace">=A0 =A0{</font=
></div><div style><font face=3D"courier new, monospace">=A0 =A0...</font></=
div><div style>
<font face=3D"courier new, monospace">=A0 =A0public:</font></div><div style=
><font face=3D"courier new, monospace">=A0 =A0 =A0 ...</font></div><div sty=
le><font face=3D"courier new, monospace">=A0 =A0 =A0 MyVectorType(vector&lt=
;T&gt;&amp;&amp; other) { ??? } // cannot currently be implemented properly=
 without being a friend of vector</font></div>
<div style><font face=3D"courier new, monospace">=A0 =A0 =A0 ...</font></di=
v><div style><font face=3D"courier new, monospace">=A0 =A0};</font></div><d=
iv style><font face=3D"courier new, monospace"><br></font></div><div style>=
<font face=3D"courier new, monospace">=A0 =A0vector&lt;int&gt; vec;</font><=
/div>
<div style><font face=3D"courier new, monospace">=A0 =A0...</font></div><di=
v style><font face=3D"courier new, monospace">=A0 =A0MyVectorType&lt;int&gt=
; myvec{<b><u>move</u></b>(vec)};</font></div><div style><br></div><div>=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">
<div class=3D"gmail_quote"><div></div><div>2. =A0The stated invariant was t=
hat the size of the container couldn&#39;t change after construction. =A0I =
have no idea how you implement an efficient move and maintain that invarian=
t.</div>


<div><br></div></div></blockquote><div>=A0</div><div style>The goal is not =
to maintain that invariant. The invariant is only valid with the semantic o=
f the current owning object. If the ownership is=A0transferred=A0back to a =
vector, yes, the invariant is lost but I don&#39;t see the problem.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_quote"><d=
iv></div><div>3. =A0People concerned about performance when returning expen=
sive data structures tend to concentrate on RVO first and then r-value refe=
rences.</div>
</div><div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote>=
<div><br></div><div style>Please explain how I could benefit from RVO if tw=
o types are involved (vector vs MyVectorType). Can you correct the example =
in my previous post to benefit from RVO? (without changing the return types=
 of the functions, which are imposed in this context)</div>
</div></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--e89a8f838e89bc301e04dd79f17f--

.

--047d7bdc122003e25504dd7a5a93
Content-Type: text/plain; charset=ISO-8859-1

On 24 May 2013 12:15, Alex B <devalexb@gmail.com> wrote:

>
> 1.  I have no idea what it means to move between two unrelated types.
>>
>>
> You can call it "transfer ownership" instead of "move" if you prefer.
>

You can only "transfer ownership" if you have access to the "guts" of the
container.  unique_ptr, for instance, exposes all its "guts" (the pointer
and the deleter) so that shared_ptr can take it.

This just isn't true for different containers, even if they contain
contiguous storage, as they may have *different* underlying representations
of the data.  For instance, a vector<char> may have the size of the vector
embedded in vector member variables while std::string may have the size of
the string embedded in the heap block.

How would you make "move" work between vector<char> and string, without
nailing down the implementation?  It's the same problem...

 2.  The stated invariant was that the size of the container couldn't
>> change after construction.  I have no idea how you implement an efficient
>> move and maintain that invariant.
>>
>>
> The goal is not to maintain that invariant.
>

If that isn't an invariant, then how does it differ from vector?

People ask for this kind of invariant breaking thing all the time; it
usually comes in the form of "I want member variables that are references
and I want const member variables, but I also want assignment to work."


> --
>
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--047d7bdc122003e25504dd7a5a93
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 24 May 2013 12:15, Alex B <span dir=3D"ltr">&lt;<a href=3D"mailto:devale=
xb@gmail.com" target=3D"_blank">devalexb@gmail.com</a>&gt;</span> wrote:<br=
><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_quote"=
><div>1. =A0I have no idea what it means to move between two unrelated type=
s.</div>


<div><br></div></div></blockquote><div><br></div></div><div>You can call it=
 &quot;transfer ownership&quot; instead of &quot;move&quot; if you prefer. =
</div></div></div></div></blockquote><div><br></div><div>You can only &quot=
;transfer ownership&quot; if you have access to the &quot;guts&quot; of the=
 container. =A0unique_ptr, for instance, exposes all its &quot;guts&quot; (=
the pointer and the deleter) so that shared_ptr can take it.</div>

<div><br></div><div>This just isn&#39;t true for different containers, even=
 if they contain contiguous storage, as they may have *different* underlyin=
g representations of the data. =A0For instance, a vector&lt;char&gt; may ha=
ve the size of the vector embedded in vector member variables while std::st=
ring may have the size of the string embedded in the heap block.</div>

<div><br></div><div>How would you make &quot;move&quot; work between vector=
&lt;char&gt; and string, without nailing down the implementation? =A0It&#39=
;s the same problem...</div><div><br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
 class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"gmail_quote"><div></div><div>2. =A0The stated invariant was t=
hat the size of the container couldn&#39;t change after construction. =A0I =
have no idea how you implement an efficient move and maintain that invarian=
t.</div>




<div><br></div></div></blockquote><div>=A0</div></div><div>The goal is not =
to maintain that invariant. </div></div></div></div></blockquote><div><br><=
/div><div>If that isn&#39;t an invariant, then how does it differ from vect=
or?</div>

<div><br></div><div>People ask for this kind of invariant breaking thing al=
l the time; it usually comes in the form of &quot;I want member variables t=
hat are references and I want const member variables, but I also want assig=
nment to work.&quot;</div>

<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D=
"gmail_extra"><div class=3D"gmail_quote"><div>--=A0</div></div></div></div>=
</blockquote>

</div>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin@=
eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 (847)=
 691-1404

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7bdc122003e25504dd7a5a93--

.

------=_Part_557_21199848.1369420005027
Content-Type: text/plain; charset=ISO-8859-1

On Friday, May 24, 2013 7:13:22 AM UTC-7, Alex B wrote:
>
>
> And again, the point of this thread is to allow such an object to be able
>> to be moved into a `vector` (or to move a `vector` into such an object), if
>> you indeed want to change the semantics of the object you're using. So the
>> idea is that, if you want to change the semantics (resizing vs.
>> no-resizing), then you can do so without copying. Just like you can
>> `release` a `unique_ptr` return value and stick it in a `shared_ptr` if you
>> want different pointer semantics.
>>
>> That is exactly my point. The goal is to define a way to return a
> continuous data container that could be moved into *any* contiguous data
> container (without making the function a template function).
>

That's a very *different* goal, one that is highly unlikely to be able to
work in the general case. The goal you originally suggested was between
`vector` and `dynarray`, which are two very specific classes with known
implementations. That's different from saying "any contiguous data
container".

We need to be able to 'release' the ownership from a vector (or any similar
> user-defined container) the same way we can release the ownership from a
> unique_ptr.
>

You can't release the memory owned by a vector because that memory *isn't
owned by the vector*. It's owned by the *allocator* for the vector. To
properly free it, you must have 4 pieces of information:

1. A pointer to the memory.

2. The type of data allocated (ie: the `T` that
allocator_traits<allocator<T>>::allocate was called on.

3. The number of elements (the capacity).

4. The allocator itself.

That's why what you suggest can't work in the general case. You can require
`vector` and `dynarray` to be transferable into one-another (allocator
willing). But you can't require that you can just extract the guts out of a
vector and deallocate it yourself.

The adaptor idea is interesting. But I'm not sure to understand how it
> would allow moving to a dynarray or any user-made container. Can
> somebody elaborate?
>

It wouldn't, nor was either of those things the point of the suggestion.
The adapter class idea came up in a side conversation about what a "new
array class that would be almost exactly the same as dynarray except that
it would always allocate on the heap" would look like. Such a class would
look a lot like dynarray, but it wouldn't have the same effect (since it's
always heap allocator). It would be exactly like `std::vector`, except that
it's missing certain operations. Hence the notion of it being an "adapter".

Personally, I don't see the need for `vector` to be a template parameter
type or anything. It could simply be a class that is said to work as if it
were written in terms of `vector`, with appropriate move into and out of
support.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_557_21199848.1369420005027
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Friday, May 24, 2013 7:13:22 AM UTC-7, Alex B wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr"><br><div><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div>And again, the point of this thread =
is to allow such an object to be able to be moved into a `vector` (or to mo=
ve a `vector` into such an object), if you indeed want to change the semant=
ics of the object you're using. So the idea is that, if you want to change =
the semantics (resizing vs. no-resizing), then you can do so without copyin=
g. Just like you can `release` a `unique_ptr` return value and stick it in =
a `shared_ptr` if you want different pointer semantics.<br>
</div><div><div>

<p></p></div></div></blockquote></div>That is exactly my point. The goal is=
 to define a way to return a continuous data container that could be moved =
into&nbsp;<i>any</i>&nbsp;contiguous data container (without making the fun=
ction a template function).</div></div></blockquote><div><br>That's a very =
<i>different</i> goal, one that is highly unlikely to be able to work in th=
e general case. The goal you originally suggested was between `vector` and =
`dynarray`, which are two very specific classes with known implementations.=
 That's different from saying "any contiguous data container".<br><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">
<div></div><div>We need to be able to 'release' the ownership from a vector=
 (or any similar user-defined container) the same way we can release the ow=
nership from a unique_ptr.</div></div></blockquote><div><br>You can't relea=
se the memory owned by a vector because that memory <i>isn't owned by the v=
ector</i>. It's owned by the <i>allocator</i> for the vector. To properly f=
ree it, you must have 4 pieces of information:<br><br>1. A pointer to the m=
emory.<br><br>2. The type of data allocated (ie: the `T` that allocator_tra=
its&lt;allocator&lt;T&gt;&gt;::allocate was called on.<br><br>3. The number=
 of elements (the capacity).<br><br>4. The allocator itself.<br><br>That's =
why what you suggest can't work in the general case. You can require `vecto=
r` and `dynarray` to be transferable into one-another (allocator willing). =
But you can't require that you can just extract the guts out of a vector an=
d deallocate it yourself.<br><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr"><div>The adaptor idea is interesting. But I'm not=
 sure to understand how it would allow moving to a dynarray or any user-mad=
e container. Can somebody&nbsp;elaborate?</div></div></blockquote><div><br>=
It wouldn't, nor was either of those things the point of the suggestion. Th=
e adapter class idea came up in a side conversation about what a "new array=
 class that would be almost exactly the same as dynarray except that it wou=
ld always allocate on the heap" would look like. Such a class would look a =
lot like dynarray, but it wouldn't have the same effect (since it's always =
heap allocator). It would be exactly like `std::vector`, except that it's m=
issing certain operations. Hence the notion of it being an "adapter".<br><b=
r>Personally, I don't see the need for `vector` to be a template parameter =
type or anything. It could simply be a class that is said to work as if it =
were written in terms of `vector`, with appropriate move into and out of su=
pport.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_557_21199848.1369420005027--

.

------=_Part_617_2457276.1369420384366
Content-Type: text/plain; charset=ISO-8859-1

On Friday, May 24, 2013 7:47:19 AM UTC-7, Alex B wrote:
>
> So when releasing a vector, the caller would also have to carry along the
> allocator and make sure to use the allocator to delete the data later on.
>
> To me, it is as dangerous as releasing a unique_ptr having a custom
> deleter, so it does not seem like a show stopper to me.
>
> One (possible) way to go around it in a safer way would be to have a
> vector::release method that would return a unique_ptr with a custom
> deleter. That custom deleter would actually use the allocator to delete.
>

And how would this help exactly? You lose *all* of the useful parts of
being a vector (no size information, no range begin/end support, etc). All
you gain is a unique_ptr to some block of data.

You wouldn't be able to stick it in anything without having explicit
knowledge of how the deleter class works. Even if the deleter class's
functionality was specified, the receiving object would have to adopt the
allocator.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_617_2457276.1369420384366
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Friday, May 24, 2013 7:47:19 AM UTC-7, Alex B wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr">So when releasing a vector, the c=
aller would also have to carry along the allocator and make sure to use the=
 allocator to delete the data later on.<div><br></div><div>To me, it is as =
dangerous as releasing a unique_ptr having a custom deleter, so it does not=
 seem like a show stopper to me.</div>
<div><br></div><div>One (possible) way to go&nbsp;around&nbsp;it in a safer=
 way would be to have a vector::release method that would return a unique_p=
tr with a custom deleter. That custom deleter would actually use the alloca=
tor to delete.</div></div></blockquote><div><br>And how would this help exa=
ctly? You lose <i>all</i> of the useful parts of being a vector (no size in=
formation, no range begin/end support, etc). All you gain is a unique_ptr t=
o some block of data.<br><br>You wouldn't be able to stick it in anything w=
ithout having explicit knowledge of how the deleter class works. Even if th=
e deleter class's functionality was specified, the receiving object would h=
ave to adopt the allocator.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_617_2457276.1369420384366--

.

--bcaec53f907b769fd704dd7b3463
Content-Type: text/plain; charset=ISO-8859-1

On 24 May 2013 01:45, Nicol Bolas <jmckesson@gmail.com> wrote:

>
> Well, maybe that's part of the problem.
>
> If a particular committee member did not get involved in the primary
> discussion for a particular proposal, then they should not be able to delay
> the process by asking questions *later* about it. If the rest of the
> committee, who did decide to incorporate it, decided that it was ready to
> go, it shouldn't stop because of a couple of people who weren't there for
> the main discussion.
>
> Think of it as a "speak now or forever hold your peace" kind of thing.
> This would make the process more efficient, as we would know when the
> discussion phase for a proposal has begun and ended. There would be a clear
> record of the discussion, so that later groups can read the discussions and
> see what points have been dealt with (the minutes that I've seen from
> meetings thus far don't seem to work as a record of significant issues for
> discussion. I couldn't even find the record for when the array_ref proposal
> was rejected, let along the criticisms for it).
>

But the record doesn't matter.  If we follow your "speak now or forever
hold your peace" advice, then the committee has already spoken and
array_ref will never be part of the standard.  You can't have it both ways.

(The record is on the committee wiki, but it isn't terribly enlightening on
why it was rejected.)
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--bcaec53f907b769fd704dd7b3463
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On 24 May 2013 01:45, Nicol Bolas <span dir=3D"l=
tr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@=
gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"im"><br></div><div>Well, maybe that&#39;s part of the problem=
..<br><br>If a particular committee member did not get involved in the prima=
ry discussion for a particular proposal, then they should not be able to de=
lay the process by asking questions <i>later</i> about it. If the rest of t=
he committee, who did decide to incorporate it, decided that it was ready t=
o go, it shouldn&#39;t stop because of a couple of people who weren&#39;t t=
here for the main discussion.<br>

<br>Think of it as a &quot;speak now or forever hold your peace&quot; kind =
of thing. This would make the process more efficient, as we would know when=
 the discussion phase for a proposal has begun and ended. There would be a =
clear record of the discussion, so that later groups can read the discussio=
ns and see what points have been dealt with (the minutes that I&#39;ve seen=
 from meetings thus far don&#39;t seem to work as a record of significant i=
ssues for discussion. I couldn&#39;t even find the record for when the arra=
y_ref proposal was rejected, let along the criticisms for it).<br>

</div></blockquote><div><br></div><div>But the record doesn&#39;t matter. =
=A0If we follow your &quot;speak now or forever hold your peace&quot; advic=
e, then the committee has already spoken and array_ref will never be part o=
f the standard. =A0You can&#39;t have it both ways.</div>

<div><br></div><div>(The record is on the committee wiki, but it isn&#39;t =
terribly enlightening on why it was rejected.)</div><div>--=A0</div></div>=
=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin@evilov=
erlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 (847) 691-1=
404

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--bcaec53f907b769fd704dd7b3463--

.

------=_Part_584_7069613.1369422876526
Content-Type: text/plain; charset=ISO-8859-1

On Friday, May 24, 2013 11:44:57 AM UTC-7, Nevin ":-)" Liber wrote:
>
> On 24 May 2013 01:45, Nicol Bolas <jmck...@gmail.com <javascript:>> wrote:
>
>>
>> Well, maybe that's part of the problem.
>>
>> If a particular committee member did not get involved in the primary
>> discussion for a particular proposal, then they should not be able to delay
>> the process by asking questions *later* about it. If the rest of the
>> committee, who did decide to incorporate it, decided that it was ready to
>> go, it shouldn't stop because of a couple of people who weren't there for
>> the main discussion.
>>
>> Think of it as a "speak now or forever hold your peace" kind of thing.
>> This would make the process more efficient, as we would know when the
>> discussion phase for a proposal has begun and ended. There would be a clear
>> record of the discussion, so that later groups can read the discussions and
>> see what points have been dealt with (the minutes that I've seen from
>> meetings thus far don't seem to work as a record of significant issues for
>> discussion. I couldn't even find the record for when the array_ref proposal
>> was rejected, let along the criticisms for it).
>>
>
> But the record doesn't matter.  If we follow your "speak now or forever
> hold your peace" advice, then the committee has already spoken and
> array_ref will never be part of the standard.  You can't have it both ways.
>

That's not what I said. What I said was that there would be a period of
discussion that happens outside of meetings, and that there would be *no*discussion during meetings. At the meetings, the actual proposal would
either be voted in or not. So you either speak at the discussion part, or
you don't speak at all.

That doesn't mean that a proposal can't come back in a later meeting, after
another round of discussion and revision.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_584_7069613.1369422876526
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Friday, May 24, 2013 11:44:57 AM UTC-7, Nevin ":-)" Liber wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div class=3D"gmail_quote">On 24 May 2=
013 01:45, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"s-2cLgopWB0J">jmck...@gmail.com</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><br></div><div>Well, maybe that's part of the problem.<br><br>If a par=
ticular committee member did not get involved in the primary discussion for=
 a particular proposal, then they should not be able to delay the process b=
y asking questions <i>later</i> about it. If the rest of the committee, who=
 did decide to incorporate it, decided that it was ready to go, it shouldn'=
t stop because of a couple of people who weren't there for the main discuss=
ion.<br>

<br>Think of it as a "speak now or forever hold your peace" kind of thing. =
This would make the process more efficient, as we would know when the discu=
ssion phase for a proposal has begun and ended. There would be a clear reco=
rd of the discussion, so that later groups can read the discussions and see=
 what points have been dealt with (the minutes that I've seen from meetings=
 thus far don't seem to work as a record of significant issues for discussi=
on. I couldn't even find the record for when the array_ref proposal was rej=
ected, let along the criticisms for it).<br>

</div></blockquote><div><br></div><div>But the record doesn't matter. &nbsp=
;If we follow your "speak now or forever hold your peace" advice, then the =
committee has already spoken and array_ref will never be part of the standa=
rd. &nbsp;You can't have it both ways.</div></div></blockquote><div><br>Tha=
t's not what I said. What I said was that there would be a period of discus=
sion that happens outside of meetings, and that there would be <i>no</i> di=
scussion during meetings. At the meetings, the actual proposal would either=
 be voted in or not. So you either speak at the discussion part, or you don=
't speak at all.<br><br>That doesn't mean that a proposal can't come back i=
n a later meeting, after another round of discussion and revision.</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_584_7069613.1369422876526--

.

--047d7b2e08876a984104dd7bab6c
Content-Type: text/plain; charset=ISO-8859-1

On 24 May 2013 21:33, Nicol Bolas <jmckesson@gmail.com> wrote:

>
>
>> One (possible) way to go around it in a safer way would be to have a
>> vector::release method that would return a unique_ptr with a custom
>> deleter. That custom deleter would actually use the allocator to delete.
>>
>
> And how would this help exactly? You lose *all* of the useful parts of
> being a vector (no size information, no range begin/end support, etc). All
> you gain is a unique_ptr to some block of data.
>

You won't be able to stick it into anything anyway if you don't know how
the deleter works, or you need to at least
pass the deleter along with it.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--047d7b2e08876a984104dd7bab6c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 24 May 2013 21:33, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div class=3D"im"><br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex">
<div dir=3D"ltr">
<div><br></div><div>One (possible) way to go=A0around=A0it in a safer way w=
ould be to have a vector::release method that would return a unique_ptr wit=
h a custom deleter. That custom deleter would actually use the allocator to=
 delete.</div>
</div></blockquote></div><div><br>And how would this help exactly? You lose=
 <i>all</i> of the useful parts of being a vector (no size information, no =
range begin/end support, etc). All you gain is a unique_ptr to some block o=
f data.<br>
</div></blockquote><div><br><div>You won&#39;t be able to stick it into any=
thing anyway if you don&#39;t know how the deleter works, or you need to at=
 least<br>pass the deleter along with it.=A0 </div></div></div><br></div>
</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b2e08876a984104dd7bab6c--

.

--047d7b2e088713df4b04dd7bb42c
Content-Type: text/plain; charset=ISO-8859-1

On 24 May 2013 22:14, Nicol Bolas <jmckesson@gmail.com> wrote:

>
> That's not what I said. What I said was that there would be a period of
> discussion that happens outside of meetings, and that there would be *no*discussion during meetings. At the meetings, the actual proposal would
> either be voted in or not. So you either speak at the discussion part, or
> you don't speak at all.
>
>
Ok, in the imaginary world where this approach is adopted, I will vote
against every proposal.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--047d7b2e088713df4b04dd7bb42c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 24 May 2013 22:14, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><div>That&#39;s not what I said. What I =
said was that there would be a period of discussion that happens outside of=
 meetings, and that there would be <i>no</i> discussion during meetings. At=
 the meetings, the actual proposal would either be voted in or not. So you =
either speak at the discussion part, or you don&#39;t speak at all.<br>
<br></div></blockquote><div><br></div><div>Ok, in the imaginary world where=
 this approach is adopted, I will vote against every proposal. <br></div></=
div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b2e088713df4b04dd7bb42c--

.

--001a11c35aca45663104dd7bb844
Content-Type: text/plain; charset=ISO-8859-1

On 24 May 2013 14:14, Nicol Bolas <jmckesson@gmail.com> wrote:

>
>
> That's not what I said. What I said was that there would be a period of
> discussion that happens outside of meetings, and that there would be *no*discussion during meetings. At the meetings, the actual proposal would
> either be voted in or not. So you either speak at the discussion part, or
> you don't speak at all.
>

That seems *less* efficient to me, as people tend to vote "no" when their
concerns aren't addressed, thus making proposals stretch over many meetings
(if they ever get voted in at all).  Discussion is the whole point of face
to face meetings.

For instance, while std::optional was extensively discussed outside of the
meeting, I am very sure it *never* would have been voted in were it not for
the face to face discussions at Bristol.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--001a11c35aca45663104dd7bb844
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 24 May 2013 14:14, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto:j=
mckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span> wr=
ote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br><div><br>That&#39;s not what I said. What I said was that there would b=
e a period of discussion that happens outside of meetings, and that there w=
ould be <i>no</i> discussion during meetings. At the meetings, the actual p=
roposal would either be voted in or not. So you either speak at the discuss=
ion part, or you don&#39;t speak at all.<br>

</div></blockquote><div><br>That seems *less* efficient to me, as people te=
nd to vote &quot;no&quot; when their concerns aren&#39;t addressed, thus ma=
king proposals stretch over many meetings (if they ever get voted in at all=
).=A0 Discussion is the whole point of face to face meetings.<br>

<br>For instance, while std::optional was extensively discussed outside of =
the meeting, I am very sure it *never* would have been voted in were it not=
 for the face to face discussions at Bristol.<br></div></div>-- <br>=A0Nevi=
n &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.=
com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 (847) 691-1404

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c35aca45663104dd7bb844--

.

--001a11c33112adb5a904dd7dc618
Content-Type: text/plain; charset=ISO-8859-1

On 24 May 2013 17:49, Nevin Liber <nevin@eviloverlord.com> wrote:

>
> If you really want the adaptor:
>
> template<typename... Ts>
> using silly_vector_adaptor  = const std::vector<Ts...>;
>
> Callee uses a vector internally and returns silly_vector_adaptor.  Problem
> solved.
>
>
>
Note that this is yet another different beast than a non-resizable
contiguous sequence container,
because not only does that prevent resizing, it prevents modification of
the elements, too.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--001a11c33112adb5a904dd7dc618
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 24 May 2013 17:49, Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><div class=3D"gmail_quote"><div>If you r=
eally want the adaptor:</div><div><br></div><div>template&lt;typename... Ts=
&gt;</div>
<div>using silly_vector_adaptor =A0=3D const std::vector&lt;Ts...&gt;;</div=
><div><br></div><div>Callee uses a vector internally and returns silly_vect=
or_adaptor. =A0Problem solved.</div>

</div><div class=3D"im"><br><br></div></blockquote><div><br></div><div>Note=
 that this is yet another different beast than a non-resizable contiguous s=
equence container,<br>because not only does that prevent resizing, it preve=
nts modification of the elements, too. <br>
</div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c33112adb5a904dd7dc618--

.

------=_Part_727_19963525.1369433447670
Content-Type: text/plain; charset=ISO-8859-1

On Friday, May 24, 2013 12:21:48 PM UTC-7, Nevin ":-)" Liber wrote:
>
> On 24 May 2013 14:14, Nicol Bolas <jmck...@gmail.com <javascript:>> wrote:
>
>> That's not what I said. What I said was that there would be a period of
>> discussion that happens outside of meetings, and that there would be *no*discussion during meetings. At the meetings, the actual proposal would
>> either be voted in or not. So you either speak at the discussion part, or
>> you don't speak at all.
>>
>
> That seems *less* efficient to me, as people tend to vote "no" when their
> concerns aren't addressed, thus making proposals stretch over many meetings
> (if they ever get voted in at all).  Discussion is the whole point of face
> to face meetings.
>

Why?

For instance, while std::optional was extensively discussed outside of the
> meeting, I am very sure it *never* would have been voted in were it not for
> the face to face discussions at Bristol.
>

The whole point of the idea is to *end* the reliance on those.

Face to face discussions are the *slow* part of the standardization
process. They're the part that makes standardization hard. And the reason
why most languages evolve much faster and more effectively than C++ is that
they either handle all of their major issues via e-mail/forums/alternate
communications or they have *lots* of face to face discussions (ie: are
working near each other).

This is the 21st century, and we are all computer experts. We are perfectly
capable of carrying on an intelligent, productive discussion without
physically being in the same room. We shouldn't have to be shackled to this
ridiculous twice-a-years schedule just to get something accomplished.

The C++ standardization process has a problem. And there are three ways to
deal with this problem:

1: Have more face to face discussions.

2: Focus on having more discussions and more productive ones, just not face
to face. Thus, all face to face time would be focused on getting something
done (ie: voting stuff into the standard).

3: Do nothing. This leaves face-to-face discussions as a *massive*bottleneck towards actually accomplishing anything.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_727_19963525.1369433447670
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Friday, May 24, 2013 12:21:48 PM UTC-7, Nevin ":-)" Liber wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">On 24 May 2013 14:14, Nicol Bolas <spa=
n dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"FuItPzHk4HkJ">jmck...@gmail.com</a>&gt;</span> wrote:<br><div cla=
ss=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>That's not what I said. What I said was that there would be a period o=
f discussion that happens outside of meetings, and that there would be <i>n=
o</i> discussion during meetings. At the meetings, the actual proposal woul=
d either be voted in or not. So you either speak at the discussion part, or=
 you don't speak at all.<br>

</div></blockquote><div><br>That seems *less* efficient to me, as people te=
nd to vote "no" when their concerns aren't addressed, thus making proposals=
 stretch over many meetings (if they ever get voted in at all).&nbsp; Discu=
ssion is the whole point of face to face meetings.<br></div></div></blockqu=
ote><div><br>Why? <br><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div class=3D"gmail_quote"><div>

For instance, while std::optional was extensively discussed outside of the =
meeting, I am very sure it *never* would have been voted in were it not for=
 the face to face discussions at Bristol.</div></div></blockquote><div><br>=
The whole point of the idea is to <i>end</i> the reliance on those.<br><br>=
Face to face discussions are the <i>slow</i> part of the standardization pr=
ocess. They're the part that makes standardization hard. And the reason why=
 most languages evolve much faster and more effectively than C++ is that th=
ey either handle all of their major issues via e-mail/forums/alternate comm=
unications or they have <i>lots</i> of face to face discussions (ie: are wo=
rking near each other).<br><br>This is the 21st century, and we are all com=
puter experts. We are perfectly capable of carrying on an intelligent, prod=
uctive discussion without physically being in the same room. We shouldn't h=
ave to be shackled to this ridiculous twice-a-years schedule just to get so=
mething accomplished.<br><br>The C++ standardization process has a problem.=
 And there are three ways to deal with this problem:<br><br>1: Have more fa=
ce to face discussions.<br><br>2: Focus on having more discussions and more=
 productive ones, just not face to face. Thus, all face to face time would =
be focused on getting something done (ie: voting stuff into the standard).<=
br><br>3: Do nothing. This leaves face-to-face discussions as a <i>massive<=
/i> bottleneck towards actually accomplishing anything.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_727_19963525.1369433447670--

.

------=_Part_739_20928310.1369433611598
Content-Type: text/plain; charset=ISO-8859-1

On Friday, May 24, 2013 12:21:18 PM UTC-7, Ville Voutilainen wrote:
>
> On 24 May 2013 22:14, Nicol Bolas <jmck...@gmail.com <javascript:>> wrote:
>
>>
>> That's not what I said. What I said was that there would be a period of
>> discussion that happens outside of meetings, and that there would be *no*discussion during meetings. At the meetings, the actual proposal would
>> either be voted in or not. So you either speak at the discussion part, or
>> you don't speak at all.
>>
>>
> Ok, in the imaginary world where this approach is adopted, I will vote
> against every proposal.
>

I would say that such a standpoint is pretty disappointing coming from a
voting committee member. It's rather immature to say that, if the process
doesn't work the way *you* want it to, you'll just throw a wrench in the
whole thing until it does. By this reasoning, if I were a voting member, I
should just vote against everything until the process that *I* want to see
were adopted.

Obstructing a process just because you don't personally agree with it may
be a common tactic in politics, but I thought we were better than that.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_739_20928310.1369433611598
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Friday, May 24, 2013 12:21:18 PM UTC-7, Ville Voutilainen wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gm=
ail_quote">On 24 May 2013 22:14, Nicol Bolas <span dir=3D"ltr">&lt;<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"PrskYYa5K7kJ">j=
mck...@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><div>That's not what I said. What I said=
 was that there would be a period of discussion that happens outside of mee=
tings, and that there would be <i>no</i> discussion during meetings. At the=
 meetings, the actual proposal would either be voted in or not. So you eith=
er speak at the discussion part, or you don't speak at all.<br>
<br></div></blockquote><div><br></div><div>Ok, in the imaginary world where=
 this approach is adopted, I will vote against every proposal.<br></div></d=
iv></div></div></blockquote><div><br>I would say that such a standpoint is =
pretty disappointing coming from a voting committee member. It's rather imm=
ature to say that, if the process doesn't work the way <i>you</i> want it t=
o, you'll just throw a wrench in the whole thing until it does. By this rea=
soning, if I were a voting member, I should just vote against everything un=
til the process that <i>I</i> want to see were adopted.<br><br>Obstructing =
a process just because you don't personally agree with it may be a common t=
actic in politics, but I thought we were better than that.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_739_20928310.1369433611598--

.

--001a11c2ab98e88d4504dd7e397d
Content-Type: text/plain; charset=ISO-8859-1

On 25 May 2013 01:13, Nicol Bolas <jmckesson@gmail.com> wrote:

>
> Ok, in the imaginary world where this approach is adopted, I will vote
>> against every proposal.
>>
>
> I would say that such a standpoint is pretty disappointing coming from a
> voting committee member. It's rather immature to say that,
>

I would say that proposing the removal of review rounds that have proven to
be essential in the process is equally disappointing.


if the process doesn't work the way *you* want it to, you'll just throw a
> wrench in the whole thing until it does. By this reasoning, if I
>

You fail to understand the end, and think it's about the means. I would
certainly consider throwing a wrench into
a standards process that is downright haphazard.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--001a11c2ab98e88d4504dd7e397d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 25 May 2013 01:13, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><div class=3D"im"><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>Ok, in the imaginary =
world where this approach is adopted, I will vote against every proposal.<b=
r></div></div></div></div></blockquote></div><div><br>I would say that such=
 a standpoint is pretty disappointing coming from a voting committee member=
.. It&#39;s rather immature to say that, </div>
</blockquote><div><br></div><div>I would say that proposing the removal of =
review rounds that have proven to be essential in the process is equally di=
sappointing. <br><br><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>if the process doesn&#39;t work the way <i>you</i> want it to, you&#39=
;ll just throw a wrench in the whole thing until it does. By this reasoning=
, if I </div></blockquote><div><br></div><div>You fail to understand the en=
d, and think it&#39;s about the means. I would certainly consider throwing =
a wrench into<br>
a standards process that is downright haphazard.<br><br></div></div><br></d=
iv></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c2ab98e88d4504dd7e397d--

.

On 5/23/13, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wrote:
> 2013/5/24 Alex B <devalexb@gmail.com>:
> > So if the return value should be a container, vector would be the
> > best option. But what if the one calling the function prefers
> > storing the result in a dynarray? That's why I proposed adding
> > the ability to move a vector in a dynarray. But I am willing
> > to explore other possibilities.
>
> I think that dynarray is not a good container for this kind of
> example, because it would be returned out of a function. Yes,
> technically it it possible to return a dynarray, but it really
> would not take advantage of the most important use-case for that
> type: To be used in block scope as variable with automatic storage
> duration and taking the memory from the stack.

I would just like to make it clear that while dynarray as an
automatic variable is an important use case, I would hesitate to
call it the most important use case.  Its use in a member variable
of a stack object is also important.

Consider the following code.

class abstraction {
    .... other variables ....
    dynarray<int> datablock;
public:
    outer(int z ....) : storage(z) .... {}
};

void whatever(....) {
    static abstraction permanent(20 ....);
    abstraction transient(20 ....);
    ....
}

In this case, the dynarray element storage for 'permanent' must
necessarily be allocated on the heap.  However, the dynarray element
storage for 'transient' can be allocated on the stack.  The reason
(pragmatically) is that the abstraction constructor is inline,
and the compiler can now observe that the dynarray constructor is
being called on a stack variable, and therefore allocate its data
storage from the stack.

To be clear, "sufficiently inline" abstractions implemented with
dynarray will automatically become faster when they are automatic
variables.

--=20
Lawrence Crowl

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



.

On May 24, 2013, at 5:24 PM, Lawrence Crowl <crowl@googlers.com> wrote:

> In this case, the dynarray element storage for 'permanent' must
> necessarily be allocated on the heap.

Couldn't it also be in "static" space?  In this particular example,
the size is known at compile time.
 --
 Nevin ":-)" Liber
 <mailto:nevin@eviloverlord.com>
 (847) 691-1404
(sent from my iPad)

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On 5/24/13, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Friday, May 24, 2013 7:13:22 AM UTC-7, Alex B wrote:
> > That is exactly my point. The goal is to define a way to
> > return a continuous data container that could be moved into
> > *any* contiguous data container (without making the function
> > a template function).
>
> That's a very *different* goal, one that is highly unlikely to be
> able to work in the general case. The goal you originally suggested
> was between `vector` and `dynarray`, which are two very specific
> classes with known implementations. That's different from saying
> "any contiguous data container".

Because dynarray implementation need to handle heap storage anyway,
moving from a vector/whatever into a dynarray being constructed
is possible.  The problem is that one cannot always move out of
a dynarray.

> > We need to be able to 'release' the ownership from a vector
> > (or any similar user-defined container) the same way we can
> > release the ownership from a unique_ptr.
>
> You can't release the memory owned by a vector because that memory
> *isn't owned by the vector*. It's owned by the *allocator* for the
> vector. To properly free it, you must have 4 pieces of information:
>
> 1. A pointer to the memory.
>
> 2. The type of data allocated (ie: the `T` that
> allocator_traits<allocator<T>>::allocate was called on.
>
> 3. The number of elements (the capacity).
>
> 4. The allocator itself.
>
> That's why what you suggest can't work in the general case. You can
> require `vector` and `dynarray` to be transferable into one-another
> (allocator willing). But you can't require that you can just
> extract the guts out of a vector and deallocate it yourself.

I think it would be possible to define a 'chunk of contiguously
allocated objects' abstraction.  For types that can be moved from
there would need to be some form of release function, possibly
invoked by conversion to 'chunk' type.  That abstraction would need
to carry the allocator.

I am less confident that we could retrofit such a scheme into
the current library without inducing a change in the ABI.  The
implementors of the standard library would need to be consulted.

--
Lawrence Crowl

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On 5/24/13, Nevin Liber <nliber@gmail.com> wrote:
> On May 24, 2013, at 5:24 PM, Lawrence Crowl <crowl@googlers.com> wrote:
> > In this case, the dynarray element storage for 'permanent'
> > must necessarily be allocated on the heap.
>
> Couldn't it also be in "static" space?  In this particular example,
> the size is known at compile time.

Yes, in this case.  I tried to avoid introducing too many concepts
in to the example, and apparently I introduced one too few.  :-)

--
Lawrence Crowl

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

------=_Part_1035_32311972.1369473696623
Content-Type: text/plain; charset=ISO-8859-1

On Friday, May 24, 2013 3:21:53 PM UTC-7, Ville Voutilainen wrote:
>
> On 25 May 2013 01:13, Nicol Bolas <jmck...@gmail.com <javascript:>> wrote:
>
>>
>> Ok, in the imaginary world where this approach is adopted, I will vote
>>> against every proposal.
>>>
>>
>> I would say that such a standpoint is pretty disappointing coming from a
>> voting committee member. It's rather immature to say that,
>>
>
> I would say that proposing the removal of review rounds that have proven
> to be essential in the process is equally disappointing.
>
>
> if the process doesn't work the way *you* want it to, you'll just throw a
>> wrench in the whole thing until it does. By this reasoning, if I
>>
>
> You fail to understand the end, and think it's about the means. I would
> certainly consider throwing a wrench into
> a standards process that is downright haphazard.
>

There's nothing "haphazard" about what I suggested. It simply moves the
discussion to periods *between* meetings, so that meetings can be focused
on the matter of up/down votes. It allows substantitve discussion to happen
more than twice a year. It clears up the bottleneck that the meetings
create, thus allowing meetings to be about passing what has *already been*agreed upon, rather than debating the same points that have been brought up
in other discussions outside of the meeting.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_1035_32311972.1369473696623
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Friday, May 24, 2013 3:21:53 PM UTC-7, Ville Voutilainen wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gma=
il_quote">On 25 May 2013 01:13, Nicol Bolas <span dir=3D"ltr">&lt;<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"4oxFyycBYY4J">j=
mck...@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>Ok, in the imaginary =
world where this approach is adopted, I will vote against every proposal.<b=
r></div></div></div></div></blockquote></div><div><br>I would say that such=
 a standpoint is pretty disappointing coming from a voting committee member=
.. It's rather immature to say that, </div>
</blockquote><div><br></div><div>I would say that proposing the removal of =
review rounds that have proven to be essential in the process is equally di=
sappointing. <br><br><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>if the process doesn't work the way <i>you</i> want it to, you'll just=
 throw a wrench in the whole thing until it does. By this reasoning, if I <=
/div></blockquote><div><br></div><div>You fail to understand the end, and t=
hink it's about the means. I would certainly consider throwing a wrench int=
o<br>
a standards process that is downright haphazard.<br></div></div></div></div=
></blockquote><div><br>There's nothing "haphazard" about what I suggested. =
It simply moves the discussion to periods <i>between</i> meetings, so that =
meetings can be focused on the matter of up/down votes. It allows substanti=
tve discussion to happen more than twice a year. It clears up the bottlenec=
k that the meetings create, thus allowing meetings to be about passing what=
 has <i>already been</i> agreed upon, rather than debating the same points =
that have been brought up in other discussions outside of the meeting.<br><=
/div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1035_32311972.1369473696623--

.

--001a11c2e4d01d193704dd884c90
Content-Type: text/plain; charset=ISO-8859-1

On 25 May 2013 12:21, Nicol Bolas <jmckesson@gmail.com> wrote:

>
> There's nothing "haphazard" about what I suggested. It simply moves the
> discussion to periods *between* meetings, so that meetings can be focused
> on the matter of up/down votes. It allows substantitve discussion to happen
> more than twice a year. It clears up the bottleneck that the meetings
> create, thus allowing meetings to be about passing what has *already been*agreed upon, rather than debating the same points that have been brought up
> in other discussions outside of the meeting.
>
>
>
>
The study groups already have the means to conduct substantive discussion
more than twice a year. And if they
want to avoid rehashing discussions all over again, they can make
proposals/presentations that clarify the
potential points of controversy beforehand. That doesn't mean that we
should just rubberstamp what
they propose without any discussion. The alleged bottleneck is there for a
reason. We also already
have evidence of proposals that are "good enough" that they pass this
process without delay. For the
proposals that don't, the onus is on them to become good enough, and the
review process is
a rather instrumental tool to achieve that goal.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--001a11c2e4d01d193704dd884c90
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 25 May 2013 12:21, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><div>There&#39;s nothing &quot;haphazard=
&quot; about what I suggested. It simply moves the discussion to periods <i=
>between</i> meetings, so that meetings can be focused on the matter of up/=
down votes. It allows substantitve discussion to happen more than twice a y=
ear. It clears up the bottleneck that the meetings create, thus allowing me=
etings to be about passing what has <i>already been</i> agreed upon, rather=
 than debating the same points that have been brought up in other discussio=
ns outside of the meeting.<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

<br><br></div></div></blockquote><div><br></div><div>The study groups alrea=
dy have the means to conduct substantive discussion more than twice a year.=
 And if they<br>want to avoid rehashing discussions all over again, they ca=
n make proposals/presentations that clarify the<br>
</div><div>potential points of controversy beforehand. That doesn&#39;t mea=
n that we should just rubberstamp what<br>they propose without any discussi=
on. The alleged bottleneck is there for a reason. We also already<br>have e=
vidence of proposals that are &quot;good enough&quot; that they pass this p=
rocess without delay. For the<br>
proposals that don&#39;t, the onus is on them to become good enough, and th=
e review process is<br>a rather instrumental tool to achieve that goal.<br>=
</div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c2e4d01d193704dd884c90--

.

------=_Part_46_32631040.1369490928126
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Op vrijdag 24 mei 2013 08:57:48 UTC+2 schreef Daniel Kr=FCgler het volgende=
:

> 2013/5/24 Nicol Bolas <jmck...@gmail.com <javascript:>>:=20
> > On Thursday, May 23, 2013 8:29:16 PM UTC-7, Nevin ":-)" Liber wrote:=20
> >>=20
> >> On May 23, 2013, at 10:18 PM, Alex B <deva...@gmail.com> wrote:=20
> >>=20
> >> > Maybe what we need is a new array class that would be almost exactly=
=20
> the=20
> >> > same as dynarray except that it would always allocate on the heap (o=
r=20
> where=20
> >> > the specified allocator actually allocates).=20
> >>=20
> >> How is that any different than vector?=20
> >=20
> > It is exactly like std::vector except that it must be created with an=
=20
> > explicit size, and it cannot be resized at all.=20
>
> This looks like a adaptor for std::vector for me, so wouldn't=20
> necessarily require a full-fledged container.=20
>
>
https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/DEdAgZWd=
0hc
=20

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_46_32631040.1369490928126
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Op vrijdag 24 mei 2013 08:57:48 UTC+2 schreef Daniel Kr=FCgler het volgende=
:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">2013/5/24 Nicol Bolas &lt=
;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"NypXfZg=
FbjUJ">jmck...@gmail.com</a>&gt;:
<br>&gt; On Thursday, May 23, 2013 8:29:16 PM UTC-7, Nevin ":-)" Liber wrot=
e:
<br>&gt;&gt;
<br>&gt;&gt; On May 23, 2013, at 10:18 PM, Alex B &lt;<a>deva...@gmail.com<=
/a>&gt; wrote:
<br>&gt;&gt;
<br>&gt;&gt; &gt; Maybe what we need is a new array class that would be alm=
ost exactly the
<br>&gt;&gt; &gt; same as dynarray except that it would always allocate on =
the heap (or where
<br>&gt;&gt; &gt; the specified allocator actually allocates).
<br>&gt;&gt;
<br>&gt;&gt; How is that any different than vector?
<br>&gt;
<br>&gt; It is exactly like std::vector except that it must be created with=
 an
<br>&gt; explicit size, and it cannot be resized at all.
<br>
<br>This looks like a adaptor for std::vector for me, so wouldn't
<br>necessarily require a full-fledged container.
<br><br></blockquote><div><a href=3D"https://groups.google.com/a/isocpp.org=
/forum/#!topic/std-proposals/DEdAgZWd0hc">https://groups.google.com/a/isocp=
p.org/forum/#!topic/std-proposals/DEdAgZWd0hc</a>&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_46_32631040.1369490928126--

.

------=_Part_1670_26332138.1369492265630
Content-Type: text/plain; charset=ISO-8859-1

Op vrijdag 24 mei 2013 08:33:15 UTC+2 schreef Nicol Bolas het volgende:

> Nicol, I hear you talk a lot, but I haven't seen any papers from you.
>> Would you like to write up contiguous_iterator_tag?
>>
>
> No; I don't want to see it done this way.
>

What way? Array_ref benefits from or even needs the contiguous_iterator_tag.



> Ranges are a *long* way from standardization (unless discussions are
> happening outside of the range study group's mailing list that I'm not
> aware of).
>
>
array_ref is too simple and useful to directly associate it with ranges or
> some other proposal. We don't even know what this "iterator_range" will
> look like,
>


boost::iterator_range exists already. I think the point is that
iterator_range (or just range) is a proper generalization of array_ref and
is quite simple too. So there's no reason to have array_ref instead of
range.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_1670_26332138.1369492265630
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Op vrijdag 24 mei 2013 08:33:15 UTC+2 schreef Nicol Bolas het volgende:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex">Nicol, I hear you talk a lot, but I haven't seen any papers from =
you.
<br>Would you like to write up contiguous_iterator_tag?
<br></blockquote><div><br>No; I don't want to see it done this way. </div><=
/blockquote><div><br></div><div>What way? Array_ref benefits from or even n=
eeds the contiguous_iterator_tag.</div><div><br></div><div>&nbsp;</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div>Ranges are a *long* way from =
standardization (unless discussions are happening outside of the range stud=
y group's mailing list that I'm not aware of).<br><br></div></blockquote><d=
iv><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>array_ref is=
 too simple and useful to directly associate it with ranges or some other p=
roposal. We don't even know what this "iterator_range" will look like, </di=
v></blockquote><div><br></div><div><br></div><div>boost::iterator_range exi=
sts already. I think the point is that iterator_range (or just range) is a =
proper generalization of array_ref and is quite simple too. So there's no r=
eason to have array_ref instead of range.</div><div><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1670_26332138.1369492265630--

.

------=_Part_1582_31315341.1369492906330
Content-Type: text/plain; charset=ISO-8859-1

Op zaterdag 25 mei 2013 12:22:48 UTC+2 schreef Ville Voutilainen het
volgende:

> The study groups already have the means to conduct substantive discussion
> more than twice a year. And if they
>

But some proposals don't get any feedback (for months) before a meeting and
are then rejected at the meeting itself.
IMO it'd be nice if more issues were raised (and addressed) sooner.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_1582_31315341.1369492906330
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Op zaterdag 25 mei 2013 12:22:48 UTC+2 schreef Ville Voutilainen het volgen=
de:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">The st=
udy groups already have the means to conduct substantive discussion more th=
an twice a year. And if they<br></div></blockquote><div><br></div><div>But =
some proposals don't get any feedback (for months) before a meeting and are=
 then rejected at the meeting itself.&nbsp;</div><div>IMO it'd be nice if m=
ore issues were raised (and addressed) sooner.</div><div><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1582_31315341.1369492906330--

.

--001a11c331126d6c0f04dd8c0105
Content-Type: text/plain; charset=ISO-8859-1

On 25 May 2013 17:41, Olaf van der Spek <olafvdspek@gmail.com> wrote:

> Op zaterdag 25 mei 2013 12:22:48 UTC+2 schreef Ville Voutilainen het
> volgende:
>
> The study groups already have the means to conduct substantive discussion
>> more than twice a year. And if they
>>
>
> But some proposals don't get any feedback (for months) before a meeting
> and are then rejected at the meeting itself.
> IMO it'd be nice if more issues were raised (and addressed) sooner.
>
>
>
Yep, we need to improve pre-meeting feedback.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--001a11c331126d6c0f04dd8c0105
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 25 May 2013 17:41, Olaf van der Spek <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com</=
a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Op zaterdag 25 mei 2013 12:22:48 UTC+2 schre=
ef Ville Voutilainen het volgende:<div class=3D"im"><br><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex">
<div dir=3D"ltr">The study groups already have the means to conduct substan=
tive discussion more than twice a year. And if they<br></div></blockquote><=
div><br></div></div><div>But some proposals don&#39;t get any feedback (for=
 months) before a meeting and are then rejected at the meeting itself.=A0</=
div>
<div>IMO it&#39;d be nice if more issues were raised (and addressed) sooner=
..</div><div class=3D"HOEnZb"><div class=3D"h5"><div><br><br></div></div></d=
iv></blockquote><div><br></div><div>Yep, we need to improve pre-meeting fee=
dback. <br>
</div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c331126d6c0f04dd8c0105--

.

------=_Part_302_18221322.1369502001614
Content-Type: text/plain; charset=ISO-8859-1

On Saturday, May 25, 2013 7:31:05 AM UTC-7, Olaf van der Spek wrote:
>
> Op vrijdag 24 mei 2013 08:33:15 UTC+2 schreef Nicol Bolas het volgende:
>
>> Nicol, I hear you talk a lot, but I haven't seen any papers from you.
>>> Would you like to write up contiguous_iterator_tag?
>>>
>>
>> No; I don't want to see it done this way.
>>
>
> What way? Array_ref benefits from or even needs the
> contiguous_iterator_tag.
>

It neither needs it nor benefits from it. `array_ref` uses pointers, which
are de-facto contiguous iterators.

Ranges are a *long* way from standardization (unless discussions are
>> happening outside of the range study group's mailing list that I'm not
>> aware of).
>>
>>
> array_ref is too simple and useful to directly associate it with ranges or
>> some other proposal. We don't even know what this "iterator_range" will
>> look like,
>>
>
>
> boost::iterator_range exists already.
>

`array_ref` exists already too. It was independently invented in two
separate projects.


> I think the point is that iterator_range (or just range) is a proper
> generalization of array_ref and is quite simple too. So there's no reason
> to have array_ref instead of range.
>

Except for wanting it done sooner, rather than tying it to the massive
"range" proposal that has yet to make even a *single proposal*. From
looking at the mailing list and the fact that not *one single proposal* for
any form of range has been made, I would say that standard range is still
in the conceptual phase. Also, there's no guarantee that the standard range
proposal will look like Boost.Range, or will have an `iterator_range` with
similar functionality (there's been talk of having ranges as fundamental
types, not made of iterators in any forward-facing way beyond begin/end).

So basically, you're saying, "Let's not use the solution that is guaranteed
to work. Let's instead wait around for 1-3+ years until a random SG gets
their heads together and forms something not entirely unlike a proposal.
And then let's hope that the proposal they produce will solve the problem
of interop with contiguous arrays, which is *not* a problem that the Range
SG is trying to solve."

See, once you have something large and "general" like `iterator_range`,
someone's going to say, "well, what about all those algorithms that take
iterator pairs?" Someone's going to ask, "well, what about treating
containers as ranges?" Then someone will ask, "what about composing
ranges?" Someone asks about ranges being the fundamental unit, with
iterators as kind of a backwards compatibility feature. And it balloons
from there. Eventually, you forget about the reason why you wanted
`iterator_range` at all, and you ultimately don't get a functioning
solution.

By contrast, `array_ref` is clean, finished, in production code, and most
importantly *narrowly scoped*. It's not something huge like ranges that
feature-creeps out of control. It's a known quantity with exactly the
effects we want. It's extensible for new classes (via the use of `operator
array_ref` overloads). And it solves the problem.

<insert obligatory "Perfect is the Enemy of Good" repetition>

However, if you want functionality differences:

This is what we want to have work:

//For some known type T:

void consumer(SomeClass<T> array_data)
{
  //consume array_data.
}

std::vector<T> data1 = { stuff };
consumer(data1);

std::array<T, 10> data2 = { stuff };
consumer(data2);

std::initializer_list<T> data3 = { stuff };
consumer(data3);

T data4[] = { stuff };
consumer(data4);

Note specifically the *lack* of any explicit conversion operation on the
various `dataN` parameters when passed to `consumer`. The user doesn't have
to care; as long as they are using a contiguous class, it will work. And
remember: the `T`'s here are a specific type; this isn't in template code
over some `typename T`.

This is what we *want* out of a prospective `SomeClass`.

That's not possible with `iterator_range`. Not without explicit conversions.

The user wants to take `iterator_range<const T*>`. But std::vector won't be
implicitly convertible to `iterator_range<const T*>`. Instead, if it is to
have an implicit conversion, it will be the kind of iterator_range that all
other containers use: `iterator_range<vector<T,
allocator_type>::const_iterator>>`. The standard does not *require* that to
be the same thing as `iterator_range<const T*>`.

The only way to make this work is to require implementations to have a
partial specialization of `iterator_range` for `<const T*>`, then use your
suggested `contiguous_iterator_tag` to allow it to do the conversion.

It should be noted that Boost.Range's version of this class has *no such*metaprogramming machinery, nor does it have specialized constructor
overloads for `vector`, `string`, or other known contiguous containers. As
such, this concept is *completely* untested.

Meanwhile, `array_ref` is a known *solution* to the problem. It exists,
with two independently developed implementations. It works for the intended
purpose: interoperability between users of arrays.

So yes, there are plenty of reasons to have `array_ref` instead of
`iterator_range`.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_302_18221322.1369502001614
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Saturday, May 25, 2013 7:31:05 AM UTC-7, Olaf van der Spek wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">Op vrijdag 24 mei 2013 08:33:15 UTC+2=
 schreef Nicol Bolas het volgende:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">Nicol, I hear you talk a lot, bu=
t I haven't seen any papers from you.
<br>Would you like to write up contiguous_iterator_tag?
<br></blockquote><div><br>No; I don't want to see it done this way. </div><=
/blockquote><div><br></div><div>What way? Array_ref benefits from or even n=
eeds the contiguous_iterator_tag.</div></blockquote><div><br>It neither nee=
ds it nor benefits from it. `array_ref` uses pointers, which are de-facto c=
ontiguous iterators.<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin=
-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Ranges are a =
*long* way from standardization (unless discussions are happening outside o=
f the range study group's mailing list that I'm not aware of).<br><br></div=
></blockquote><div><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>a=
rray_ref is too simple and useful to directly associate it with ranges or s=
ome other proposal. We don't even know what this "iterator_range" will look=
 like, </div></blockquote><div><br></div><div><br></div><div>boost::iterato=
r_range exists already.</div></blockquote><div><br>`array_ref` exists alrea=
dy too. It was independently invented in two separate projects.<br>&nbsp;</=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div>I think the point is =
that iterator_range (or just range) is a proper generalization of array_ref=
 and is quite simple too. So there's no reason to have array_ref instead of=
 range.</div></blockquote><div><br>Except for wanting it done sooner, rathe=
r than tying it to the massive "range" proposal that has yet to make even a=
 <i>single proposal</i>. From looking at the mailing list and the fact that=
 not <i>one single proposal</i> for any form of range has been made, I woul=
d say that standard range is still in the conceptual phase. Also, there's n=
o guarantee that the standard range proposal will look like Boost.Range, or=
 will have an `iterator_range` with similar functionality (there's been tal=
k of having ranges as fundamental types, not made of iterators in any forwa=
rd-facing way beyond begin/end).<br><br>So basically, you're saying, "Let's=
 not use the solution that is guaranteed to work. Let's instead wait around=
 for 1-3+ years until a random SG gets their heads together and forms somet=
hing not entirely unlike a proposal. And then let's hope that the proposal =
they produce will solve the problem of interop with contiguous arrays, whic=
h is <i>not</i> a problem that the Range SG is trying to solve."<br><br>See=
, once you have something large and "general" like `iterator_range`,=20
someone's going to say, "well, what about all those algorithms that take
 iterator pairs?" Someone's going to ask, "well, what about treating=20
containers as ranges?" Then someone will ask, "what about composing=20
ranges?" Someone asks about ranges being the fundamental unit, with iterato=
rs as kind of a backwards compatibility feature. And it balloons from there=
.. Eventually, you forget about the reason why you wanted `iterator_range` a=
t all, and you ultimately don't get a functioning solution.<br><br>By contr=
ast, `array_ref` is clean, finished, in production code, and most important=
ly <i>narrowly scoped</i>. It's not something huge like ranges that feature=
-creeps out of control. It's a known quantity with exactly the effects we w=
ant. It's extensible for new classes (via the use of `operator array_ref` o=
verloads). And it solves the problem.<br><br>&lt;insert obligatory "Perfect=
 is the Enemy of Good" repetition&gt;<br><br>However, if you want functiona=
lity differences:<br><br>This is what we want to have work:<br><br>//For so=
me known type T:<br><br><div class=3D"prettyprint" style=3D"background-colo=
r: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: soli=
d; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><=
div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> consumer</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Some=
Class</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> array_data</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #800;" cl=
ass=3D"styled-by-prettify">//consume array_data.</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br><br>std</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">vector</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&g=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> data1 <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> stuff </span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br>consumer</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">data1</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br><br>std</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>array</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #066;" class=3D"styled-by-prettify">10</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> data2 </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> stu=
ff </span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>consumer</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">data2</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br><br>std</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">initializer_list</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> data3 </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> stuff </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br>consumer</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">data3</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br><br>T data4</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">[]</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
stuff </span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>consumer=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">data4</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><b=
r>Note specifically the <i>lack</i> of any explicit conversion operation on=
 the various `dataN` parameters when passed to `consumer`. The user doesn't=
 have to care; as long as they are using a contiguous class, it will work. =
And remember: the `T`'s here are a specific type; this isn't in template co=
de over some `typename T`.<br><br>This is what we <i>want</i> out of a pros=
pective `SomeClass`.<br><br>That's not possible with `iterator_range`. Not =
without explicit conversions.<br><br>The user wants to take `iterator_range=
&lt;const T*&gt;`. But std::vector won't be implicitly convertible to `iter=
ator_range&lt;const T*&gt;`. Instead, if it is to have an implicit conversi=
on, it will be the kind of iterator_range that all other containers use: `i=
terator_range&lt;vector&lt;T, allocator_type&gt;::const_iterator&gt;&gt;`. =
The standard does not <i>require</i> that to be the same thing as `iterator=
_range&lt;const T*&gt;`.<br><br>The only way to make this work is to requir=
e implementations to have a partial specialization of `iterator_range` for =
`&lt;const T*&gt;`, then use your suggested `contiguous_iterator_tag` to al=
low it to do the conversion.<br><br>It should be noted that Boost.Range's v=
ersion of this class has <i>no such</i> metaprogramming machinery, nor does=
 it have specialized constructor overloads for `vector`, `string`, or other=
 known contiguous containers. As such, this concept is <i>completely</i> un=
tested.<br><br>Meanwhile, `array_ref` is a known <i>solution</i> to the pro=
blem. It exists, with two independently developed implementations. It works=
 for the intended purpose: interoperability between users of arrays.<br><br=
>So yes, there are plenty of reasons to have `array_ref` instead of `iterat=
or_range`.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_302_18221322.1369502001614--

.

------=_Part_1329_6792319.1369504119556
Content-Type: text/plain; charset=ISO-8859-1

On Saturday, May 25, 2013 3:22:48 AM UTC-7, Ville Voutilainen wrote:
>
> On 25 May 2013 12:21, Nicol Bolas <jmck...@gmail.com <javascript:>> wrote:
>
>>
>> There's nothing "haphazard" about what I suggested. It simply moves the
>> discussion to periods *between* meetings, so that meetings can be
>> focused on the matter of up/down votes. It allows substantitve discussion
>> to happen more than twice a year. It clears up the bottleneck that the
>> meetings create, thus allowing meetings to be about passing what has *already
>> been* agreed upon, rather than debating the same points that have been
>> brought up in other discussions outside of the meeting.
>>
>
> The study groups already have the means to conduct substantive discussion
> more than twice a year.
>

Even if we assumed that this helped (and by helped, that means that the
output from a study-group would be more likely to get through L/EWG without
any back-and-forth), it's only helpful for work that falls into that
study-group.

SGs are for big topics that require a lot of expert knowledge. Not smaller
things like Boost.Any or Printf.

And if they
> want to avoid rehashing discussions all over again, they can make
> proposals/presentations that clarify the
> potential points of controversy beforehand.
>

How do you know what a point of controversy is until it becomes
controversial? And if you're going to intelligently discuss a proposal and
vote on whether it should be standardized, isn't it your responsibility to
be educated on the subject's background?

That doesn't mean that we should just rubberstamp what
> they propose without any discussion. The alleged bottleneck is there for a
> reason.
>

It's not an "alleged" anything; it *is* a bottleneck. The fact that time is
often cited as the reason for "reasonable feature X not getting into
standard Y" proves that there are significant bottlenecks in the
standardization process.

Why isn't at least some form of Unicode support in C++14? Printf for
streams? Boost.Any? string_rev/view/etc? Why? Not enough time.

Not enough time? There were *six months* between Portland and Bristol.
That's time enough to write any of those proposals 3 times over. That's
plenty of time for someone to say, "I don't like the Unicode string class;
if you insist on keeping it in the proposal, I will vote against it."
That's plenty of time for someone to say, "If you aren't 100% backwards
compatible with printf, you had better use some other formatting syntax, or
I will vote against it." And so on.

Six months is plenty of time for commentary and revision in any reasonable
process. But the C++ committee doesn't use a reasonable process. It has
exactly one meaningful discussion period every 6 months, followed by a
vote. If your proposal doesn't match whatever arcane decision making
criteria used by the various committee members, then you have to wait *
another* 6 months to get your revised edition looked at and
approved/rejected.

How can you say that this *isn't* a bottleneck?

The Unicode paper was first presented here in *November* of 2012. It was
rough, but various persons helped iron it out. The version from the mailing
is dated for March, but I don't recall any major differences between that
version and the one we saw after much discussion here on these forums. The
printf proposal was in the *January* mailing, so there's really no excuse
for having no discussion about compatibility there.

I believe people should be able to walk into a committee meeting already
knowing if their proposals are going to get voted in or not. It shouldn't
be a surprise. It shouldn't involve discussion that hasn't been had before.
That way, if someone on the committee is really against something, you have
time to either convince them otherwise or remove it *before* the binding
vote.

That's a process that *works*. Yes, it requires more involvement from
committee members, rather than just have a meeting, then forget about
committee work until the next one. That's the only way you can effectively
move forward with improving the language in a reasonable timeframe.

We also already
> have evidence of proposals that are "good enough" that they pass this
> process without delay. For the
> proposals that don't, the onus is on them to become good enough, and the
> review process is
> a rather instrumental tool to achieve that goal.
>

"Good enough" is in the eye of the beholder. And if `dynarray` is what the
committee considers "good enough" to pass on its first try (more or less),
while that same committee asks for additional revisions of the Unicode
proposal, then I have strong reservations about L/EWG's ability to
reasonably determine what constitutes "good enough".

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_1329_6792319.1369504119556
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Saturday, May 25, 2013 3:22:48 AM UTC-7, Ville Voutilainen wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"g=
mail_quote">On 25 May 2013 12:21, Nicol Bolas <span dir=3D"ltr">&lt;<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"JrFvbYXOjMYJ">j=
mck...@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><div>There's nothing "haphazard" about w=
hat I suggested. It simply moves the discussion to periods <i>between</i> m=
eetings, so that meetings can be focused on the matter of up/down votes. It=
 allows substantitve discussion to happen more than twice a year. It clears=
 up the bottleneck that the meetings create, thus allowing meetings to be a=
bout passing what has <i>already been</i> agreed upon, rather than debating=
 the same points that have been brought up in other discussions outside of =
the meeting.<br>
</div></blockquote><div><br></div><div>The study groups already have the me=
ans to conduct substantive discussion more than twice a year.</div></div></=
div></div></blockquote><div><br>Even if we assumed that this helped (and by=
 helped, that means that the output from a study-group would be more likely=
 to get through L/EWG without any back-and-forth), it's only helpful for wo=
rk that falls into that study-group.<br><br>SGs are for big topics that req=
uire a lot of expert knowledge. Not smaller things like Boost.Any or Printf=
..<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><div><div class=3D"gmail_quote"><div>And if they<br>want to avoid rehashi=
ng discussions all over again, they can make proposals/presentations that c=
larify the<br>
</div><div>potential points of controversy beforehand.</div></div></div></d=
iv></blockquote><div><br>How do you know what a point of controversy is unt=
il it becomes controversial? And if you're going to intelligently discuss a=
 proposal and vote on whether it should be standardized, isn't it your resp=
onsibility to be educated on the subject's background?<br><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"g=
mail_quote"><div>That doesn't mean that we should just rubberstamp what<br>=
they propose without any discussion. The alleged bottleneck is there for a =
reason.</div></div></div></div></blockquote><div><br>It's not an "alleged" =
anything; it <i>is</i> a bottleneck. The fact that time is often cited as t=
he reason for "reasonable feature X not getting into standard Y" proves tha=
t there are significant bottlenecks in the standardization process.<br><br>=
Why isn't at least some form of Unicode support in C++14? Printf for stream=
s? Boost.Any? string_rev/view/etc? Why? Not enough time.<br><br>Not enough =
time? There were <i>six months</i> between Portland and Bristol. That's tim=
e enough to write any of those proposals 3 times over. That's plenty of tim=
e for someone to say, "I don't like the Unicode string class; if you insist=
 on keeping it in the proposal, I will vote against it." That's plenty of t=
ime for someone to say, "If you aren't 100% backwards compatible with print=
f, you had better use some other formatting syntax, or I will vote against =
it." And so on.<br><br>Six months is plenty of time for commentary and revi=
sion in any reasonable process. But the C++ committee doesn't use a reasona=
ble process. It has exactly one meaningful discussion period every 6 months=
, followed by a vote. If your proposal doesn't match whatever arcane decisi=
on making criteria used by the various committee members, then you have to =
wait <i>another</i> 6 months to get your revised edition looked at and appr=
oved/rejected.<br><br>How can you say that this <i>isn't</i> a bottleneck?<=
br><br>The Unicode paper was first presented here in <i>November</i> of 201=
2. It was rough, but various persons helped iron it out. The version from t=
he mailing is dated for March, but I don't recall any major differences bet=
ween that version and the one we saw after much discussion here on these fo=
rums. The printf proposal was in the <i>January</i> mailing, so there's rea=
lly no excuse for having no discussion about compatibility there.<br><br>I =
believe people should be able to walk into a committee meeting already know=
ing if their proposals are going to get voted in or not. It shouldn't be a =
surprise. It shouldn't involve discussion that hasn't been had before. That=
 way, if someone on the committee is really against something, you have tim=
e to either convince them otherwise or remove it <i>before</i> the binding =
vote.<br><br>That's a process that <i>works</i>. Yes, it requires more invo=
lvement from committee members, rather than just have a meeting, then forge=
t about committee work until the next one. That's the only way you can effe=
ctively move forward with improving the language in a reasonable timeframe.=
<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div><div class=3D"gmail_quote"><div>We also already<br>have evidence of p=
roposals that are "good enough" that they pass this process without delay. =
For the<br>
proposals that don't, the onus is on them to become good enough, and the re=
view process is<br>a rather instrumental tool to achieve that goal.<br></di=
v></div></div></div></blockquote><div><br>"Good enough" is in the eye of th=
e beholder. And if `dynarray` is what the committee considers "good enough"=
 to pass on its first try (more or less), while that same committee asks fo=
r additional revisions of the Unicode proposal, then I have strong reservat=
ions about L/EWG's ability to reasonably determine what constitutes "good e=
nough".<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1329_6792319.1369504119556--

.

------=_Part_1303_18666847.1369504504644
Content-Type: text/plain; charset=ISO-8859-1

On Saturday, May 25, 2013 7:48:15 AM UTC-7, Ville Voutilainen wrote:
>
> On 25 May 2013 17:41, Olaf van der Spek <olafv...@gmail.com <javascript:>>wrote:
>
>> Op zaterdag 25 mei 2013 12:22:48 UTC+2 schreef Ville Voutilainen het
>> volgende:
>>
>> The study groups already have the means to conduct substantive discussion
>>> more than twice a year. And if they
>>>
>>
>> But some proposals don't get any feedback (for months) before a meeting
>> and are then rejected at the meeting itself.
>> IMO it'd be nice if more issues were raised (and addressed) sooner.
>>
>>
>>
> Yep, we need to improve pre-meeting feedback.
>

So... after all of that, you basically *agree with me?* Making effective
use of pre-meeting time is exactly what I'm talking about.

The only difference is that, by banishing substantive discussion from the *
actual* meeting, it forces that discussion to be handled pre-meeting. Which
gives the proposer more time to allay fears about some aspect, argue
points, and/or make corrections. And thus, when we finally have the
pass/fail vote, the person can walk into the meeting confident that all
substantive criticism has been heard. That there will be no blind-siding by
some committee member who has some pet peeve about X that was never
discussed or commented on.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_1303_18666847.1369504504644
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Saturday, May 25, 2013 7:48:15 AM UTC-7, Ville Voutilainen wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"g=
mail_quote">On 25 May 2013 17:41, Olaf van der Spek <span dir=3D"ltr">&lt;<=
a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"vgIKqN9QF=
SUJ">olafv...@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Op zaterdag 25 mei 2013 12:22:48 UTC+2 schre=
ef Ville Voutilainen het volgende:<div><br><blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
<div dir=3D"ltr">The study groups already have the means to conduct substan=
tive discussion more than twice a year. And if they<br></div></blockquote><=
div><br></div></div><div>But some proposals don't get any feedback (for mon=
ths) before a meeting and are then rejected at the meeting itself.&nbsp;</d=
iv>
<div>IMO it'd be nice if more issues were raised (and addressed) sooner.</d=
iv><div><div><div><br><br></div></div></div></blockquote><div><br></div><di=
v>Yep, we need to improve pre-meeting feedback.&nbsp;</div></div></div></di=
v></blockquote><div><br>So... after all of that, you basically <i>agree wit=
h me?</i> Making effective use of pre-meeting time is exactly what I'm talk=
ing about.<br><br>The only difference is that, by banishing substantive dis=
cussion from the <i>actual</i> meeting, it forces that discussion to be han=
dled pre-meeting. Which gives the proposer more time to allay fears about s=
ome aspect, argue points, and/or make corrections. And thus, when we finall=
y have the pass/fail vote, the person can walk into the meeting confident t=
hat all substantive criticism has been heard. That there will be no blind-s=
iding by some committee member who has some pet peeve about X that was neve=
r discussed or commented on.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1303_18666847.1369504504644--

.

--e89a8ff2511c76c99804dd90c218
Content-Type: text/plain; charset=ISO-8859-1

On 25 May 2013 20:48, Nicol Bolas <jmckesson@gmail.com> wrote:

>
> The study groups already have the means to conduct substantive discussion
>> more than twice a year.
>>
>
> Even if we assumed that this helped (and by helped, that means that the
> output from a study-group would be more likely to get through L/EWG without
> any back-and-forth), it's only helpful for work that falls into that
> study-group.
>
> SGs are for big topics that require a lot of expert knowledge. Not smaller
> things like Boost.Any or Printf.
>

Well, it seems that things like any and printf are slated for a library TS.
Whether that TS is LEWG's stuff
or a separate SG remains to be seen.


>
> And if they
>> want to avoid rehashing discussions all over again, they can make
>> proposals/presentations that clarify the
>> potential points of controversy beforehand.
>>
>
> How do you know what a point of controversy is until it becomes
> controversial? And if you're going to intelligently discuss a proposal and
> vote on whether it should be standardized, isn't it your responsibility to
> be educated on the subject's background?
>

Oh, the education about background is something we completely agree on.
There was a lot of "is this variant?" discussion
when discussing std::any, and _that_ is just a waste of time. The authors
of optional knew that there was controversy
about relational operators and optional references because 1) there was a
lot of discussion about it in this
very forum 2) they had a proposal in Portland! They had a proposal in the
pipeline early, which is in general
something very much recommendable.



> That doesn't mean that we should just rubberstamp what
>> they propose without any discussion. The alleged bottleneck is there for
>> a reason.
>>
>
> It's not an "alleged" anything; it *is* a bottleneck. The fact that time
> is often cited as the reason for "reasonable feature X not getting into
> standard Y" proves that there are significant bottlenecks in the
> standardization process.
>

Ok. Those bottlenecks are not bugs in the process, so we shouldn't remove
them.


>
> Why isn't at least some form of Unicode support in C++14? Printf for
> streams? Boost.Any? string_rev/view/etc? Why? Not enough time.
>

Any apparently didn't have allocator support, and its author wasn't present
in Bristol.  string_view has a lot of design
issues that are undecided, and apparently the _author_ of it didn't have
time to make a new proposal to solve those
design issues. printf for streams got direction guidance for a paper that
isn't constrained by the legacy printf. The
author of the paper wasn't in Bristol, so we didn't have a new paper to
vote in.

The lack of time in these is lack of time by the paper authors. The
proposals weren't in a mature enough shape
to go in. You may think that's a bottleneck in the process, I don't think
so.


> Not enough time? There were *six months* between Portland and Bristol.
> That's time enough to write any of those proposals 3 times over. That's
> plenty of time for someone to say, "I don't like the Unicode string class;
> if you insist on keeping it in the proposal, I will vote against it."
> That's plenty of time for someone to say, "If you aren't 100% backwards
> compatible with printf, you had better use some other formatting syntax, or
> I will vote against it." And so on.
>

Then the paper authors should actively collect such feedback, instead of
bitching that volunteers busy with their
day jobs aren't spending their every waking hour looking at such proposals.
Removing *EWG reviews from the
process won't help with that at all.



>
> Six months is plenty of time for commentary and revision in any reasonable
> process. But the C++ committee doesn't use a reasonable process. It has
> exactly one meaningful discussion period every 6 months, followed by a
> vote. If your proposal doesn't match whatever arcane decision making
> criteria used by the various committee members, then you have to wait *
> another* 6 months to get your revised edition looked at and
> approved/rejected.
>

You don't have to wait. You can absolutely solicit feedback more often. You
can enlist committee members to help you
with your proposal, to get it more mature before a meeting. But don't take
my opinion on it, ask whether the authors
of optional had feedback more often than every six months, and ask them
whether they think the process works and/or
is reasonable.


>
>
> The Unicode paper was first presented here in *November* of 2012. It was
> rough, but various persons helped iron it out. The
>

Presenting here is unfortunately no guarantee of how the committee will
look at it. A small minority of the committee actively
follows this forum.


>
> I believe people should be able to walk into a committee meeting already
> knowing if their proposals are going to get voted in or not. It shouldn't
> be a surprise. It shouldn't involve discussion that hasn't been had before.
> That way, if someone on the committee is really against something, you have
> time to either convince them otherwise or remove it *before* the binding
> vote.
>

Sure, you can do that. The binding vote is at the end of the meeting, so
you have the days before that to convince people.


>
> That's a process that *works*. Yes, it requires more involvement from
> committee members, rather than just have a meeting, then forget about
> committee work until the next one. That's the only way you can effectively
> move forward with improving the language in a reasonable timeframe.
>

And what part of the current timeframes are unreasonable? A new c++
standard is slated to come out 3 years after
the previous one.


> We also already
>> have evidence of proposals that are "good enough" that they pass this
>> process without delay. For the
>> proposals that don't, the onus is on them to become good enough, and the
>> review process is
>> a rather instrumental tool to achieve that goal.
>>
>
> "Good enough" is in the eye of the beholder. And if `dynarray` is what the
> committee considers "good enough" to pass on its first try (more or less),
> while that same committee asks for additional revisions of the Unicode
> proposal, then I have strong reservations about L/EWG's ability to
> reasonably determine what constitutes "good enough".
>

dynarray has implementation and use experience, and had a champion in the
meeting, and it was also already in Portland.
The unicode proposal apparently had none of these things. I don't see that
as any kind of an example what (L)EWG are
capable of or not.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--e89a8ff2511c76c99804dd90c218
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 25 May 2013 20:48, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><div class=3D"im"><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>The study groups alre=
ady have the means to conduct substantive discussion more than twice a year=
..</div></div></div></div></blockquote></div><div><br>Even if we assumed tha=
t this helped (and by helped, that means that the output from a study-group=
 would be more likely to get through L/EWG without any back-and-forth), it&=
#39;s only helpful for work that falls into that study-group.<br>
<br>SGs are for big topics that require a lot of expert knowledge. Not smal=
ler things like Boost.Any or Printf.<br></div></blockquote><div><br></div><=
div>Well, it seems that things like any and printf are slated for a library=
 TS. Whether that TS is LEWG&#39;s stuff<br>
</div><div>or a separate SG remains to be seen.<br>=A0<br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div><br></div><div class=3D"im"><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>And if they<br>want t=
o avoid rehashing discussions all over again, they can make proposals/prese=
ntations that clarify the<br>
</div><div>potential points of controversy beforehand.</div></div></div></d=
iv></blockquote></div><div><br>How do you know what a point of controversy =
is until it becomes controversial? And if you&#39;re going to intelligently=
 discuss a proposal and vote on whether it should be standardized, isn&#39;=
t it your responsibility to be educated on the subject&#39;s background?<br=
>
</div></blockquote><div><br></div><div>Oh, the education about background i=
s something we completely agree on. There was a lot of &quot;is this varian=
t?&quot; discussion<br>when discussing std::any, and _that_ is just a waste=
 of time. The authors of optional knew that there was controversy<br>
about relational operators and optional references because 1) there was a l=
ot of discussion about it in this<br></div><div>very forum 2) they had a pr=
oposal in Portland! They had a proposal in the pipeline early, which is in =
general<br>
</div><div>something very much recommendable.<br><br></div><div><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div><br></div><div class=3D"im"><blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>That doesn&#39;t mean=
 that we should just rubberstamp what<br>they propose without any discussio=
n. The alleged bottleneck is there for a reason.</div></div></div></div></b=
lockquote>
</div><div><br>It&#39;s not an &quot;alleged&quot; anything; it <i>is</i> a=
 bottleneck. The fact that time is often cited as the reason for &quot;reas=
onable feature X not getting into standard Y&quot; proves that there are si=
gnificant bottlenecks in the standardization process.<br>
</div></blockquote><div><br></div><div>Ok. Those bottlenecks are not bugs i=
n the process, so we shouldn&#39;t remove them.<br>=A0<br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">
<div><br>Why isn&#39;t at least some form of Unicode support in C++14? Prin=
tf for streams? Boost.Any? string_rev/view/etc? Why? Not enough time.<br></=
div></blockquote><div><br></div><div>Any apparently didn&#39;t have allocat=
or support, and its author wasn&#39;t present in Bristol.=A0 string_view ha=
s a lot of design<br>
issues that are undecided, and apparently the _author_ of it didn&#39;t hav=
e time to make a new proposal to solve those<br>design issues. printf for s=
treams got direction guidance for a paper that isn&#39;t constrained by the=
 legacy printf. The<br>
author of the paper wasn&#39;t in Bristol, so we didn&#39;t have a new pape=
r to vote in.<br><br></div><div>The lack of time in these is lack of time b=
y the paper authors. The proposals weren&#39;t in a mature enough shape<br>
to go in. You may think that&#39;s a bottleneck in the process, I don&#39;t=
 think so.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>Not enough =
time? There were <i>six months</i> between Portland and Bristol. That&#39;s=
 time enough to write any of those proposals 3 times over. That&#39;s plent=
y of time for someone to say, &quot;I don&#39;t like the Unicode string cla=
ss; if you insist on keeping it in the proposal, I will vote against it.&qu=
ot; That&#39;s plenty of time for someone to say, &quot;If you aren&#39;t 1=
00% backwards compatible with printf, you had better use some other formatt=
ing syntax, or I will vote against it.&quot; And so on.<br>
</div></blockquote><div><br></div><div>Then the paper authors should active=
ly collect such feedback, instead of=A0 bitching that volunteers busy with =
their<br></div><div>day jobs aren&#39;t spending their every waking hour lo=
oking at such proposals. Removing *EWG reviews from the<br>
process won&#39;t help with that at all.<br><br>=A0<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div><br>Six months is plenty of time for commentary and r=
evision in any reasonable process. But the C++ committee doesn&#39;t use a =
reasonable process. It has exactly one meaningful discussion period every 6=
 months, followed by a vote. If your proposal doesn&#39;t match whatever ar=
cane decision making criteria used by the various committee members, then y=
ou have to wait <i>another</i> 6 months to get your revised edition looked =
at and approved/rejected.<br>
</div></blockquote><div><br></div><div>You don&#39;t have to wait. You can =
absolutely solicit feedback more often. You can enlist committee members to=
 help you<br>with your proposal, to get it more mature before a meeting. Bu=
t don&#39;t take my opinion on it, ask whether the authors<br>
of optional had feedback more often than every six months, and ask them whe=
ther they think the process works and/or<br>is reasonable.<br>=A0<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div><br><br>The Unicode paper was first presented here in <i>November</i> =
of 2012. It was rough, but various persons helped iron it out. The </div></=
blockquote><div><br></div><div>Presenting here is unfortunately no guarante=
e of how the committee will look at it. A small minority of the committee a=
ctively<br>
follows this forum.<br>=A0<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br=
>I believe people should be able to walk into a committee meeting already k=
nowing if their proposals are going to get voted in or not. It shouldn&#39;=
t be a surprise. It shouldn&#39;t involve discussion that hasn&#39;t been h=
ad before. That way, if someone on the committee is really against somethin=
g, you have time to either convince them otherwise or remove it <i>before</=
i> the binding vote.<br>
</div></blockquote><div><br></div><div>Sure, you can do that. The binding v=
ote is at the end of the meeting, so you have the days before that to convi=
nce people.<br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>That&#39;s a process that <i>works</i>. Yes, it requires more invo=
lvement from committee members, rather than just have a meeting, then forge=
t about committee work until the next one. That&#39;s the only way you can =
effectively move forward with improving the language in a reasonable timefr=
ame.<br>
</div></blockquote><div><br></div><div>And what part of the current timefra=
mes are unreasonable? A new c++ standard is slated to come out 3 years afte=
r<br>the previous one. <br><br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br></div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div><div class=3D"gmail_quote"><div>We also already<br>have=
 evidence of proposals that are &quot;good enough&quot; that they pass this=
 process without delay. For the<br>

proposals that don&#39;t, the onus is on them to become good enough, and th=
e review process is<br>a rather instrumental tool to achieve that goal.<br>=
</div></div></div></div></blockquote></div><div><br>&quot;Good enough&quot;=
 is in the eye of the beholder. And if `dynarray` is what the committee con=
siders &quot;good enough&quot; to pass on its first try (more or less), whi=
le that same committee asks for additional revisions of the Unicode proposa=
l, then I have strong reservations about L/EWG&#39;s ability to reasonably =
determine what constitutes &quot;good enough&quot;.<br>
</div></blockquote><div><br></div><div>dynarray has implementation and use =
experience, and had a champion in the meeting, and it was also already in P=
ortland.<br></div><div>The unicode proposal apparently had none of these th=
ings. I don&#39;t see that as any kind of an example what (L)EWG are<br>
capable of or not.<br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--e89a8ff2511c76c99804dd90c218--

.

--001a11c2f4266bcdec04dd90dcd0
Content-Type: text/plain; charset=ISO-8859-1

On 25 May 2013 20:55, Nicol Bolas <jmckesson@gmail.com> wrote:

>
> Yep, we need to improve pre-meeting feedback.
>>
>
> So... after all of that, you basically *agree with me?* Making effective
> use of pre-meeting time is exactly what I'm talking about.
>

Sure, I agree with that part. There's room for improvement, and the
committee has already taken steps to improve the
amount of work it does between the meetings, believe it or not.


>
> The only difference is that, by banishing substantive discussion from the
> *actual* meeting, it forces that discussion to be handled pre-meeting.
> Which gives the proposer more time to allay fears about some aspect, argue
> points, and/or make corrections. And
>

Funny, that gives the proposer less time, actually, if there's no
discussion during a meeting. That would be "Get it ready
before a meeting or it will be flat out rejected." Of course, if you
actively allay the fears, and argue points, and make corrections,
the discussion in a meeting will be less of a hurdle.


> thus, when we finally have the pass/fail vote, the person can walk into
> the meeting confident that all substantive criticism has been heard. That
> there will be no blind-siding by some committee member who has some pet
> peeve about X that was never discussed or commented on.
>
>
>
Part of the problems you complain about are caused by the persons not even
walking into the meetings, at all.
It's also caused by not having a champion who can actually participate in
the committee-internal mailing
lists and discuss the proposals there. Doing that improves the chances of
having the issues discussed
before a meeting much more than discussing it here will.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--001a11c2f4266bcdec04dd90dcd0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 25 May 2013 20:55, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">
<div><div class=3D"gmail_quote"><div>Yep, we need to improve pre-meeting fe=
edback.=A0</div></div></div></div></blockquote><div><br>So... after all of =
that, you basically <i>agree with me?</i> Making effective use of pre-meeti=
ng time is exactly what I&#39;m talking about.<br>
</div></blockquote><div><br></div><div>Sure, I agree with that part. There&=
#39;s room for improvement, and the committee has already taken steps to im=
prove the<br></div><div>amount of work it does between the meetings, believ=
e it or not.<br>
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div><br>The only difference is=
 that, by banishing substantive discussion from the <i>actual</i> meeting, =
it forces that discussion to be handled pre-meeting. Which gives the propos=
er more time to allay fears about some aspect, argue points, and/or make co=
rrections. And </div>
</blockquote><div><br></div><div>Funny, that gives the proposer less time, =
actually, if there&#39;s no discussion during a meeting. That would be &quo=
t;Get it ready <br>before a meeting or it will be flat out rejected.&quot; =
Of course, if you actively allay the fears, and argue points, and make corr=
ections,<br>
the discussion in a meeting will be less of a hurdle. <br>=A0<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div>thus, when we finally have the pass/fail vo=
te, the person can walk into the meeting confident that all substantive cri=
ticism has been heard. That there will be no blind-siding by some committee=
 member who has some pet peeve about X that was never discussed or commente=
d on.<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

<br></div></div></blockquote><div><br></div><div>Part of the problems you c=
omplain about are caused by the persons not even walking into the meetings,=
 at all.<br></div><div>It&#39;s also caused by not having a champion who ca=
n actually participate in the committee-internal mailing<br>
lists and discuss the proposals there. Doing that improves the chances of h=
aving the issues discussed<br>before a meeting much more than discussing it=
 here will.<br></div><div><br>=A0</div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c2f4266bcdec04dd90dcd0--

.

--047d7b6d9e6e0b94b804dd962d7b
Content-Type: text/plain; charset=ISO-8859-1

On Sat, May 25, 2013 at 10:13 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Saturday, May 25, 2013 7:31:05 AM UTC-7, Olaf van der Spek wrote:
>>
>> Op vrijdag 24 mei 2013 08:33:15 UTC+2 schreef Nicol Bolas het volgende:
>>
>>> Nicol, I hear you talk a lot, but I haven't seen any papers from you.
>>>> Would you like to write up contiguous_iterator_tag?
>>>>
>>>
>>> No; I don't want to see it done this way.
>>>
>>
>> What way? Array_ref benefits from or even needs the
>> contiguous_iterator_tag.
>>
>
> It neither needs it nor benefits from it. `array_ref` uses pointers, which
> are de-facto contiguous iterators.
>

array_ref<T*> should be implicitly constructible from vector<T>,
SmallVector<T, N>, dynarray<T>, array<T, N>, etc., but to do that in
general, we need to be able to detect that the relevant iterators are
contiguous.


> Ranges are a *long* way from standardization (unless discussions are
>>> happening outside of the range study group's mailing list that I'm not
>>> aware of).
>>>
>>>
>> array_ref is too simple and useful to directly associate it with ranges
>>> or some other proposal. We don't even know what this "iterator_range" will
>>> look like,
>>>
>>
>>
>> boost::iterator_range exists already.
>>
>
> `array_ref` exists already too. It was independently invented in two
> separate projects.
>

Olaf didn't make a claim that array_ref doesn't exist; he appeared to be
trying to demonstrate that you were wrong that "We don't even know what
this "iterator_range" will look like".


>
>
>> I think the point is that iterator_range (or just range) is a proper
>> generalization of array_ref and is quite simple too. So there's no reason
>> to have array_ref instead of range.
>>
>
> Except for wanting it done sooner, rather than tying it to the massive
> "range" proposal that has yet to make even a *single proposal*. From
> looking at the mailing list and the fact that not *one single proposal*for any form of range has been made,
>

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3513.html,
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3643.pdf, and
http://wiki.edg.com/twiki/pub/Wg21bristol/SG9/make_iterator_pair.html look
like proposals to me. All three help to establish a notion of what "ranges"
should be in C++17.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--047d7b6d9e6e0b94b804dd962d7b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sat, May 25, 2013 at 10:13 AM, Nicol Bolas <span dir=3D=
"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank" class=3D=
"cremed">jmckesson@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_e=
xtra"><div class=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D"im">On Saturday, May 25, 2013 7:31:05 AM UTC=
-7, Olaf van der Spek wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,20=
4);border-left-style:solid;padding-left:1ex">

Op vrijdag 24 mei 2013 08:33:15 UTC+2 schreef Nicol Bolas het volgende:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">Nicol, I hear you talk a lot, but I haven&#39;t seen any p=
apers from you.
<br>Would you like to write up contiguous_iterator_tag?
<br></blockquote><div><br>No; I don&#39;t want to see it done this way. </d=
iv></blockquote><div><br></div><div>What way? Array_ref benefits from or ev=
en needs the contiguous_iterator_tag.</div></blockquote></div><div><br>

It neither needs it nor benefits from it. `array_ref` uses pointers, which =
are de-facto contiguous iterators.<br></div></blockquote><div>=A0</div><div=
>array_ref&lt;T*&gt; should be implicitly constructible from vector&lt;T&gt=
;, SmallVector&lt;T, N&gt;, dynarray&lt;T&gt;, array&lt;T, N&gt;, etc., but=
 to do that in general, we need to be able to detect that the relevant iter=
ators are contiguous.</div>

<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><div></div><div class=3D"im"><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;=
border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex=
">

<div></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-st=
yle:solid;padding-left:1ex"><div>Ranges are a *long* way from standardizati=
on (unless discussions are happening outside of the range study group&#39;s=
 mailing list that I&#39;m not aware of).<br>

<br></div></blockquote><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(=
204,204,204);border-left-style:solid;padding-left:1ex"><div>array_ref is to=
o simple and useful to directly associate it with ranges or some other prop=
osal. We don&#39;t even know what this &quot;iterator_range&quot; will look=
 like, </div>

</blockquote><div><br></div><div><br></div><div>boost::iterator_range exist=
s already.</div></blockquote></div><div><br>`array_ref` exists already too.=
 It was independently invented in two separate projects.<br></div></blockqu=
ote>

<div><br></div><div>Olaf didn&#39;t make a claim that array_ref doesn&#39;t=
 exist; he appeared to be trying to demonstrate that you were wrong that &q=
uot;<span style=3D"color:rgb(80,0,80)">We don&#39;t even know what this &qu=
ot;iterator_range&quot; will look like&quot;.=A0</span></div>

<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><div>=A0</div><div class=3D"im"><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:=
1ex">

<div>I think the point is that iterator_range (or just range) is a proper g=
eneralization of array_ref and is quite simple too. So there&#39;s no reaso=
n to have array_ref instead of range.</div></blockquote></div><div><br>

Except for wanting it done sooner, rather than tying it to the massive &quo=
t;range&quot; proposal that has yet to make even a <i>single proposal</i>. =
From looking at the mailing list and the fact that not <i>one single propos=
al</i> for any form of range has been made,</div>

</blockquote><div><br></div><div><a href=3D"http://www.open-std.org/jtc1/sc=
22/wg21/docs/papers/2013/n3513.html">http://www.open-std.org/jtc1/sc22/wg21=
/docs/papers/2013/n3513.html</a>,=A0<a href=3D"http://www.open-std.org/jtc1=
/sc22/wg21/docs/papers/2013/n3643.pdf">http://www.open-std.org/jtc1/sc22/wg=
21/docs/papers/2013/n3643.pdf</a>, and=A0<a href=3D"http://wiki.edg.com/twi=
ki/pub/Wg21bristol/SG9/make_iterator_pair.html">http://wiki.edg.com/twiki/p=
ub/Wg21bristol/SG9/make_iterator_pair.html</a> look like proposals to me. A=
ll three help to establish a notion of what &quot;ranges&quot; should be in=
 C++17.</div>

<div>=A0</div></div></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b6d9e6e0b94b804dd962d7b--

.

------=_Part_338_4419985.1369565042762
Content-Type: text/plain; charset=ISO-8859-1

On Saturday, May 25, 2013 7:55:56 PM UTC-7, Jeffrey Yasskin wrote:
>
> On Sat, May 25, 2013 at 10:13 AM, Nicol Bolas <jmck...@gmail.com<javascript:>
> > wrote:
>
>> On Saturday, May 25, 2013 7:31:05 AM UTC-7, Olaf van der Spek wrote:
>>>
>>> Op vrijdag 24 mei 2013 08:33:15 UTC+2 schreef Nicol Bolas het volgende:
>>>
>>>> Nicol, I hear you talk a lot, but I haven't seen any papers from you.
>>>>> Would you like to write up contiguous_iterator_tag?
>>>>>
>>>>
>>>> No; I don't want to see it done this way.
>>>>
>>>
>>> What way? Array_ref benefits from or even needs the
>>> contiguous_iterator_tag.
>>>
>>
>> It neither needs it nor benefits from it. `array_ref` uses pointers,
>> which are de-facto contiguous iterators.
>>
>
> array_ref<T*> should be implicitly constructible from vector<T>,
> SmallVector<T, N>, dynarray<T>, array<T, N>, etc., but to do that in
> general, we need to be able to detect that the relevant iterators are
> contiguous.
>
>
>> Ranges are a *long* way from standardization (unless discussions are
>>>> happening outside of the range study group's mailing list that I'm not
>>>> aware of).
>>>>
>>>>
>>> array_ref is too simple and useful to directly associate it with ranges
>>>> or some other proposal. We don't even know what this "iterator_range" will
>>>> look like,
>>>>
>>>
>>>
>>> boost::iterator_range exists already.
>>>
>>
>> `array_ref` exists already too. It was independently invented in two
>> separate projects.
>>
>
> Olaf didn't make a claim that array_ref doesn't exist; he appeared to be
> trying to demonstrate that you were wrong that "We don't even know what
> this "iterator_range" will look like".
>

But we don't. We know what it *could* look like. My point is that we don't
know that boost::iterator_range will have the same functionality as some
eventual std::iterator_range.

It would not be the first time that the Boost version of some component has
more functionality than the standard library version. Just look at
`boost::bind`; it has operator ! support and a couple of other features
that were never standardized.

 I think the point is that iterator_range (or just range) is a proper
>>> generalization of array_ref and is quite simple too. So there's no reason
>>> to have array_ref instead of range.
>>>
>>
>> Except for wanting it done sooner, rather than tying it to the massive
>> "range" proposal that has yet to make even a *single proposal*. From
>> looking at the mailing list and the fact that not *one single proposal*for any form of range has been made,
>>
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3513.html,
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3643.pdf, and
> http://wiki.edg.com/twiki/pub/Wg21bristol/SG9/make_iterator_pair.htmllook like proposals to me. All three help to establish a notion of what
> "ranges" should be in C++17.
>

I can't really agree that N3643 is a proposal. Yes, it has an N-document
number, so it is a proposal in the most technical sense. But it's very
scant on the *specific* details of what this `select` template function
returns. Besides having begin/end, how does this object behave? Does the
object have .begin/.end members, or does it instead use
`std::begin/std::end` specializations? Is the object copyable? And what can
you do with it?

But N3513 is indeed a solid proposal, and I'm glad to see that progress is
being made (though it would be nice to know what the committee thought of
N3513). However, it should be noted that the next version of that paper
replaces the "range" concept with "traversable", likely so that the term
"range" can be preserved for some future concept that is more strict than
an iterator pair with a couple of accessible operations.

That being said, it should be noted that even N3513's updated version
doesn't include an `iterator_range`. So while more progress is being made
than I thought, that progress hasn't gotten to the point where `array_ref`
would be supposedly supplanted. Whereas if the committee had continued with
`array_ref` from last year, we'd have it for C++14 already, rather than
having to hope to get it as part of some Range TS or even worse, C++17.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_338_4419985.1369565042762
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Saturday, May 25, 2013 7:55:56 PM UTC-7, Jeffrey Yasskin wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Sat, May 25, 2013 a=
t 10:13 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"1adqnZzp_iQJ">jmck...@gmail.com</a>&g=
t;</span> wrote:<br><div><div class=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div>On Saturday, May 25, 2013 7:31:05 AM UTC-7, Olaf van =
der Spek wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex">

Op vrijdag 24 mei 2013 08:33:15 UTC+2 schreef Nicol Bolas het volgende:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">Nicol, I hear you talk a lot, but I haven't seen any paper=
s from you.
<br>Would you like to write up contiguous_iterator_tag?
<br></blockquote><div><br>No; I don't want to see it done this way. </div><=
/blockquote><div><br></div><div>What way? Array_ref benefits from or even n=
eeds the contiguous_iterator_tag.</div></blockquote></div><div><br>

It neither needs it nor benefits from it. `array_ref` uses pointers, which =
are de-facto contiguous iterators.<br></div></blockquote><div>&nbsp;</div><=
div>array_ref&lt;T*&gt; should be implicitly constructible from vector&lt;T=
&gt;, SmallVector&lt;T, N&gt;, dynarray&lt;T&gt;, array&lt;T, N&gt;, etc., =
but to do that in general, we need to be able to detect that the relevant i=
terators are contiguous.</div>

<div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div></div><div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-st=
yle:solid;padding-left:1ex"><div>Ranges are a *long* way from standardizati=
on (unless discussions are happening outside of the range study group's mai=
ling list that I'm not aware of).<br>

<br></div></blockquote><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(=
204,204,204);border-left-style:solid;padding-left:1ex"><div>array_ref is to=
o simple and useful to directly associate it with ranges or some other prop=
osal. We don't even know what this "iterator_range" will look like, </div>

</blockquote><div><br></div><div><br></div><div>boost::iterator_range exist=
s already.</div></blockquote></div><div><br>`array_ref` exists already too.=
 It was independently invented in two separate projects.<br></div></blockqu=
ote>

<div><br></div><div>Olaf didn't make a claim that array_ref doesn't exist; =
he appeared to be trying to demonstrate that you were wrong that "<span sty=
le=3D"color:rgb(80,0,80)">We don't even know what this "iterator_range" wil=
l look like".&nbsp;</span></div></div></div></div></blockquote><div><br>But=
 we don't. We know what it <i>could</i> look like. My point is that we don'=
t know that boost::iterator_range will have the same functionality as some =
eventual std::iterator_range.<br><br>It would not be the first time that th=
e Boost version of some component has more functionality than the standard =
library version. Just look at `boost::bind`; it has operator ! support and =
a couple of other features that were never standardized.<br><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D=
"gmail_quote">

<div></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-st=
yle:solid;padding-left:1ex"><div></div><div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-colo=
r:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div>I think the point is that iterator_range (or just range) is a proper g=
eneralization of array_ref and is quite simple too. So there's no reason to=
 have array_ref instead of range.</div></blockquote></div><div><br>

Except for wanting it done sooner, rather than tying it to the massive "ran=
ge" proposal that has yet to make even a <i>single proposal</i>. From looki=
ng at the mailing list and the fact that not <i>one single proposal</i> for=
 any form of range has been made,</div>

</blockquote><div><br></div><div><a href=3D"http://www.open-std.org/jtc1/sc=
22/wg21/docs/papers/2013/n3513.html" target=3D"_blank">http://www.open-std.=
org/jtc1/<wbr>sc22/wg21/docs/papers/2013/<wbr>n3513.html</a>,&nbsp;<a href=
=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3643.pdf" targ=
et=3D"_blank">http://www.open-<wbr>std.org/jtc1/sc22/wg21/docs/<wbr>papers/=
2013/n3643.pdf</a>, and&nbsp;<a href=3D"http://wiki.edg.com/twiki/pub/Wg21b=
ristol/SG9/make_iterator_pair.html" target=3D"_blank">http://wiki.edg.com/t=
wiki/<wbr>pub/Wg21bristol/SG9/make_<wbr>iterator_pair.html</a> look like pr=
oposals to me. All three help to establish a notion of what "ranges" should=
 be in C++17.</div></div></div></div></blockquote><div><br>I can't really a=
gree that N3643 is a proposal. Yes, it has an N-document number, so it is a=
 proposal in the most technical sense. But it's very scant on the <i>specif=
ic</i> details of what this `select` template function returns. Besides hav=
ing begin/end, how does this object behave? Does the object have .begin/.en=
d members, or does it instead use `std::begin/std::end` specializations? Is=
 the object copyable? And what can you do with it?<br><br>But N3513 is inde=
ed a solid proposal, and I'm glad to see that progress is being made (thoug=
h it would be nice to know what the committee thought of N3513). However, i=
t should be noted that the next version of that paper replaces the "range" =
concept with "traversable", likely so that the term "range" can be preserve=
d for some future concept that is more strict than an iterator pair with a =
couple of accessible operations.<br><br>That being said, it should be noted=
 that even N3513's updated version doesn't include an `iterator_range`. So =
while more progress is being made than I thought, that progress hasn't gott=
en to the point where `array_ref` would be supposedly supplanted. Whereas i=
f the committee had continued with `array_ref` from last year, we'd have it=
 for C++14 already, rather than having to hope to get it as part of some Ra=
nge TS or even worse, C++17.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_338_4419985.1369565042762--

.

------=_Part_1872_28709226.1369566207152
Content-Type: text/plain; charset=ISO-8859-1

On Saturday, May 25, 2013 1:35:49 PM UTC-7, Ville Voutilainen wrote:
>
> On 25 May 2013 20:55, Nicol Bolas <jmck...@gmail.com <javascript:>> wrote:
>
>> The only difference is that, by banishing substantive discussion from the
>> *actual* meeting, it forces that discussion to be handled pre-meeting.
>> Which gives the proposer more time to allay fears about some aspect, argue
>> points, and/or make corrections. And
>>
>
> Funny, that gives the proposer less time, actually, if there's no
> discussion during a meeting. That would be "Get it ready
> before a meeting or it will be flat out rejected." Of course, if you
> actively allay the fears, and argue points, and make corrections,
> the discussion in a meeting will be less of a hurdle.
>

So how do you know what those "fears", "points" and "corrections" even are *
without* having a discussion with the committee members?

thus, when we finally have the pass/fail vote, the person can walk into the
>> meeting confident that all substantive criticism has been heard. That there
>> will be no blind-siding by some committee member who has some pet peeve
>> about X that was never discussed or commented on.
>>
>
> Part of the problems you complain about are caused by the persons not even
> walking into the meetings, at all.
> It's also caused by not having a champion who can actually participate in
> the committee-internal mailing
> lists and discuss the proposals there. Doing that improves the chances of
> having the issues discussed
> before a meeting much more than discussing it here will.
>

OK, I'm starting to see where you're coming from. You say the problem is
that the person isn't present at the meetings and doesn't have a champion
to talk on the internal ML. I say that the problem is that the person *needs
to do those things at all*.

What is *gained* by having these hurdles in the design process of C++?
What's the point of having that whole "call for papers" thing, if all
you're going to do is lay down a bunch of obstacles for people who've
decided to take the time to help make C++ better? That kind of process is
far more likely to get people to *stop* contributing than to encourage
contributions.

What good does it serve to have all real pre-meeting discussion behind
doors that are locked and barred, such that the only way you can get
meaningful pre-meeting feedback is by knowing the right people? What is
gained by forcing people to fly potentially halfway around the world to
talk face-to-face, when we have technology *right now* that can allow us to
talk face-to-face without leaving our homes/offices?

The committee asks the community to help, then sets the rules to make
helping as difficult and time consuming as possible. Unless you happen to
be part of the in-group or happen to get someone who is to help you of
course. *Then* your proposal is effectively fast-tracked.

That's not a process that is conducive to community involvement.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_1872_28709226.1369566207152
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Saturday, May 25, 2013 1:35:49 PM UTC-7, Ville Voutilainen wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"g=
mail_quote">On 25 May 2013 20:55, Nicol Bolas <span dir=3D"ltr">&lt;<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"A5n9Ov0uL6wJ">j=
mck...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv>The only difference is that, by banishing substantive discussion from th=
e <i>actual</i> meeting, it forces that discussion to be handled pre-meetin=
g. Which gives the proposer more time to allay fears about some aspect, arg=
ue points, and/or make corrections. And </div>
</blockquote><div><br></div><div>Funny, that gives the proposer less time, =
actually, if there's no discussion during a meeting. That would be "Get it =
ready <br>before a meeting or it will be flat out rejected." Of course, if =
you actively allay the fears, and argue points, and make corrections,<br>
the discussion in a meeting will be less of a hurdle.<br></div></div></div>=
</div></blockquote><div><br>So how do you know what those "fears", "points"=
 and "corrections" even are <i>without</i> having a discussion with the com=
mittee members?<br><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div>thus, when we finally have the pass/fail vote, the person can walk=
 into the meeting confident that all substantive criticism has been heard. =
That there will be no blind-siding by some committee member who has some pe=
t peeve about X that was never discussed or commented on.
</div></blockquote><div><br></div><div>Part of the problems you complain ab=
out are caused by the persons not even walking into the meetings, at all.<b=
r></div><div>It's also caused by not having a champion who can actually par=
ticipate in the committee-internal mailing<br>
lists and discuss the proposals there. Doing that improves the chances of h=
aving the issues discussed<br>before a meeting much more than discussing it=
 here will.<br></div></div></div></div></blockquote><div><br>OK, I'm starti=
ng to see where you're coming from. You say the problem is that the person =
isn't present at the meetings and doesn't have a champion to talk on the in=
ternal ML. I say that the problem is that the person <i>needs to do those t=
hings at all</i>.<br><br>What is <i>gained</i> by having these hurdles in t=
he design process of C++? What's the point of having that whole "call for p=
apers" thing, if all you're going to do is lay down a bunch of obstacles fo=
r people who've decided to take the time to help make C++ better? That kind=
 of process is far more likely to get people to <i>stop</i> contributing th=
an to encourage contributions.<br><br>What good does it serve to have all r=
eal pre-meeting discussion behind doors that are locked and barred, such th=
at the only way you can get meaningful pre-meeting feedback is by knowing t=
he right people? What is gained by forcing people to fly potentially halfwa=
y around the world to talk face-to-face, when we have technology <i>right n=
ow</i> that can allow us to talk face-to-face without leaving our homes/off=
ices?<br><br>The committee asks the community to help, then sets the rules =
to make helping as difficult and time consuming as possible. Unless you hap=
pen to be part of the in-group or happen to get someone who is to help you =
of course. <i>Then</i> your proposal is effectively fast-tracked.<br><br>Th=
at's not a process that is conducive to community involvement.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1872_28709226.1369566207152--

.

--047d7b6773041c7ef504dd9d1f43
Content-Type: text/plain; charset=ISO-8859-1

On 26 May 2013 14:03, Nicol Bolas <jmckesson@gmail.com> wrote:

>
> Funny, that gives the proposer less time, actually, if there's no
>> discussion during a meeting. That would be "Get it ready
>> before a meeting or it will be flat out rejected." Of course, if you
>> actively allay the fears, and argue points, and make corrections,
>> the discussion in a meeting will be less of a hurdle.
>>
>
> So how do you know what those "fears", "points" and "corrections" even are
> *without* having a discussion with the committee members?
>

I don't know how you know that without such a discussion, the "actively
allay" means having a discussion with the committee
members. It doesn't mean that you sit on your arse, wait for the committee
to contact you, and complain if it doesn't.



>
> OK, I'm starting to see where you're coming from. You say the problem is
> that the person isn't present at the meetings and doesn't have a champion
> to talk on the internal ML. I say that the problem is that the person *needs
> to do those things at all*.
>

And instead the person should get his proposal accepted.. ..how? By just
writing it and waiting?


>
> What is *gained* by having these hurdles in the design process of C++?
> What's the point of having that whole "call for papers" thing, if all
> you're going to do is lay down a bunch of obstacles for people who've
> decided to take the time to help make C++ better? That kind of process is
> far more likely to get people to *stop* contributing than to encourage
> contributions.
>

What is gained is that it weeds out people who have meta-discussions on
std-proposals instead of actually working
on a proposal.



>
> What good does it serve to have all real pre-meeting discussion behind
> doors that are locked and barred, such that the only way you can get
> meaningful pre-meeting feedback is by knowing the right people? What is
> gained by forcing people to fly potentially
>

It cuts down the noise. We have had discussions about opening the committee
mailing lists read-only to the general
public, and the example of this forum gives us ample reason not to do so.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--047d7b6773041c7ef504dd9d1f43
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 26 May 2013 14:03, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><div class=3D"im"><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>Funny, that gives the=
 proposer less time, actually, if there&#39;s no discussion during a meetin=
g. That would be &quot;Get it ready <br>before a meeting or it will be flat=
 out rejected.&quot; Of course, if you actively allay the fears, and argue =
points, and make corrections,<br>

the discussion in a meeting will be less of a hurdle.<br></div></div></div>=
</div></blockquote></div><div><br>So how do you know what those &quot;fears=
&quot;, &quot;points&quot; and &quot;corrections&quot; even are <i>without<=
/i> having a discussion with the committee members?<br>
</div></blockquote><div><br></div><div>I don&#39;t know how you know that w=
ithout such a discussion, the &quot;actively allay&quot; means having a dis=
cussion with the committee<br>members. It doesn&#39;t mean that you sit on =
your arse, wait for the committee to contact you, and complain if it doesn&=
#39;t.<br>
<br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><br><div>OK, I&#39;m starti=
ng to see where you&#39;re coming from. You say the problem is that the per=
son isn&#39;t present at the meetings and doesn&#39;t have a champion to ta=
lk on the internal ML. I say that the problem is that the person <i>needs t=
o do those things at all</i>.<br>
</div></blockquote><div><br></div><div>And instead the person should get hi=
s proposal accepted.. ..how? By just writing it and waiting?<br>=A0<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">
<div><br>What is <i>gained</i> by having these hurdles in the design proces=
s of C++? What&#39;s the point of having that whole &quot;call for papers&q=
uot; thing, if all you&#39;re going to do is lay down a bunch of obstacles =
for people who&#39;ve decided to take the time to help make C++ better? Tha=
t kind of process is far more likely to get people to <i>stop</i> contribut=
ing than to encourage contributions.<br>
</div></blockquote><div><br></div><div>What is gained is that it weeds out =
people who have meta-discussions on std-proposals instead of actually worki=
ng<br></div><div>on a proposal.<br><br></div><div>=A0<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">
<div><br>What good does it serve to have all real pre-meeting discussion be=
hind doors that are locked and barred, such that the only way you can get m=
eaningful pre-meeting feedback is by knowing the right people? What is gain=
ed by forcing people to fly potentially </div>
</blockquote><div><br></div><div>It cuts down the noise. We have had discus=
sions about opening the committee mailing lists read-only to the general<br=
></div><div>public, and the example of this forum gives us ample reason not=
 to do so.<br>
</div><div><br><br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b6773041c7ef504dd9d1f43--

.

------=_Part_2036_12815010.1369575019985
Content-Type: text/plain; charset=ISO-8859-1

Ville, the main thing I'm going to say here is that it's very difficult to
get any pre-meeting feedback- at least, that was my experience. When I
presented the Unicode paper in Bristol, I got completely different feedback
to what I got, say, here. I mean, what exactly do you intend here?

Get it ready before a meeting or it will be flat out rejected


That's what we already had in Bristol, essentially.

Firstly, I'm going to say that the call for papers was kind of badly timed,
since everyone who answered it had their proposals moved to second tier
because they weren't going to be ready for C++14. Secondly, in my
experience, the feedback gained here is, well, it's kinda helpful, but it's
in no way preparation for attending a meeting and finding what feedback
you're going to get there. Bristol was my first meeting, and one of my
papers was essentially worthless which I simply should not have submitted
in the first place (n3575), but for the other three, I could have presented
a version that would have addressed the Committee's concerns- if I had
actually known what those concerns were before going. For example, it took
Jeffrey less than five minutes to sink N3574. I mean, sure, ultimately the
quality of the paper being presented is the responsibility of the
presenter, but it's difficult to present a good paper when the only way to
find out if it's good enough is to go to a meeting and present it- not to
mention the vast waste of time entailed.

Secondly, I think that the Committee is not especially efficient at making
use of the meetings. For example, I found some of the plenary sessions,
especially the one on Friday, to be a waste of time. Instead of dealing
with more papers, more revisions, I sat around and watched other people
vote and it wasn't even a binding vote. What was the point of that? And
there was far too much bikeshed discussion going on, at least in LEWG. But
I think more importantly, the level of attendance of specific meetings was
so paper-dependent that really, the optimum scheduling would not revolve
around subgroups at all, but which papers people wished to attend the
discussion of.

Finally, I can see why the Committee does not wish to open up their mailing
lists to everybody. std-proposals has, in the circles I frequent, become a
byword for proof for Sturgeon's Law, and it's no wonder that the Committee
wants to protect themselves from that. But if you're going to operate a
giant filter between the haves and have-nots, as it were, and then call for
a bunch of new proposals from new authors, then there should be some system
or advice as to what exactly is required to be a person that the Committee
wants to take seriously, because it's seriously off-putting to be trying to
generate decent proposals and then be locked out from the feedback that I
could really use. If the Committee really wants a bunch of new proposals
and new authors, they should consider not treating all authors who haven't
already attended ten meetings like crap. I don't know if there's interest
in updated versions of any of my proposals, or a few others I could make,
but if Chicago is gonna be like Bristol, then I'm really not sure if it's
gonna be worth my time and money- and I'm not the only one who feels this
way.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_2036_12815010.1369575019985
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Ville, the main thing I'm going to say here is that it's very difficult to =
get any pre-meeting feedback- at least, that was my experience. When I pres=
ented the Unicode paper in Bristol, I got completely different feedback to =
what I got, say, here. I mean, what exactly do you intend here?<div><br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; bo=
rder-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-st=
yle: solid; padding-left: 1ex;">Get it ready before a meeting or it will be=
 flat out rejected&nbsp;</blockquote><div><br></div><div>That's what we alr=
eady had in Bristol, essentially.</div><div><br></div><div>Firstly, I'm goi=
ng to say that the call for papers was kind of badly timed, since everyone =
who answered it had their proposals moved to second tier because they weren=
't going to be ready for C++14. Secondly, in my experience, the feedback ga=
ined here is, well, it's kinda helpful, but it's in no way preparation for =
attending a meeting and finding what feedback you're going to get there. Br=
istol was my first meeting, and one of my papers was essentially worthless =
which I simply should not have submitted in the first place (n3575), but fo=
r the other three, I could have presented a version that would have address=
ed the Committee's concerns- if I had actually known what those concerns we=
re before going. For example, it took Jeffrey less than five minutes to sin=
k N3574. I mean, sure, ultimately the quality of the paper being presented =
is the responsibility of the presenter, but it's difficult to present a goo=
d paper when the only way to find out if it's good enough is to go to a mee=
ting and present it- not to mention the vast waste of time entailed.</div><=
div><br></div><div>Secondly, I think that the Committee is not especially e=
fficient at making use of the meetings. For example, I found some of the pl=
enary sessions, especially the one on Friday, to be a waste of time. Instea=
d of dealing with more papers, more revisions, I sat around and watched oth=
er people vote and it wasn't even a binding vote. What was the point of tha=
t? And there was far too much bikeshed discussion going on, at least in LEW=
G. But I think more importantly, the level of attendance of specific meetin=
gs was so paper-dependent that really, the optimum scheduling would not rev=
olve around subgroups at all, but which papers people wished to attend the =
discussion of.</div><div><br></div><div>Finally, I can see why the Committe=
e does not wish to open up their mailing lists to everybody. std-proposals =
has, in the circles I frequent, become a byword for proof for Sturgeon's La=
w, and it's no wonder that the Committee wants to protect themselves from t=
hat. But if you're going to operate a giant filter between the haves and ha=
ve-nots, as it were, and then call for a bunch of new proposals from new au=
thors, then there should be some system or advice as to what exactly is req=
uired to be a person that the Committee wants to take seriously, because it=
's seriously off-putting to be trying to generate decent proposals and then=
 be locked out from the feedback that I could really use. If the Committee =
really wants a bunch of new proposals and new authors, they should consider=
 not treating all authors who haven't already attended ten meetings like cr=
ap. I don't know if there's interest in updated versions of any of my propo=
sals, or a few others I could make, but if Chicago is gonna be like Bristol=
, then I'm really not sure if it's gonna be worth my time and money- and I'=
m not the only one who feels this way.</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2036_12815010.1369575019985--

.

--e89a8f6465c3bb7d4604dda153db
Content-Type: text/plain; charset=ISO-8859-1

On 26 May 2013 16:30, DeadMG <wolfeinstein@gmail.com> wrote:

> Ville, the main thing I'm going to say here is that it's very difficult to
> get any pre-meeting feedback- at least, that was my experience. When I
> presented the Unicode paper in Bristol, I got completely different feedback
> to what I got, say, here. I mean,


The problem with this forum indeed is that it has rather few committee
followers. Consensus here doesn't indicate
much anything.


> what exactly do you intend here?
>
> Get it ready before a meeting or it will be flat out rejected
>
>
> That's what we already had in Bristol, essentially.
>

Oh, that was a snide remark against the idea of not being able to discuss
proposals in a meeting at
all. If you get a complete rejection in a meeting, then that's that, but if
you get feedback that says
the paper is otherwise ok, but needs certain fixes, those are theoretically
possible to fix during a meeting.


>
> Firstly, I'm going to say that the call for papers was kind of badly
> timed, since everyone who answered it had their proposals moved to second
> tier because they weren't going to be ready for C++14. Secondly, in my
> experience, the feedback gained here is,
>

Yep. The call for papers came out after Kona, and it probably would've been
helpful to get it out sooner.


> well, it's kinda helpful, but it's in no way preparation for attending a
> meeting and finding what feedback you're going to get there. Bristol was my
> first meeting, and one of my papers was essentially worthless which I
> simply should not have submitted in the first place (n3575), but for the
> other three, I could have presented a version that would have addressed the
> Committee's concerns- if I had actually known what those concerns were
> before going. For example, it took Jeffrey less than five minutes to sink
> N3574. I mean, sure, ultimately the quality of the paper being presented is
> the responsibility of the presenter, but it's difficult to present a good
> paper when the only way to find out if it's good enough is to go to a
> meeting and present it- not to mention the vast waste of time entailed.
>

Yes. This is why you should try and find committee members to help with
your papers.


>
> Secondly, I think that the Committee is not especially efficient at making
> use of the meetings. For example, I found some of the plenary sessions,
> especially the one on Friday, to be a waste of time. Instead of dealing
> with more papers, more revisions, I sat around and watched other people
> vote and it wasn't even a binding vote. What was the point of that? And
> there was far too much
>

The Friday plenary is meant to save time on Saturday, because we can remove
motions from the motions list if they don't
pass the Friday "practice vote", and we try to have the discussions about
the motions on Friday rather than on Saturday.
 Passing on Friday is unfortunately not a 100% foolproof indication of
passing on Saturday.


> bikeshed discussion going on, at least in LEWG. But I think more
> importantly, the level of attendance of specific meetings was so
>

The LEWG proceedings did leave quite a lot to be desired.


> paper-dependent that really, the optimum scheduling would not revolve
> around subgroups at all, but which papers people wished to attend the
> discussion of.
>

We do try to achieve that, by instructing the subgroups to drag certain
people into the room when a certain paper
is discussed, and to avoid conflicts for the key people. That doesn't
always succeed.


>
> Finally, I can see why the Committee does not wish to open up their
> mailing lists to everybody. std-proposals has, in the circles I frequent,
> become a byword for proof for Sturgeon's Law, and it's no wonder that the
> Committee wants to protect themselves from that. But if you're going to
> operate a giant filter between the haves and have-nots, as it were, and
> then call for a bunch of new proposals from new authors, then there should
> be some system or advice as to what exactly is required to be a person that
> the Committee wants to take seriously, because it's seriously off-putting
> to be trying to generate decent proposals and then be locked out from the
> feedback that I could really use.
>

The improvement I seek first of all is that the subgroups tell paper
authors who weren't present in the discussion what
the feedback was, as not everybody can read the feedback from the wiki. I
think we also need to start a process
where a paper is given a heads-up on the committee lists as soon as it
arrives, and we ask for committee volunteers
to help the papers along.


> If the Committee really wants a bunch of new proposals and new authors,
> they should consider not treating all authors who haven't already attended
> ten meetings like crap. I don't know if there's interest in updated
> versions of any of my proposals, or a few others
>

The interest in updated versions is the very thing a *EWG should give
guidance on. It's unfortunate and flat out wrong
if you didn't get that feedback for your papers. Asking the relevant *EWG
head is one way to find out about these things.
I collect the EWG proposals into the issues list with indication about
whether an updated proposal is deemed worthwhile,
and why. I hope the LEWG (and Study Groups) follows suit.

I could make, but if Chicago is gonna be like Bristol, then I'm really not
> sure if it's gonna be worth my time and money- and I'm not the only one who
> feels this way.
>
>
>
>
Perseverance is a virtue when dealing with this particular committee. ;)

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--e89a8f6465c3bb7d4604dda153db
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 26 May 2013 16:30, DeadMG <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:wolfeinstein@gmail.com" target=3D"_blank">wolfeinstein@gmail.com</a>&gt;<=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Ville, the main thing I&#39;m going to say h=
ere is that it&#39;s very difficult to get any pre-meeting feedback- at lea=
st, that was my experience. When I presented the Unicode paper in Bristol, =
I got completely different feedback to what I got, say, here. I mean, </blo=
ckquote>
<div><br></div><div>The problem with this forum indeed is that it has rathe=
r few committee followers. Consensus here doesn&#39;t indicate<br>much anyt=
hing.<br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
what exactly do you intend here?<div class=3D"im"><div><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width=
:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-lef=
t:1ex">
Get it ready before a meeting or it will be flat out rejected=A0</blockquot=
e><div><br></div></div><div>That&#39;s what we already had in Bristol, esse=
ntially.</div></blockquote><div><br></div><div>Oh, that was a snide remark =
against the idea of not being able to discuss proposals in a meeting at<br>
all. If you get a complete rejection in a meeting, then that&#39;s that, bu=
t if you get feedback that says<br>the paper is otherwise ok, but needs cer=
tain fixes, those are theoretically possible to fix during a meeting.<br>
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div><br></div><div>Firstly, I&=
#39;m going to say that the call for papers was kind of badly timed, since =
everyone who answered it had their proposals moved to second tier because t=
hey weren&#39;t going to be ready for C++14. Secondly, in my experience, th=
e feedback gained here is, </div>
</blockquote><div><br></div><div>Yep. The call for papers came out after Ko=
na, and it probably would&#39;ve been helpful to get it out sooner.<br>=A0<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">
<div>well, it&#39;s kinda helpful, but it&#39;s in no way preparation for a=
ttending a meeting and finding what feedback you&#39;re going to get there.=
 Bristol was my first meeting, and one of my papers was essentially worthle=
ss which I simply should not have submitted in the first place (n3575), but=
 for the other three, I could have presented a version that would have addr=
essed the Committee&#39;s concerns- if I had actually known what those conc=
erns were before going. For example, it took Jeffrey less than five minutes=
 to sink N3574. I mean, sure, ultimately the quality of the paper being pre=
sented is the responsibility of the presenter, but it&#39;s difficult to pr=
esent a good paper when the only way to find out if it&#39;s good enough is=
 to go to a meeting and present it- not to mention the vast waste of time e=
ntailed.</div>
</blockquote><div><br></div><div>Yes. This is why you should try and find c=
ommittee members to help with your papers.<br>=A0<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">
<div><br></div><div>Secondly, I think that the Committee is not especially =
efficient at making use of the meetings. For example, I found some of the p=
lenary sessions, especially the one on Friday, to be a waste of time. Inste=
ad of dealing with more papers, more revisions, I sat around and watched ot=
her people vote and it wasn&#39;t even a binding vote. What was the point o=
f that? And there was far too much </div>
</blockquote><div><br></div><div>The Friday plenary is meant to save time o=
n Saturday, because we can remove motions from the motions list if they don=
&#39;t<br>pass the Friday &quot;practice vote&quot;, and we try to have the=
 discussions about the motions on Friday rather than on Saturday.<br>
=A0Passing on Friday is unfortunately not a 100% foolproof indication of pa=
ssing on Saturday.<br>=A0<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>bik=
eshed discussion going on, at least in LEWG. But I think more importantly, =
the level of attendance of specific meetings was so </div>
</blockquote><div><br></div><div>The LEWG proceedings did leave quite a lot=
 to be desired.<br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>paper-d=
ependent that really, the optimum scheduling would not revolve around subgr=
oups at all, but which papers people wished to attend the discussion of.</d=
iv>
</blockquote><div><br></div><div>We do try to achieve that, by instructing =
the subgroups to drag certain people into the room when a certain paper<br>=
is discussed, and to avoid conflicts for the key people. That doesn&#39;t a=
lways succeed.<br>
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div><br></div><div>Finally, I =
can see why the Committee does not wish to open up their mailing lists to e=
verybody. std-proposals has, in the circles I frequent, become a byword for=
 proof for Sturgeon&#39;s Law, and it&#39;s no wonder that the Committee wa=
nts to protect themselves from that. But if you&#39;re going to operate a g=
iant filter between the haves and have-nots, as it were, and then call for =
a bunch of new proposals from new authors, then there should be some system=
 or advice as to what exactly is required to be a person that the Committee=
 wants to take seriously, because it&#39;s seriously off-putting to be tryi=
ng to generate decent proposals and then be locked out from the feedback th=
at I could really use. </div>
</blockquote><div><br></div><div>The improvement I seek first of all is tha=
t the subgroups tell paper authors who weren&#39;t present in the discussio=
n what<br>the feedback was, as not everybody can read the feedback from the=
 wiki. I think we also need to start a process<br>
where a paper is given a heads-up on the committee lists as soon as it arri=
ves, and we ask for committee volunteers<br>to help the papers along.<br></=
div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>If the Committee really wants a bunch of new proposals and new authors=
, they should consider not treating all authors who haven&#39;t already att=
ended ten meetings like crap. I don&#39;t know if there&#39;s interest in u=
pdated versions of any of my proposals, or a few others </div>
</blockquote><div><br></div><div>The interest in updated versions is the ve=
ry thing a *EWG should give guidance on. It&#39;s unfortunate and flat out =
wrong<br>if you didn&#39;t get that feedback for your papers. Asking the re=
levant *EWG head is one way to find out about these things.<br>
</div><div>I collect the EWG proposals into the issues list with indication=
 about whether an updated proposal is deemed worthwhile,<br>and why. I hope=
 the LEWG (and Study Groups) follows suit. <br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<div>I could make, but if Chicago is gonna be like Bristol, then I&#39;m re=
ally not sure if it&#39;s gonna be worth my time and money- and I&#39;m not=
 the only one who feels this way.</div><div class=3D"HOEnZb"><div class=3D"=
h5">


<p></p>

<br><br></div></div></blockquote><div><br></div><div>Perseverance is a virt=
ue when dealing with this particular committee. ;) <br></div></div><br></di=
v></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--e89a8f6465c3bb7d4604dda153db--

.

------=_Part_81_29868032.1369587024901
Content-Type: text/plain; charset=ISO-8859-1


>
> If you get a complete rejection in a meeting, then that's that, but if you
> get feedback that says the paper is otherwise ok, but needs certain fixes,
> those are theoretically possible to fix during a meeting.


Technically, yes. But, at least in Bristol, that was certainly not the
reality for all but a very few papers. Even stuff like string_view, which
we could have okayed in Bristol given the recommended changes, didn't come
back.

Yes. This is why you should try and find committee members to help with
> your papers.


Yes, but how? I mean, I attended Bristol so I could probably produce a mail
for a few members, but at the most fundamental level, if the information
for contacting the Committee members is public enough for prospective
authors to find them as feedback, how is that different from making the
internal mailing list public? What I'm saying is that you can't both
secrete yourself away to hide from the rubbish *and* tell people to come
find you for feedback on serious papers, because surprise- since you're
hidden away, people can't find you. (I don't mean you specifically, of
course).

The Friday plenary is meant to save time on Saturday, because we can remove
> motions from the motions list if they don't pass the Friday "practice
> vote", and we try to have the discussions about the motions on Friday
> rather than on Saturday. Passing on Friday is unfortunately not a 100%
> foolproof indication of passing on Saturday.


Sure- but only the *voting members* and maybe the paper authors need to be
there. Everybody else could be doing something else and served little
purpose.

The improvement I seek first of all is that the subgroups tell paper
> authors who weren't present in the discussion what the feedback was, as not
> everybody can read the feedback from the wiki. I think we also need to
> start a process where a paper is given a heads-up on the committee lists as
> soon as it arrives, and we ask for committee volunteers to help the papers
> along.


Yes. I personally have posted feedback from the wiki to paper authors who
weren't present, but I also think that the ad-hoc note-taking I've seen
needs to be replaced with something more effective. I personally did not
volunteer to take notes because my hearing is terrible and I can't blame
anyone else for taking bad notes, but there are some things where I got
feedback in Bristol, forgot what it was, but it's not recorded on the wiki.

The interest in updated versions is the very thing a *EWG should give
> guidance on. It's unfortunate and flat out wrong if you didn't get that
> feedback for your papers.


Er, that was a poor choice of phrasing. I did get that feedback when I
attended Bristol. What I meant was more like, *how much *interest. It's a
give and take, and I feel that waiting five or six months for five minutes
of the Committee's time is not them holding up their end of the bargain.
It's a waste of my time to work on it without the proper feedback, and it's
a waste of the Committee's time to fly half way across the world to debate
it when they could do so from the comfort of wherever they choose to live
for nothing.

Perseverance is a virtue when dealing with this particular committee


There's a difference between "Patience is a virtue; you need patience to
get stuff through Committee" and "We needlessly delay everything massively,
and then we tell you to just go deal with std-proposals between meetings
and it'll be fine".

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_81_29868032.1369587024901
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style=
: solid; padding-left: 1ex;">If you get a complete rejection in a meeting, =
then that's that, but if you get feedback that says&nbsp;the paper is other=
wise ok, but needs certain fixes, those are theoretically possible to fix d=
uring a meeting.</blockquote><div><br></div><div>Technically, yes. But, at =
least in Bristol, that was certainly not the reality for all but a very few=
 papers. Even stuff like string_view, which we could have okayed in Bristol=
 given the recommended changes, didn't come back.</div><div><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-lef=
t-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: sol=
id; padding-left: 1ex;">Yes. This is why you should try and find committee =
members to help with your papers.</blockquote><div><br></div><div>Yes, but =
how? I mean, I attended Bristol so I could probably produce a mail for a fe=
w members, but at the most fundamental level, if the information for contac=
ting the Committee members is public enough for prospective authors to find=
 them as feedback, how is that different from making the internal mailing l=
ist public? What I'm saying is that you can't both secrete yourself away to=
 hide from the rubbish <i>and</i>&nbsp;tell people to come find you for fee=
dback on serious papers, because surprise- since you're hidden away, people=
 can't find you. (I don't mean you specifically, of course).</div><div><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex;=
 border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left=
-style: solid; padding-left: 1ex;">The Friday plenary is meant to save time=
 on Saturday, because we can remove motions from the motions list if they d=
on't&nbsp;pass the Friday "practice vote", and we try to have the discussio=
ns about the motions on Friday rather than on Saturday.&nbsp;Passing on Fri=
day is unfortunately not a 100% foolproof indication of passing on Saturday=
..</blockquote><div><br></div><div>Sure- but only the <i>voting members</i>&=
nbsp;and maybe the paper authors need to be there. Everybody else could be =
doing something else and served little purpose.</div><div><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-=
width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid=
; padding-left: 1ex;">The improvement I seek first of all is that the subgr=
oups tell paper authors who weren't present in the discussion what the feed=
back was, as not everybody can read the feedback from the wiki. I think we =
also need to start a process where a paper is given a heads-up on the commi=
ttee lists as soon as it arrives, and we ask for committee volunteers to he=
lp the papers along.</blockquote><div><br></div><div>Yes. I personally have=
 posted feedback from the wiki to paper authors who weren't present, but I =
also think that the ad-hoc note-taking I've seen needs to be replaced with =
something more effective. I personally did not volunteer to take notes beca=
use my hearing is terrible and I can't blame anyone else for taking bad not=
es, but there are some things where I got feedback in Bristol, forgot what =
it was, but it's not recorded on the wiki.</div><div><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width=
: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; pad=
ding-left: 1ex;">The interest in updated versions is the very thing a *EWG =
should give guidance on. It's unfortunate and flat out wrong&nbsp;if you di=
dn't get that feedback for your papers.</blockquote><div><br></div><div>Er,=
 that was a poor choice of phrasing. I did get that feedback when I attende=
d Bristol. What I meant was more like, <i>how much </i>interest. It's a giv=
e and take, and I feel that waiting five or six months for five minutes of =
the Committee's time is not them holding up their end of the bargain. It's =
a waste of my time to work on it without the proper feedback, and it's a wa=
ste of the Committee's time to fly half way across the world to debate it w=
hen they could do so from the comfort of wherever they choose to live for n=
othing.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, =
204, 204); border-left-style: solid; padding-left: 1ex;">Perseverance is a =
virtue when dealing with this particular committee</blockquote><div><br></d=
iv><div>There's a difference between "Patience is a virtue; you need patien=
ce to get stuff through Committee" and "We needlessly delay everything mass=
ively, and then we tell you to just go deal with std-proposals between meet=
ings and it'll be fine".&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_81_29868032.1369587024901--

.

--047d7bdca64ae92bfd04dda20a4a
Content-Type: text/plain; charset=ISO-8859-1

On 26 May 2013 19:50, DeadMG <wolfeinstein@gmail.com> wrote:

> If you get a complete rejection in a meeting, then that's that, but if you
>> get feedback that says the paper is otherwise ok, but needs certain fixes,
>> those are theoretically possible to fix during a meeting.
>
>
> Technically, yes. But, at least in Bristol, that was certainly not the
> reality for all but a very few papers. Even stuff like string_view, which
> we could have okayed in Bristol given the recommended changes, didn't come
> back.
>

I think that was because its author was standing in for the LEWG chair, and
had too many things on his hands.
Chairing a working group and authoring papers don't mix well.


>
> Yes. This is why you should try and find committee members to help with
>> your papers.
>
>
> Yes, but how? I mean, I attended Bristol so I could probably produce a
> mail for a few members, but at the most fundamental level, if the
> information for contacting the Committee members is public enough for
> prospective authors to find them as feedback, how is that different from
> making the internal mailing list public? What I'm saying is that you can't
> both secrete yourself away to hide from the rubbish *and* tell people to
> come find you for feedback on serious papers, because surprise- since
> you're hidden away, people can't find you. (I don't mean you specifically,
> of course).
>

Sure. As I said below, when a paper comes in to the lwgchair or whatever,
the chair should preferably try and find
a volunteer who can at least mentor, and even better champion the paper,
and that volunteer should talk to
the paper author directly.


>
> The Friday plenary is meant to save time on Saturday, because we can
>> remove motions from the motions list if they don't pass the Friday
>> "practice vote", and we try to have the discussions about the motions on
>> Friday rather than on Saturday. Passing on Friday is unfortunately not a
>> 100% foolproof indication of passing on Saturday.
>
>
> Sure- but only the *voting members* and maybe the paper authors need to
> be there. Everybody else could be doing something else and served little
> purpose.
>

Probably. The WG/SG chairs will be in the plenary, so what you can achieve
during those sessions is unofficial
at any rate (and double so because when the plenary starts, new motions no
longer come in). It's not unprecedented
that people who don't have voting rights or discussion input in the plenary
spend that time elsewhere.



> The improvement I seek first of all is that the subgroups tell paper
>> authors who weren't present in the discussion what the feedback was, as not
>> everybody can read the feedback from the wiki. I think we also need to
>> start a process where a paper is given a heads-up on the committee lists as
>> soon as it arrives, and we ask for committee volunteers to help the papers
>> along.
>
>
> Yes. I personally have posted feedback from the wiki to paper authors who
> weren't present, but I also think that the ad-hoc note-taking I've seen
> needs to be replaced with something more effective. I personally did not
> volunteer to take notes because my hearing is terrible and I can't blame
> anyone else for taking bad notes, but there are some things where I got
> feedback in Bristol, forgot what it was, but it's not recorded on the wiki.
>

I do recommend taking your own notes, if you're presenting a paper. That's
hard to do, but even if it slows your presentation
down, do it anyway. I don't expect we'll get any professional stenographers
any time soon. The note-takers are volunteers
just like everybody else, and it's a bitching hard job - I have taken EWG
notes for quite some time now, and it's anything
but easy.



>
> The interest in updated versions is the very thing a *EWG should give
>> guidance on. It's unfortunate and flat out wrong if you didn't get that
>> feedback for your papers.
>
>
> Er, that was a poor choice of phrasing. I did get that feedback when I
> attended Bristol. What I meant was more like, *how much *interest. It's a
> give and take, and I feel that waiting five or six months for five minutes
> of the Committee's time is not them holding up their end of the bargain.
> It's a waste of my time to work on it without the proper feedback, and it's
> a waste of the Committee's time to fly half way across the world to debate
> it when they could do so from the comfort of wherever they choose to live
> for nothing.
>

Yep, it's unfortunate that in different meetings you may have very
different people in a room, giving very different
feedback. One remedy against that is referring to the previous feedback.
Getting between-meeting feedback
would perhaps be possible if there's a committee mentor/champion to help
with that, as I suggested.


> Perseverance is a virtue when dealing with this particular committee
>
>
> There's a difference between "Patience is a virtue; you need patience to
> get stuff through Committee" and "We needlessly delay everything massively,
> and then we tell you to just go deal with std-proposals between meetings
> and it'll be fine".
>
>
>
>
I don't agree with the "needlessly", but otherwise there's room for
improvement both on how the committee handles
things and how the proposal authors do their part, I think.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--047d7bdca64ae92bfd04dda20a4a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 26 May 2013 19:50, DeadMG <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:wolfeinstein@gmail.com" target=3D"_blank">wolfeinstein@gmail.com</a>&gt;<=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left=
-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
If you get a complete rejection in a meeting, then that&#39;s that, but if =
you get feedback that says=A0the paper is otherwise ok, but needs certain f=
ixes, those are theoretically possible to fix during a meeting.</blockquote=
>
<div><br></div></div><div>Technically, yes. But, at least in Bristol, that =
was certainly not the reality for all but a very few papers. Even stuff lik=
e string_view, which we could have okayed in Bristol given the recommended =
changes, didn&#39;t come back.</div>
</blockquote><div><br></div><div>I think that was because its author was st=
anding in for the LEWG chair, and had too many things on his hands.<br></di=
v><div>Chairing a working group and authoring papers don&#39;t mix well.<br=
>
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div class=3D"im"><div><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid=
;padding-left:1ex">
Yes. This is why you should try and find committee members to help with you=
r papers.</blockquote><div><br></div></div><div>Yes, but how? I mean, I att=
ended Bristol so I could probably produce a mail for a few members, but at =
the most fundamental level, if the information for contacting the Committee=
 members is public enough for prospective authors to find them as feedback,=
 how is that different from making the internal mailing list public? What I=
&#39;m saying is that you can&#39;t both secrete yourself away to hide from=
 the rubbish <i>and</i>=A0tell people to come find you for feedback on seri=
ous papers, because surprise- since you&#39;re hidden away, people can&#39;=
t find you. (I don&#39;t mean you specifically, of course).</div>
</blockquote><div><br></div><div>Sure. As I said below, when a paper comes =
in to the lwgchair or whatever, the chair should preferably try and find<br=
>a volunteer who can at least mentor, and even better champion the paper, a=
nd that volunteer should talk to<br>
the paper author directly.<br>=A0<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div class=3D"im"><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,20=
4,204);border-left-style:solid;padding-left:1ex">
The Friday plenary is meant to save time on Saturday, because we can remove=
 motions from the motions list if they don&#39;t=A0pass the Friday &quot;pr=
actice vote&quot;, and we try to have the discussions about the motions on =
Friday rather than on Saturday.=A0Passing on Friday is unfortunately not a =
100% foolproof indication of passing on Saturday.</blockquote>
<div><br></div></div><div>Sure- but only the <i>voting members</i>=A0and ma=
ybe the paper authors need to be there. Everybody else could be doing somet=
hing else and served little purpose.</div></blockquote><div><br></div><div>
Probably. The WG/SG chairs will be in the plenary, so what you can achieve =
during those sessions is unofficial<br>at any rate (and double so because w=
hen the plenary starts, new motions no longer come in). It&#39;s not unprec=
edented<br>
that people who don&#39;t have voting rights or discussion input in the ple=
nary spend that time elsewhere.=A0 <br><br><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
<div class=3D"im"><div><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,2=
04,204);border-left-style:solid;padding-left:1ex">The improvement I seek fi=
rst of all is that the subgroups tell paper authors who weren&#39;t present=
 in the discussion what the feedback was, as not everybody can read the fee=
dback from the wiki. I think we also need to start a process where a paper =
is given a heads-up on the committee lists as soon as it arrives, and we as=
k for committee volunteers to help the papers along.</blockquote>
<div><br></div></div><div>Yes. I personally have posted feedback from the w=
iki to paper authors who weren&#39;t present, but I also think that the ad-=
hoc note-taking I&#39;ve seen needs to be replaced with something more effe=
ctive. I personally did not volunteer to take notes because my hearing is t=
errible and I can&#39;t blame anyone else for taking bad notes, but there a=
re some things where I got feedback in Bristol, forgot what it was, but it&=
#39;s not recorded on the wiki.</div>
</blockquote><div><br></div><div>I do recommend taking your own notes, if y=
ou&#39;re presenting a paper. That&#39;s hard to do, but even if it slows y=
our presentation<br>down, do it anyway. I don&#39;t expect we&#39;ll get an=
y professional stenographers any time soon. The note-takers are volunteers<=
br>
just like everybody else, and it&#39;s a bitching hard job - I have taken E=
WG notes for quite some time now, and it&#39;s anything<br>but easy.<br><br=
>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im"><div><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,2=
04,204);border-left-style:solid;padding-left:1ex">The interest in updated v=
ersions is the very thing a *EWG should give guidance on. It&#39;s unfortun=
ate and flat out wrong=A0if you didn&#39;t get that feedback for your paper=
s.</blockquote>
<div><br></div></div><div>Er, that was a poor choice of phrasing. I did get=
 that feedback when I attended Bristol. What I meant was more like, <i>how =
much </i>interest. It&#39;s a give and take, and I feel that waiting five o=
r six months for five minutes of the Committee&#39;s time is not them holdi=
ng up their end of the bargain. It&#39;s a waste of my time to work on it w=
ithout the proper feedback, and it&#39;s a waste of the Committee&#39;s tim=
e to fly half way across the world to debate it when they could do so from =
the comfort of wherever they choose to live for nothing.</div>
</blockquote><div><br></div><div>Yep, it&#39;s unfortunate that in differen=
t meetings you may have very different people in a room, giving very differ=
ent<br></div><div>feedback. One remedy against that is referring to the pre=
vious feedback. Getting between-meeting feedback<br>
would perhaps be possible if there&#39;s a committee mentor/champion to hel=
p with that, as I suggested. <br><br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div class=3D"im">
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex">Perseverance is a virtue when dealing with =
this particular committee</blockquote>
<div><br></div></div><div>There&#39;s a difference between &quot;Patience i=
s a virtue; you need patience to get stuff through Committee&quot; and &quo=
t;We needlessly delay everything massively, and then we tell you to just go=
 deal with std-proposals between meetings and it&#39;ll be fine&quot;.=A0</=
div>
<div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

<br><br></div></div></blockquote><div><br></div><div>I don&#39;t agree with=
 the &quot;needlessly&quot;, but otherwise there&#39;s room for improvement=
 both on how the committee handles<br></div><div>things and how the proposa=
l authors do their part, I think. <br>
</div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7bdca64ae92bfd04dda20a4a--

.

On Sun, May 26, 2013 at 1:13 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
>> So how do you know what those "fears", "points" and "corrections" even are
>> without having a discussion with the committee members?
>
>
> I don't know how you know that without such a discussion, the "actively
> allay" means having a discussion with the committee
> members. It doesn't mean that you sit on your arse, wait for the committee
> to contact you, and complain if it doesn't.

So what exactly should've been done? Papers are submitted to the
chair, then what?
Without access to mailing lists the committee reads the only option
seems to be to sit on ones arse.

>> What good does it serve to have all real pre-meeting discussion behind
>> doors that are locked and barred, such that the only way you can get
>> meaningful pre-meeting feedback is by knowing the right people? What is
>> gained by forcing people to fly potentially
>
>
> It cuts down the noise. We have had discussions about opening the committee
> mailing lists read-only to the general
> public, and the example of this forum gives us ample reason not to do so.

How would public read-only access affect noise levels?
IMO without access it gets very hard for paper authors to gather feedback.




--
Olaf

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

--20cf302ef76235629e04dda494c3
Content-Type: text/plain; charset=ISO-8859-1

On 26 May 2013 21:04, Olaf van der Spek <olafvdspek@gmail.com> wrote:

>
> So what exactly should've been done? Papers are submitted to the
> chair, then what?
>

Then ask the chair to please find a mentor/co-champion. That's not part
of the official submission guideline, but let's try to make it to be.


> Without access to mailing lists the committee reads the only option
> seems to be to sit on ones arse.
>

You can get access to those mailing lists, if you ask nicely. It helps if
you're
a delegate of a national body.

>
> It cuts down the noise. We have had discussions about opening the
committee
> mailing lists read-only to the general
> public, and the example of this forum gives us ample reason not to do so.

How would public read-only access affect noise levels?
>

It generates noise _here_, not on the lists themselves. And we frankly
don't want
to limit our flippant discussions out of concern that the general public
might read it.


> IMO without access it gets very hard for paper authors to gather feedback.
>
>
>
Let's see if we can find ways to improve that.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--20cf302ef76235629e04dda494c3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 26 May 2013 21:04, Olaf van der Spek <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com</=
a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><br>
</div>So what exactly should&#39;ve been done? Papers are submitted to the<=
br>
chair, then what?<br></blockquote><div><br></div><div>Then ask the chair to=
 please find a mentor/co-champion. That&#39;s not part<br>of the official s=
ubmission guideline, but let&#39;s try to make it to be.<br>=A0<br></div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Without access to mailing lists the committee reads the only option<br>
seems to be to sit on ones arse.<br></blockquote><div><br></div><div class=
=3D"im">You can get access to those mailing lists, if you ask nicely. It he=
lps if you&#39;re<br>a delegate of a national body.<br><br>&gt;<br>
&gt; It cuts down the noise. We have had discussions about opening the comm=
ittee<br>
&gt; mailing lists read-only to the general<br>
&gt; public, and the example of this forum gives us ample reason not to do =
so.<br>
<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">How would public read-only access affe=
ct noise levels?<br></blockquote><div><br></div><div>It generates noise _he=
re_, not on the lists themselves. And we frankly don&#39;t want<br>
</div><div>to limit our flippant discussions out of concern that the genera=
l public might read it.<br>=A0<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
IMO without access it gets very hard for paper authors to gather feedback.<=
br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br><br></font></span></bloc=
kquote><div><br></div><div>Let&#39;s see if we can find ways to improve tha=
t. <br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--20cf302ef76235629e04dda494c3--

.

------=_Part_1401_24426180.1369647065165
Content-Type: text/plain; charset=ISO-8859-1

On Sunday, May 26, 2013 1:07:17 PM UTC-7, Ville Voutilainen wrote:
>
> On 26 May 2013 21:04, Olaf van der Spek <olafv...@gmail.com <javascript:>>wrote:
>
>>
>> So what exactly should've been done? Papers are submitted to the
>> chair, then what?
>>
>
> Then ask the chair to please find a mentor/co-champion. That's not part
> of the official submission guideline, but let's try to make it to be.
>

We can't do that. Only the isocpp owners can make something "part of the
official submission guideline <http://isocpp.org/std/submit-a-proposal>."
And you are far more likely to know who to talk to about getting that done
than any of us.

IMO without access it gets very hard for paper authors to gather feedback.
>>
>
> Let's see if we can find ways to improve that.
>

This is really not a hard problem to solve. I mean, we're all programmers
here.

We need a way for someone who submits a proposal to be able to get feedback
on it from committee members. *Before* the actual meeting. And we want this
to be a private discussion between the committee members and the author(s)
of the proposal, to cut down on the potential noise.

So... do that. When a proposal is accepted, the author(s) receive a website
URL or a key of some form which they can use to gain access to a website or
something. There, they can have a discussion. All actual committee members
can participate on any of these, but non-member authors are restricted to
just the section talking about their particular proposal.

If some people are allergic to websites, I'm sure that something similar
could be done up through e-mail, with different e-mail addresses for
different proposals. The receiving mail server can screen the return
address to make sure that only the correct people can participate.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_1401_24426180.1369647065165
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sunday, May 26, 2013 1:07:17 PM UTC-7, Ville Voutilainen wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gma=
il_quote">On 26 May 2013 21:04, Olaf van der Spek <span dir=3D"ltr">&lt;<a =
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"GupPyk_Arpc=
J">olafv...@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><br>
</div>So what exactly should've been done? Papers are submitted to the<br>
chair, then what?<br></blockquote><div><br></div><div>Then ask the chair to=
 please find a mentor/co-champion. That's not part<br>of the official submi=
ssion guideline, but let's try to make it to be.<br></div></div></div></div=
></blockquote><div><br>We can't do that. Only the isocpp owners can make so=
mething "part of <a href=3D"http://isocpp.org/std/submit-a-proposal">the of=
ficial submission guideline</a>." And you are far more likely to know who t=
o talk to about getting that done than any of us.<br> <br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail=
_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">
IMO without access it gets very hard for paper authors to gather feedback.<=
span><font color=3D"#888888"><br></font></span></blockquote><div><br></div>=
<div>Let's see if we can find ways to improve that.<br></div></div></div></=
div></blockquote><div><br>This is really not a hard problem to solve. I mea=
n, we're all programmers here.<br><br>We need a way for someone who submits=
 a proposal to be able to get feedback on it from committee members. <i>Bef=
ore</i> the actual meeting. And we want this to be a private discussion bet=
ween the committee members and the author(s) of the proposal, to cut down o=
n the potential noise.<br><br>So... do that. When a proposal is accepted, t=
he author(s) receive a website URL or a key of some form which they can use=
 to gain access to a website or something. There, they can have a discussio=
n. All actual committee members can participate on any of these, but non-me=
mber authors are restricted to just the section talking about their particu=
lar proposal.<br><br>If some people are allergic to websites, I'm sure that=
 something similar could be done up through e-mail, with different e-mail a=
ddresses for different proposals. The receiving mail server can screen the =
return address to make sure that only the correct people can participate.<b=
r></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1401_24426180.1369647065165--

.

--047d7bdca64a1d6b1b04ddb00117
Content-Type: text/plain; charset=ISO-8859-1

On 27 May 2013 12:31, Nicol Bolas <jmckesson@gmail.com> wrote:

> Then ask the chair to please find a mentor/co-champion. That's not part
>
>> of the official submission guideline, but let's try to make it to be.
>>
>
> We can't do that. Only the isocpp owners can make something "part of the
> official submission guideline <http://isocpp.org/std/submit-a-proposal>."
> And you are far more likely to know who to talk to about getting that done
> than any of us.
>

Indeed. I'll see what I can do.


>
> IMO without access it gets very hard for paper authors to gather feedback.
>>>
>>
>> Let's see if we can find ways to improve that.
>>
>
> This is really not a hard problem to solve. I mean, we're all programmers
> here.
>
> We need a way for someone who submits a proposal to be able to get
> feedback on it from committee members. *Before* the actual meeting. And
> we want this to be a private discussion between the committee members and
> the author(s) of the proposal, to cut down on the potential noise.
>

We seem to agree perfectly.


>
> So... do that. When a proposal is accepted, the author(s) receive a
> website URL or a key of some form which they can use to gain access to a
> website or something. There, they can have a discussion. All actual
> committee members can participate on any of these, but non-member authors
> are restricted to just the section talking about their particular proposal.
>
> If some people are allergic to websites, I'm sure that something similar
> could be done up through e-mail, with different e-mail addresses for
> different proposals. The receiving mail server can screen the return
> address to make sure that only the correct people can participate.
>
>
>
>
I'm not yet sure what the mechanics will be. One option I had in mind was
to just find the interested committee people
(which is something the lwgchair and certain other people, like myself,
need to do) and let them communicate
with the paper author any way they think is best.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--047d7bdca64a1d6b1b04ddb00117
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 27 May 2013 12:31, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Then ask the chair to please find a mentor/c=
o-champion. That&#39;s not part<br><div class=3D"im"><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>of the official submi=
ssion guideline, but let&#39;s try to make it to be.<br></div></div></div><=
/div></blockquote></div><div><br>We can&#39;t do that. Only the isocpp owne=
rs can make something &quot;part of <a href=3D"http://isocpp.org/std/submit=
-a-proposal" target=3D"_blank">the official submission guideline</a>.&quot;=
 And you are far more likely to know who to talk to about getting that done=
 than any of us.<br>
</div></blockquote><div><br></div><div>Indeed. I&#39;ll see what I can do.<=
br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div> <br></div><div class=
=3D"im">
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D=
"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">

IMO without access it gets very hard for paper authors to gather feedback.<=
span><font color=3D"#888888"><br></font></span></blockquote><div><br></div>=
<div>Let&#39;s see if we can find ways to improve that.<br></div></div></di=
v>
</div></blockquote></div><div><br>This is really not a hard problem to solv=
e. I mean, we&#39;re all programmers here.<br><br>We need a way for someone=
 who submits a proposal to be able to get feedback on it from committee mem=
bers. <i>Before</i> the actual meeting. And we want this to be a private di=
scussion between the committee members and the author(s) of the proposal, t=
o cut down on the potential noise.<br>
</div></blockquote><div><br></div><div>We seem to agree perfectly.<br>=A0<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div><br>So... do that. When a propo=
sal is accepted, the author(s) receive a website URL or a key of some form =
which they can use to gain access to a website or something. There, they ca=
n have a discussion. All actual committee members can participate on any of=
 these, but non-member authors are restricted to just the section talking a=
bout their particular proposal.<br>
<br>If some people are allergic to websites, I&#39;m sure that something si=
milar could be done up through e-mail, with different e-mail addresses for =
different proposals. The receiving mail server can screen the return addres=
s to make sure that only the correct people can participate.<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

<br><br></div></div></blockquote><div><br></div><div>I&#39;m not yet sure w=
hat the mechanics will be. One option I had in mind was to just find the in=
terested committee people<br></div><div>(which is something the lwgchair an=
d certain other people, like myself, need to do) and let them communicate<b=
r>
with the paper author any way they think is best. <br></div></div><br></div=
></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7bdca64a1d6b1b04ddb00117--

.

------=_Part_2961_12697702.1369656485626
Content-Type: text/plain; charset=ISO-8859-1


>
> We need a way for someone who submits a proposal to be able to get
> feedback on it from committee members. *Before* the actual meeting. And
> we want this to be a private discussion between the committee members and
> the author(s) of the proposal, to cut down on the potential noise.


Strictly, all proposals have the email address of the author written on
them. It just seems to be that nobody uses it to send feedback before the
meeting. Not to mention that the infrequent nature of the mailings means
that if you got your paper in the pre-meeting mailing, you wouldn't have
that much time to alter it before a meeting anyway.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_2961_12697702.1369656485626
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style=
: solid; padding-left: 1ex;">We need a way for someone who submits a propos=
al to be able to get feedback on it from committee members. <i>Before</i> t=
he actual meeting. And we want this to be a private discussion between the =
committee members and the author(s) of the proposal, to cut down on the pot=
ential noise.</blockquote><div><br></div><div>Strictly, all proposals have =
the email address of the author written on them. It just seems to be that n=
obody uses it to send feedback before the meeting. Not to mention that the =
infrequent nature of the mailings means that if you got your paper in the p=
re-meeting mailing, you wouldn't have that much time to alter it before a m=
eeting anyway.</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2961_12697702.1369656485626--

.

--001a11c3d74050b2a704ddb21093
Content-Type: text/plain; charset=ISO-8859-1

On 27 May 2013 15:08, DeadMG <wolfeinstein@gmail.com> wrote:

> We need a way for someone who submits a proposal to be able to get
>> feedback on it from committee members. *Before* the actual meeting. And
>> we want this to be a private discussion between the committee members and
>> the author(s) of the proposal, to cut down on the potential noise.
>
>
> Strictly, all proposals have the email address of the author written on
> them. It just seems to be that nobody uses it to send feedback before the
> meeting. Not to mention that the infrequent nature of the mailings means
> that if you got your paper in the pre-meeting mailing, you wouldn't have
> that much time to alter it before a meeting anyway.
>
>
>
>
The papers are actually nowadays published between mailings on isocpp.org,
the CD was published
after the post-Bristol mailing that way, and we're far away from the next
mailing. So there's hope, we are
already taking some steps towards improvement.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--001a11c3d74050b2a704ddb21093
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 27 May 2013 15:08, DeadMG <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:wolfeinstein@gmail.com" target=3D"_blank">wolfeinstein@gmail.com</a>&gt;<=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left=
-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
We need a way for someone who submits a proposal to be able to get feedback=
 on it from committee members. <i>Before</i> the actual meeting. And we wan=
t this to be a private discussion between the committee members and the aut=
hor(s) of the proposal, to cut down on the potential noise.</blockquote>
<div><br></div></div><div>Strictly, all proposals have the email address of=
 the author written on them. It just seems to be that nobody uses it to sen=
d feedback before the meeting. Not to mention that the infrequent nature of=
 the mailings means that if you got your paper in the pre-meeting mailing, =
you wouldn&#39;t have that much time to alter it before a meeting anyway.</=
div>
<div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

<br><br></div></div></blockquote><div><br></div><div>The papers are actuall=
y nowadays published between mailings on <a href=3D"http://isocpp.org">isoc=
pp.org</a>, the CD was published<br>after the post-Bristol mailing that way=
, and we&#39;re far away from the next mailing. So there&#39;s hope, we are=
<br>
already taking some steps towards improvement.<br></div></div><br></div></d=
iv>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c3d74050b2a704ddb21093--

.