------=_Part_273_7403556.1358888707340
Content-Type: text/plain; charset=ISO-8859-1

A URI library might certainly be useful. Some comments:
> The accessors is_absolute and is_opaque have been renamed absolute and
opaque in order to be more consistent.
More consistent with what?I think the is_ prefixes are much clearer.
> Example Usage> std::network::uri
uri("http://www.example.com/glynos/?key=value#frag");> assert(*uri.scheme()
== "http");
The return type is optional<string_ref>I think using string_ref is great,
but using optional is not so great. Is there a need to distinguish between
null and empty?The danger of undefined behavior seems too high. For
example, I think it should've been assert(uri.scheme() && *uri.scheme() ==
"http"); if you use optional.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



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

<h3></h3><h3><font color=3D"#000000" face=3D"sans-serif"><span style=3D"lin=
e-height: normal;">A URI library might certainly be useful. Some comments:<=
/span></font></h3><h3><font color=3D"#000000" face=3D"sans-serif"><span sty=
le=3D"line-height: normal;"><br></span></font></h3><h3><font color=3D"#0000=
00" face=3D"sans-serif"><span style=3D"line-height: normal;">&gt; The acces=
sors is_absolute and is_opaque have been renamed absolute and opaque in ord=
er to be more consistent.</span></font></h3><h3><font color=3D"#000000" fac=
e=3D"sans-serif"><span style=3D"line-height: normal;"><br></span></font></h=
3><h3><font color=3D"#000000" face=3D"sans-serif"><span style=3D"line-heigh=
t: normal;">More consistent with what?</span></font></h3><h3><font color=3D=
"#000000" face=3D"sans-serif"><span style=3D"line-height: normal;">I think =
the is_ prefixes are much clearer.</span></font></h3><h3><font color=3D"#00=
0000" face=3D"sans-serif"><span style=3D"line-height: normal;"><br></span><=
/font></h3><h3><font color=3D"#000000" face=3D"sans-serif"><span style=3D"l=
ine-height: normal;">&gt; Example Usage</span></font></h3><h3><font color=
=3D"#000000" face=3D"sans-serif"><span style=3D"line-height: normal;">&gt; =
std::network::uri uri("http://www.example.com/glynos/?key=3Dvalue#frag");</=
span></font></h3><h3><font color=3D"#000000" face=3D"sans-serif"><span styl=
e=3D"line-height: normal;">&gt; assert(*uri.scheme() =3D=3D "http");</span>=
</font></h3><h3><font color=3D"#000000" face=3D"sans-serif"><span style=3D"=
line-height: normal;"><br></span></font></h3><h3><font color=3D"#000000" fa=
ce=3D"sans-serif"><span style=3D"line-height: normal;">The return type is o=
ptional&lt;string_ref&gt;</span></font></h3><h3><font color=3D"#000000" fac=
e=3D"sans-serif"><span style=3D"line-height: normal;">I think using string_=
ref is great, but using optional is not so great. Is there a need to distin=
guish between null and empty?</span></font></h3><h3><font color=3D"#000000"=
 face=3D"sans-serif"><span style=3D"line-height: normal;">The danger of und=
efined behavior seems too high. For example, I think it should've been asse=
rt(uri.scheme() &amp;&amp; *uri.scheme() =3D=3D "http"); if you use optiona=
l.</span></font></h3>

<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 post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.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_273_7403556.1358888707340--

.

On Tue, Jan 22, 2013 at 3:05 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> The danger of undefined behavior seems too high. For example, I think it
> should've been assert(uri.scheme() && *uri.scheme() == "http"); if you use
> optional.

An hard-coded assertion needs no "testing".  A product code can
deploy some testing or just:

  foo(uri.scheme().get_value_or(""));

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Tue, Jan 22, 2013 at 01:05:07PM -0800, Olaf van der Spek wrote:
> A URI library might certainly be useful. Some comments:
> > The accessors is_absolute and is_opaque have been renamed absolute and
> opaque in order to be more consistent.
> More consistent with what?I think the is_ prefixes are much clearer.
> > Example Usage> std::network::uri
> uri("http://www.example.com/glynos/?key=value#frag");> assert(*uri.scheme()
> == "http");
> The return type is optional<string_ref>I think using string_ref is great,
> but using optional is not so great. Is there a need to distinguish between
> null and empty?

Yes, the RFC makes a distinction between null and empty and therefore
the library should also provide that level of information.


Christof

--

http://cmeerw.org                              sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org                   xmpp:cmeerw at cmeerw.org

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

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

On Tue, Jan 22, 2013 at 10:05 PM, Olaf van der Spek <olafvdspek@gmail.com>wrote:

> > The accessors is_absolute and is_opaque have been renamed absolute and
> opaque in order to be more consistent.
> More consistent with what?I think the is_ prefixes are much clearer.


With the rest of the standard library I suppose. All booleans accessors in
the standard library types don't use is_ prefix. Like empty() or size()
functions.

Joel Lamotte

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Tue, Jan 22, 2013 at 10:05 PM, Olaf van der Spek <span dir=3D"ltr">&lt;<=
a href=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.c=
om</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"><h3><font color=3D"#000000" face=3D"sans-ser=
if"><span style=3D"line-height:normal">&gt; The accessors is_absolute and i=
s_opaque have been renamed absolute and opaque in order to be more consiste=
nt.</span></font></h3>
<h3><font color=3D"#000000" face=3D"sans-serif"><span style=3D"line-height:=
normal"><br></span></font></h3><h3><font color=3D"#000000" face=3D"sans-ser=
if"><span style=3D"line-height:normal">More consistent with what?</span></f=
ont></h3>
<h3><font color=3D"#000000" face=3D"sans-serif"><span style=3D"line-height:=
normal">I think the is_ prefixes are much clearer.</span></font></h3></bloc=
kquote></div><br>With the rest of the standard library I suppose. All boole=
ans accessors in the standard library types don&#39;t use is_ prefix. Like =
empty() or size() functions.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra" style>Joel =
Lamotte</div><div class=3D"gmail_extra" style><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 post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.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 />

--f46d044469adbdceeb04d3e95176--

.

On Wed, Jan 23, 2013 at 12:55 AM, Klaim - Jo=EBl Lamotte
<mjklaim@gmail.com> wrote:
>
> On Tue, Jan 22, 2013 at 10:05 PM, Olaf van der Spek <olafvdspek@gmail.com=
>
> wrote:
>>
>> > The accessors is_absolute and is_opaque have been renamed absolute and
>> > opaque in order to be more consistent.
>>
>>
>> More consistent with what?
>>
>> I think the is_ prefixes are much clearer.
>
>
> With the rest of the standard library I suppose. All booleans accessors i=
n
> the standard library types don't use is_ prefix. Like empty() or size()
> functions.

size isn't a boolean property. is_open (iostream) is, though.
So the standard library isn't entirely consistent itself.


Olaf

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



.

On Tue, Jan 22, 2013 at 4:05 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> A URI library might certainly be useful.

See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3507.html

--Beman

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

------=_Part_3282_18342814.1358929982323
Content-Type: text/plain; charset=ISO-8859-1

I've found a lot of occurences of "empty" in RFC3986 ("the path may be empty
(no characters)", page 16; "the registered name is empty (zero length)",
page 21... ) but no occurences of the word "null".
Could you please tell us which RFC you are referring to and where is the
distinction between null and empty is made?

Vincent

On Tuesday, January 22, 2013 11:05:12 PM UTC+1, Christof Meerwald wrote:
>
> On Tue, Jan 22, 2013 at 01:05:07PM -0800, Olaf van der Spek wrote:
> > A URI library might certainly be useful. Some comments:
> > > The accessors is_absolute and is_opaque have been renamed absolute and
> > opaque in order to be more consistent.
> > More consistent with what?I think the is_ prefixes are much clearer.
> > > Example Usage> std::network::uri
> > uri("http://www.example.com/glynos/?key=value#frag");>
> assert(*uri.scheme()
> > == "http");
> > The return type is optional<string_ref>I think using string_ref is
> great,
> > but using optional is not so great. Is there a need to distinguish
> between
> > null and empty?
>
> Yes, the RFC makes a distinction between null and empty and therefore
> the library should also provide that level of information.
>
>
> Christof
>
> --
>
> http://cmeerw.org                              sip:cmeerw at cmeerw.org
> mailto:cmeerw <javascript:> at cmeerw.org                   xmpp:cmeerw
> at cmeerw.org
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



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

I've found a lot of occurences of "empty" in RFC3986 ("<span style=3D"color=
: rgb(0, 0, 0); font-size: 1em;">the path may be&nbsp;</span><span style=3D=
"color: rgb(0, 0, 0); font-size: 1em;">empty (no characters)", page 16; "</=
span><span style=3D"color: rgb(0, 0, 0); font-size: 1em;">the</span><span s=
tyle=3D"font-size: 1em;">&nbsp;</span><span style=3D"color: rgb(0, 0, 0); f=
ont-size: 1em;">registered name is empty (zero length)", page 21...</span>&=
nbsp;) but no occurences of the word "null".<div>Could you please tell us w=
hich RFC you are referring to and where is the distinction between null and=
 empty is made?</div><div><br></div><div>Vincent<br><br>On Tuesday, January=
 22, 2013 11:05:12 PM UTC+1, Christof Meerwald wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;">On Tue, Jan 22, 2013 at 01:05:07PM -0800, Olaf van d=
er Spek wrote:
<br>&gt; A URI library might certainly be useful. Some comments:
<br>&gt; &gt; The accessors is_absolute and is_opaque have been renamed abs=
olute and=20
<br>&gt; opaque in order to be more consistent.
<br>&gt; More consistent with what?I think the is_ prefixes are much cleare=
r.
<br>&gt; &gt; Example Usage&gt; std::network::uri=20
<br>&gt; uri("<a href=3D"http://www.example.com/glynos/?key=3Dvalue#frag" t=
arget=3D"_blank">http://www.example.com/<wbr>glynos/?key=3Dvalue#frag</a>")=
;&gt; assert(*uri.scheme()=20
<br>&gt; =3D=3D "http");
<br>&gt; The return type is optional&lt;string_ref&gt;I think using string_=
ref is great,=20
<br>&gt; but using optional is not so great. Is there a need to distinguish=
 between=20
<br>&gt; null and empty?
<br>
<br>Yes, the RFC makes a distinction between null and empty and therefore
<br>the library should also provide that level of information.
<br>
<br>
<br>Christof
<br>
<br>--=20
<br>
<br><a href=3D"http://cmeerw.org" target=3D"_blank">http://cmeerw.org</a> &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp;sip:cmeerw at <a href=3D"http://cmeerw.org" tar=
get=3D"_blank">cmeerw.org</a>
<br>mailto:<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"8ytOIu1WTSQJ">cmeerw</a> at <a href=3D"http://cmeerw.org" target=3D"_bl=
ank">cmeerw.org</a> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; xmpp:cmeerw at <a href=3D"http://cmeerw.org" target=3D"_blank">cmee=
rw.org</a>
<br></blockquote></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 post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.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_3282_18342814.1358929982323--

.

On Wed, Jan 23, 2013 at 12:33:02AM -0800, Vincent Jacquet wrote:
> I've found a lot of occurences of "empty" in RFC3986 ("the path may be empty
> (no characters)", page 16; "the registered name is empty (zero length)",
> page 21... ) but no occurences of the word "null".
> Could you please tell us which RFC you are referring to and where is the
> distinction between null and empty is made?

Sorry, null was the wrong term, RFC 3986 talks about empty and
undefined, for example in 5.3 "Note that we are careful to preserve
the distinction between a component that is undefined, meaning that
its separator was not present in the reference, and a component that
is empty, meaning that the separator was present and was immediately
followed by the next component separator or the end of the reference."

It probably needs to be reviewed if the modelling of what can be
undefined matches the RFC (I think a path can be empty, but not
undefined).


Christof

--

http://cmeerw.org                              sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org                   xmpp:cmeerw at cmeerw.org

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Wed, Jan 23, 2013 at 10:01 AM, Christof Meerwald <cmeerw@cmeerw.org> wrote:
> On Wed, Jan 23, 2013 at 12:33:02AM -0800, Vincent Jacquet wrote:
>> I've found a lot of occurences of "empty" in RFC3986 ("the path may be empty
>> (no characters)", page 16; "the registered name is empty (zero length)",
>> page 21... ) but no occurences of the word "null".
>> Could you please tell us which RFC you are referring to and where is the
>> distinction between null and empty is made?
>
> Sorry, null was the wrong term, RFC 3986 talks about empty and
> undefined, for example in 5.3 "Note that we are careful to preserve
> the distinction between a component that is undefined, meaning that
> its separator was not present in the reference, and a component that
> is empty, meaning that the separator was present and was immediately
> followed by the next component separator or the end of the reference."
>
> It probably needs to be reviewed if the modelling of what can be
> undefined matches the RFC (I think a path can be empty, but not
> undefined).

Do you know of any real world code that uses that distinction?
What % of use cases require that distinction?

Could the issue by solved by having bool has_*() properties?
--
Olaf

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Wed, Jan 23, 2013 at 10:05:29AM +0100, Olaf van der Spek wrote:
> On Wed, Jan 23, 2013 at 10:01 AM, Christof Meerwald <cmeerw@cmeerw.org> wrote:
> > Sorry, null was the wrong term, RFC 3986 talks about empty and
> > undefined, for example in 5.3 "Note that we are careful to preserve
> > the distinction between a component that is undefined, meaning that
> > its separator was not present in the reference, and a component that
> > is empty, meaning that the separator was present and was immediately
> > followed by the next component separator or the end of the reference."
> >
> > It probably needs to be reviewed if the modelling of what can be
> > undefined matches the RFC (I think a path can be empty, but not
> > undefined).
> Do you know of any real world code that uses that distinction?
> What % of use cases require that distinction?

for the fragment part: any web browser behaves differently between
having an empty fragment or no fragment.

for the query part: any HTTP proxy server (and probably also web
browser) will want to know if there is an empty query part or none at
all (as it will affect caching behaviour).

For the other parts the distinction is probably only needed if you
wanted to implemented operations like normalize or resolve yourself.


> Could the issue by solved by having bool has_*() properties?

It could be, but I am not convinced that it would be a better
approach.


Christof

--

http://cmeerw.org                              sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org                   xmpp:cmeerw at cmeerw.org

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

2013/1/23 Christof Meerwald <cmeerw@cmeerw.org>:
> On Wed, Jan 23, 2013 at 10:05:29AM +0100, Olaf van der Spek wrote:
>> On Wed, Jan 23, 2013 at 10:01 AM, Christof Meerwald <cmeerw@cmeerw.org> wrote:
>> > Sorry, null was the wrong term, RFC 3986 talks about empty and
>> > undefined, for example in 5.3 "Note that we are careful to preserve
>> > the distinction between a component that is undefined, meaning that
>> > its separator was not present in the reference, and a component that
>> > is empty, meaning that the separator was present and was immediately
>> > followed by the next component separator or the end of the reference."
>> >
>> > It probably needs to be reviewed if the modelling of what can be
>> > undefined matches the RFC (I think a path can be empty, but not
>> > undefined).
>> Do you know of any real world code that uses that distinction?
>> What % of use cases require that distinction?
>
> for the fragment part: any web browser behaves differently between
> having an empty fragment or no fragment.
>
> for the query part: any HTTP proxy server (and probably also web
> browser) will want to know if there is an empty query part or none at
> all (as it will affect caching behaviour).
>
> For the other parts the distinction is probably only needed if you
> wanted to implemented operations like normalize or resolve yourself.
>
>
>> Could the issue by solved by having bool has_*() properties?
>
> It could be, but I am not convinced that it would be a better
> approach.

I agree. My gut feeling is that this is actually a problem of the
optional interface. I'm currently suggesting to add a function that
retrieves its content in a checked manner, since calling operator* for
a disengaged value would be undefined.

- Daniel

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

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

Who is responsible of knowing if a component of the uri is defined ? The=20
uri or the component ?


On Wednesday, January 23, 2013 11:08:04 AM UTC+1, Daniel Kr=FCgler wrote:
>
> 2013/1/23 Christof Meerwald <cme...@cmeerw.org <javascript:>>:=20
> > On Wed, Jan 23, 2013 at 10:05:29AM +0100, Olaf van der Spek wrote:=20
> >> On Wed, Jan 23, 2013 at 10:01 AM, Christof Meerwald <cme...@cmeerw.org=
<javascript:>>=20
> wrote:=20
> >> > Sorry, null was the wrong term, RFC 3986 talks about empty and=20
> >> > undefined, for example in 5.3 "Note that we are careful to preserve=
=20
> >> > the distinction between a component that is undefined, meaning that=
=20
> >> > its separator was not present in the reference, and a component that=
=20
> >> > is empty, meaning that the separator was present and was immediately=
=20
> >> > followed by the next component separator or the end of the=20
> reference."=20
> >> >=20
> >> > It probably needs to be reviewed if the modelling of what can be=20
> >> > undefined matches the RFC (I think a path can be empty, but not=20
> >> > undefined).=20
> >> Do you know of any real world code that uses that distinction?=20
> >> What % of use cases require that distinction?=20
> >=20
> > for the fragment part: any web browser behaves differently between=20
> > having an empty fragment or no fragment.=20
> >=20
> > for the query part: any HTTP proxy server (and probably also web=20
> > browser) will want to know if there is an empty query part or none at=
=20
> > all (as it will affect caching behaviour).=20
> >=20
> > For the other parts the distinction is probably only needed if you=20
> > wanted to implemented operations like normalize or resolve yourself.=20
> >=20
> >=20
> >> Could the issue by solved by having bool has_*() properties?=20
> >=20
> > It could be, but I am not convinced that it would be a better=20
> > approach.=20
>
> I agree. My gut feeling is that this is actually a problem of the=20
> optional interface. I'm currently suggesting to add a function that=20
> retrieves its content in a checked manner, since calling operator* for=20
> a disengaged value would be undefined.=20
>
> - Daniel=20
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



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

Who is responsible of knowing if a component of the uri is defined ? The ur=
i or the component ?<div><br></div><div><br></div><div>On Wednesday, Januar=
y 23, 2013 11:08:04 AM UTC+1, Daniel Kr=FCgler wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;">2013/1/23 Christof Meerwald &lt;<a href=3D"javascrip=
t:" target=3D"_blank" gdf-obfuscated-mailto=3D"4tC8rokyjy8J">cme...@cmeerw.=
org</a>&gt;:
<br>&gt; On Wed, Jan 23, 2013 at 10:05:29AM +0100, Olaf van der Spek wrote:
<br>&gt;&gt; On Wed, Jan 23, 2013 at 10:01 AM, Christof Meerwald &lt;<a hre=
f=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"4tC8rokyjy8J">=
cme...@cmeerw.org</a>&gt; wrote:
<br>&gt;&gt; &gt; Sorry, null was the wrong term, RFC 3986 talks about empt=
y and
<br>&gt;&gt; &gt; undefined, for example in 5.3 "Note that we are careful t=
o preserve
<br>&gt;&gt; &gt; the distinction between a component that is undefined, me=
aning that
<br>&gt;&gt; &gt; its separator was not present in the reference, and a com=
ponent that
<br>&gt;&gt; &gt; is empty, meaning that the separator was present and was =
immediately
<br>&gt;&gt; &gt; followed by the next component separator or the end of th=
e reference."
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; It probably needs to be reviewed if the modelling of what=
 can be
<br>&gt;&gt; &gt; undefined matches the RFC (I think a path can be empty, b=
ut not
<br>&gt;&gt; &gt; undefined).
<br>&gt;&gt; Do you know of any real world code that uses that distinction?
<br>&gt;&gt; What % of use cases require that distinction?
<br>&gt;
<br>&gt; for the fragment part: any web browser behaves differently between
<br>&gt; having an empty fragment or no fragment.
<br>&gt;
<br>&gt; for the query part: any HTTP proxy server (and probably also web
<br>&gt; browser) will want to know if there is an empty query part or none=
 at
<br>&gt; all (as it will affect caching behaviour).
<br>&gt;
<br>&gt; For the other parts the distinction is probably only needed if you
<br>&gt; wanted to implemented operations like normalize or resolve yoursel=
f.
<br>&gt;
<br>&gt;
<br>&gt;&gt; Could the issue by solved by having bool has_*() properties?
<br>&gt;
<br>&gt; It could be, but I am not convinced that it would be a better
<br>&gt; approach.
<br>
<br>I agree. My gut feeling is that this is actually a problem of the
<br>optional interface. I'm currently suggesting to add a function that
<br>retrieves its content in a checked manner, since calling operator* for
<br>a disengaged value would be undefined.
<br>
<br>- Daniel
<br></blockquote></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 post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.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_107_32160326.1358938475519--

.

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

Another question:
Maybe I missed that part but it is not clear to me how can I check that a
string contain a valid uri without
trying to build a uri object that would throw an exception?
For example if I want to do that check as part of my program's logic, I
don't want that check to be done
through an exception handling mecanism.

Joel Lamotte

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



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

<div dir=3D"ltr"><div style>Another question:=A0</div><div style>Maybe I mi=
ssed that part but it is not clear to me how can I check that a string cont=
ain a valid uri without=A0</div><div style>trying to build a uri object tha=
t would throw an exception?</div>
<div style>For example if I want to do that check as part of my program&#39=
;s logic, I don&#39;t want that check to be done</div><div style>through an=
 exception handling mecanism.</div><div style><br></div><div style>Joel Lam=
otte</div>
<div style><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 post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.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 />

--e89a8fb20446e0b6d804d3f3e929--

.

On Wed, Jan 23, 2013 at 01:34:20PM +0100, Klaim - Jo=EBl Lamotte wrote:
> Another question:
> Maybe I missed that part but it is not clear to me how can I check that a
> string contain a valid uri without
> trying to build a uri object that would throw an exception?
> For example if I want to do that check as part of my program's logic, I
> don't want that check to be done
> through an exception handling mecanism.

there is a noexcept make_uri factory function:

  // factory functions
  template <class String>
  uri make_uri(const String &u, std::error_code &e) noexcept;

  This factory function is provided in order to be able to construct a
  uri object without throwing an exception. The error code is stored
  in the std::error_code object, if there is a syntax error.


Christof

--=20

http://cmeerw.org                              sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org                   xmpp:cmeerw at cmeerw.org

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



.

2013/1/23 Christof Meerwald <cmeerw@cmeerw.org>:
> On Wed, Jan 23, 2013 at 01:34:20PM +0100, Klaim - Jo=EBl Lamotte wrote:
>> Another question:
>> Maybe I missed that part but it is not clear to me how can I check that =
a
>> string contain a valid uri without
>> trying to build a uri object that would throw an exception?
>> For example if I want to do that check as part of my program's logic, I
>> don't want that check to be done
>> through an exception handling mecanism.
>
> there is a noexcept make_uri factory function:
>
>   // factory functions
>   template <class String>
>   uri make_uri(const String &u, std::error_code &e) noexcept;
>
>   This factory function is provided in order to be able to construct a
>   uri object without throwing an exception. The error code is stored
>   in the std::error_code object, if there is a syntax error.

I think this function cannot be safely declared as noexcept, because
uri is a type that acquires (memory) resources and this can lead to an
out-of-memory situation that throws an exception, which will have the
effect of an immediate termination because of the noexcept. This
problem was also fixed in the filesystem library, e.g. have a look at

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3505.html#canonica=
l

where the error_code overload has also not been marked as noexcept anymore.

- Daniel

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



.

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

Olaf,


On 22 January 2013 22:05, Olaf van der Spek <olafvdspek@gmail.com> wrote:

> A URI library might certainly be useful. Some comments:
> > The accessors is_absolute and is_opaque have been renamed absolute and
> opaque in order to be more consistent.
> More consistent with what? I think the is_ prefixes are much clearer.


As someone else said on this thread, they are more consistent with other
examples in the standard library (e.g. std::string::empty()).


> > Example Usage > std::network::uri uri("
> http://www.example.com/glynos/?key=value#frag"); > assert(*uri.scheme()
> == "http");
> The return type is optional<string_ref>I think using string_ref is great,
> but using optional is not so great. Is there a need to distinguish between
> null and empty? The danger of undefined behavior seems too high. For
> example, I think it should've been assert(uri.scheme() && *uri.scheme() ==
> "http"); if you use optional.
>
> --
>

I agree, the example in the document should explicitly show the check for
validity of the part.

Regards,
Glyn

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



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

<div dir=3D"ltr">Olaf,<div class=3D"gmail_extra"><br><br><div class=3D"gmai=
l_quote">On 22 January 2013 22:05, Olaf van der Spek <span dir=3D"ltr">&lt;=
<a href=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"><h3></h3><h3><font color=3D"#000000" face=3D=
"sans-serif"><span style=3D"line-height:normal">A URI library might certain=
ly be useful. Some comments:</span></font></h3>

<h3><font color=3D"#000000" face=3D"sans-serif"><span style=3D"line-height:=
normal"><br></span></font></h3><h3><font color=3D"#000000" face=3D"sans-ser=
if"><span style=3D"line-height:normal">&gt; The accessors is_absolute and i=
s_opaque have been renamed absolute and opaque in order to be more consiste=
nt.</span></font></h3>

<h3><font color=3D"#000000" face=3D"sans-serif"><span style=3D"line-height:=
normal"><br></span></font></h3><h3><font color=3D"#000000" face=3D"sans-ser=
if"><span style=3D"line-height:normal">More consistent with what?</span></f=
ont></h3>

<h3><font color=3D"#000000" face=3D"sans-serif"><span style=3D"line-height:=
normal">I think the is_ prefixes are much clearer.</span></font></h3></bloc=
kquote><div><br></div><div>As someone else said on this thread, they are mo=
re consistent with other examples in the standard library (e.g. std::string=
::empty()).</div>

<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><h3><font color=3D"#000000" fa=
ce=3D"sans-serif"><span style=3D"line-height:normal"></span></font></h3><h3=
><font color=3D"#000000" face=3D"sans-serif"><span style=3D"line-height:nor=
mal">&gt; Example Usage</span></font></h3>

<h3><font color=3D"#000000" face=3D"sans-serif"><span style=3D"line-height:=
normal">&gt; std::network::uri uri(&quot;<a href=3D"http://www.example.com/=
glynos/?key=3Dvalue#frag" target=3D"_blank">http://www.example.com/glynos/?=
key=3Dvalue#frag</a>&quot;);</span></font></h3>

<h3><font color=3D"#000000" face=3D"sans-serif"><span style=3D"line-height:=
normal">&gt; assert(*uri.scheme() =3D=3D &quot;http&quot;);</span></font></=
h3><h3><font color=3D"#000000" face=3D"sans-serif"><span style=3D"line-heig=
ht:normal"><br>

</span></font></h3><h3><font color=3D"#000000" face=3D"sans-serif"><span st=
yle=3D"line-height:normal">The return type is optional&lt;string_ref&gt;</s=
pan></font></h3><h3><font color=3D"#000000" face=3D"sans-serif"><span style=
=3D"line-height:normal">I think using string_ref is great, but using option=
al is not so great. Is there a need to distinguish between null and empty?<=
/span></font></h3>

<h3><font color=3D"#000000" face=3D"sans-serif"><span style=3D"line-height:=
normal">The danger of undefined behavior seems too high. For example, I thi=
nk it should&#39;ve been assert(uri.scheme() &amp;&amp; *uri.scheme() =3D=
=3D &quot;http&quot;); if you use optional.</span></font></h3>

<span><font color=3D"#888888">

<p></p>

-- <br></font></span></blockquote><div><br></div><div>I agree, the example =
in the document should explicitly show the check for validity of the part.<=
/div><div><br></div><div>Regards,</div><div>Glyn</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 post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.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 />

--047d7bfcf91af0a6b704d3f8225e--

.

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

On 23 January 2013 10:47, Christof Meerwald <cmeerw@cmeerw.org> wrote:

> On Wed, Jan 23, 2013 at 10:05:29AM +0100, Olaf van der Spek wrote:
> > On Wed, Jan 23, 2013 at 10:01 AM, Christof Meerwald <cmeerw@cmeerw.org>
> wrote:
> > > Sorry, null was the wrong term, RFC 3986 talks about empty and
> > > undefined, for example in 5.3 "Note that we are careful to preserve
> > > the distinction between a component that is undefined, meaning that
> > > its separator was not present in the reference, and a component that
> > > is empty, meaning that the separator was present and was immediately
> > > followed by the next component separator or the end of the reference."
> > >
> > > It probably needs to be reviewed if the modelling of what can be
> > > undefined matches the RFC (I think a path can be empty, but not
> > > undefined).
> > Do you know of any real world code that uses that distinction?
> > What % of use cases require that distinction?
>
> for the fragment part: any web browser behaves differently between
> having an empty fragment or no fragment.
>
> for the query part: any HTTP proxy server (and probably also web
> browser) will want to know if there is an empty query part or none at
> all (as it will affect caching behaviour).
>
> For the other parts the distinction is probably only needed if you
> wanted to implemented operations like normalize or resolve yourself.
>
>
Which you may want to do with the uri in this proposal, if you want scheme
or protocol-based normalization:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3507.html#the-comparison-ladder

Regards,
Glyn

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--089e0103ee9099622b04d3f82532
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 23 January 2013 10:47, Christof Meerwald <span dir=3D"ltr">&lt;<=
a href=3D"mailto:cmeerw@cmeerw.org" target=3D"_blank">cmeerw@cmeerw.org</a>=
&gt;</span> wrote:<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"><div>On Wed, Jan 23, 2013 at 10:05:29AM +0100, Olaf van de=
r Spek wrote:<br>


&gt; On Wed, Jan 23, 2013 at 10:01 AM, Christof Meerwald &lt;<a href=3D"mai=
lto:cmeerw@cmeerw.org" target=3D"_blank">cmeerw@cmeerw.org</a>&gt; wrote:<b=
r>
</div><div>&gt; &gt; Sorry, null was the wrong term, RFC 3986 talks about e=
mpty and<br>
&gt; &gt; undefined, for example in 5.3 &quot;Note that we are careful to p=
reserve<br>
&gt; &gt; the distinction between a component that is undefined, meaning th=
at<br>
&gt; &gt; its separator was not present in the reference, and a component t=
hat<br>
&gt; &gt; is empty, meaning that the separator was present and was immediat=
ely<br>
&gt; &gt; followed by the next component separator or the end of the refere=
nce.&quot;<br>
&gt; &gt;<br>
&gt; &gt; It probably needs to be reviewed if the modelling of what can be<=
br>
&gt; &gt; undefined matches the RFC (I think a path can be empty, but not<b=
r>
&gt; &gt; undefined).<br>
&gt; Do you know of any real world code that uses that distinction?<br>
&gt; What % of use cases require that distinction?<br>
<br>
</div>for the fragment part: any web browser behaves differently between<br=
>
having an empty fragment or no fragment.<br>
<br>
for the query part: any HTTP proxy server (and probably also web<br>
browser) will want to know if there is an empty query part or none at<br>
all (as it will affect caching behaviour).<br>
<br>
For the other parts the distinction is probably only needed if you<br>
wanted to implemented operations like normalize or resolve yourself.<br>
<div><br></div></blockquote><div><br></div><div>Which you may want to do wi=
th the uri in this proposal, if you want scheme or protocol-based normaliza=
tion:</div><div><br></div><div><a href=3D"http://www.open-std.org/jtc1/sc22=
/wg21/docs/papers/2013/n3507.html#the-comparison-ladder" target=3D"_blank">=
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3507.html#the-comp=
arison-ladder</a></div>

<div><br></div><div>Regards,</div><div>Glyn</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 post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.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 />

--089e0103ee9099622b04d3f82532--

.

On Wed, Jan 23, 2013 at 10:47 AM, Christof Meerwald <cmeerw@cmeerw.org> wrote:
> On Wed, Jan 23, 2013 at 10:05:29AM +0100, Olaf van der Spek wrote:
>> On Wed, Jan 23, 2013 at 10:01 AM, Christof Meerwald <cmeerw@cmeerw.org> wrote:
>> > Sorry, null was the wrong term, RFC 3986 talks about empty and
>> > undefined, for example in 5.3 "Note that we are careful to preserve
>> > the distinction between a component that is undefined, meaning that
>> > its separator was not present in the reference, and a component that
>> > is empty, meaning that the separator was present and was immediately
>> > followed by the next component separator or the end of the reference."
>> >
>> > It probably needs to be reviewed if the modelling of what can be
>> > undefined matches the RFC (I think a path can be empty, but not
>> > undefined).
>> Do you know of any real world code that uses that distinction?
>> What % of use cases require that distinction?
>
> for the fragment part: any web browser behaves differently between
> having an empty fragment or no fragment.
>
> for the query part: any HTTP proxy server (and probably also web
> browser) will want to know if there is an empty query part or none at
> all (as it will affect caching behaviour).

Does it? Seems kinda unnatural. But I'm no expert on that matter.

> For the other parts the distinction is probably only needed if you
> wanted to implemented operations like normalize or resolve yourself.

So for the majority of use cases the distinction isn't necessary?

>> Could the issue by solved by having bool has_*() properties?
>
> It could be, but I am not convinced that it would be a better
> approach.

Why not?
It nicely avoids lots of potential for big trouble.

Olaf

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Wed, Jan 23, 2013 at 08:46:25PM +0100, Olaf van der Spek wrote:
> On Wed, Jan 23, 2013 at 10:47 AM, Christof Meerwald <cmeerw@cmeerw.org> wrote:
> > For the other parts the distinction is probably only needed if you
> > wanted to implemented operations like normalize or resolve yourself.
> So for the majority of use cases the distinction isn't necessary?

Probably, but not having that information available would seem like a
very arbitrary limitation.

> >> Could the issue by solved by having bool has_*() properties?
> >
> > It could be, but I am not convinced that it would be a better
> > approach.
> Why not?
> It nicely avoids lots of potential for big trouble.

If optional gets standardised and on the other hand the URI library
uses a different approach to model optional components because it
"nicely avoids lots of potential for big trouble" then I would claim
that something is wrong with "optional" (I haven't looked in detail at
optional, but I would expect that it does what the name suggests).


Christof

--

http://cmeerw.org                              sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org                   xmpp:cmeerw at cmeerw.org

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

2013/1/23 Christof Meerwald <cmeerw@cmeerw.org>:
> If optional gets standardised and on the other hand the URI library
> uses a different approach to model optional components because it
> "nicely avoids lots of potential for big trouble" then I would claim
> that something is wrong with "optional" (I haven't looked in detail at
> optional, but I would expect that it does what the name suggests).

I completely agree. The URI proposal shouldn't add functionality that
either is or should be provided by a referred to component (like
optional in this case).

- Daniel

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Wed, Jan 23, 2013 at 10:26 PM, Christof Meerwald <cmeerw@cmeerw.org> wrote:
> On Wed, Jan 23, 2013 at 08:46:25PM +0100, Olaf van der Spek wrote:
>> On Wed, Jan 23, 2013 at 10:47 AM, Christof Meerwald <cmeerw@cmeerw.org> wrote:
>> > For the other parts the distinction is probably only needed if you
>> > wanted to implemented operations like normalize or resolve yourself.
>> So for the majority of use cases the distinction isn't necessary?
>
> Probably, but not having that information available would seem like a
> very arbitrary limitation.

The info would be available via bool has_*() properties.

>> >> Could the issue by solved by having bool has_*() properties?
>> >
>> > It could be, but I am not convinced that it would be a better
>> > approach.
>> Why not?
>> It nicely avoids lots of potential for big trouble.
>
> If optional gets standardised and on the other hand the URI library
> uses a different approach to model optional components because it
> "nicely avoids lots of potential for big trouble" then I would claim
> that something is wrong with "optional" (I haven't looked in detail at
> optional, but I would expect that it does what the name suggests).

I don't agree. Optional is a fine tool, but that tool is not
appropriate in all cases.

Your original proposal did not use optional. Why did you move to optional?
Does it benefit existing users of the class? Does it make their code
simpler? Or more complex?

--
Olaf

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Wed, Jan 23, 2013 at 10:39:14PM +0100, Olaf van der Spek wrote:
> On Wed, Jan 23, 2013 at 10:26 PM, Christof Meerwald <cmeerw@cmeerw.org> wrote:
> > If optional gets standardised and on the other hand the URI library
> > uses a different approach to model optional components because it
> > "nicely avoids lots of potential for big trouble" then I would claim
> > that something is wrong with "optional" (I haven't looked in detail at
> > optional, but I would expect that it does what the name suggests).
> I don't agree. Optional is a fine tool, but that tool is not
> appropriate in all cases.
>
> Your original proposal did not use optional. Why did you move to optional?

It's not my proposal (all the credit goes to Glyn Matthews and Dean
Michael Berris) - I am just voicing my opinion (sorry if you got a
different impression)...

When the proposal was changed to not include the '?'-delimiter in the
query part, I pointed out that it wouldn't be possible to distinguish
between an empty and missing query part any more. Therefore some other
way was needed to model that: using optional or adding has_ methods.
And I voiced my preference for using optional.


Christof

--

http://cmeerw.org                              sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org                   xmpp:cmeerw at cmeerw.org

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

I tend to only watch this list for interesting discussions and I
wanted to let Glyn address the points as he's mostly written the paper
with input from me. That said, let me address these points.

On Thu, Jan 24, 2013 at 9:05 AM, Christof Meerwald <cmeerw@cmeerw.org> wrote:
> On Wed, Jan 23, 2013 at 10:39:14PM +0100, Olaf van der Spek wrote:
>> On Wed, Jan 23, 2013 at 10:26 PM, Christof Meerwald <cmeerw@cmeerw.org> wrote:
>> > If optional gets standardised and on the other hand the URI library
>> > uses a different approach to model optional components because it
>> > "nicely avoids lots of potential for big trouble" then I would claim
>> > that something is wrong with "optional" (I haven't looked in detail at
>> > optional, but I would expect that it does what the name suggests).
>> I don't agree. Optional is a fine tool, but that tool is not
>> appropriate in all cases.
>>
>> Your original proposal did not use optional. Why did you move to optional?
>
> It's not my proposal (all the credit goes to Glyn Matthews and Dean
> Michael Berris) - I am just voicing my opinion (sorry if you got a
> different impression)...
>
> When the proposal was changed to not include the '?'-delimiter in the
> query part, I pointed out that it wouldn't be possible to distinguish
> between an empty and missing query part any more. Therefore some other
> way was needed to model that: using optional or adding has_ methods.
> And I voiced my preference for using optional.
>

Yes. The "has_*" methods introduce additional members that don't
really make sense to have.

std::optional<std::string_ref> is perfect in this use case. Here's the
list of reasons:

- If the URI has a part, it should return a reference to that part of
the string.
- If the URI does not have that part explicitly defined, you return an
uninitialised std::optional<>.
- If the URI does have that part explicitly defined but empty, you
return a std::optional<> that had a default-constructed
std::string_ref.

It's also good for value semantics.

I'm opposed to adding more members to the URI class unless it's
absolutely necessary. std::optional<> does this nicely for us
conveying the correct semantics. It keeps the URI class simple and
easy to understand and easy to keep a mental model of.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

------=_Part_388_17019070.1358986266255
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, January 23, 2013 1:39:14 PM UTC-8, Olaf van der Spek wrote:
>
> On Wed, Jan 23, 2013 at 10:26 PM, Christof Meerwald <cme...@cmeerw.org<javascript:>>
> wrote:
> > On Wed, Jan 23, 2013 at 08:46:25PM +0100, Olaf van der Spek wrote:
> >> On Wed, Jan 23, 2013 at 10:47 AM, Christof Meerwald <cme...@cmeerw.org<javascript:>>
> wrote:
> >> > For the other parts the distinction is probably only needed if you
> >> > wanted to implemented operations like normalize or resolve yourself.
> >> So for the majority of use cases the distinction isn't necessary?
> >
> > Probably, but not having that information available would seem like a
> > very arbitrary limitation.
>
> The info would be available via bool has_*() properties.
>
> >> >> Could the issue by solved by having bool has_*() properties?
> >> >
> >> > It could be, but I am not convinced that it would be a better
> >> > approach.
> >> Why not?
> >> It nicely avoids lots of potential for big trouble.
> >
> > If optional gets standardised and on the other hand the URI library
> > uses a different approach to model optional components because it
> > "nicely avoids lots of potential for big trouble" then I would claim
> > that something is wrong with "optional" (I haven't looked in detail at
> > optional, but I would expect that it does what the name suggests).
>
> I don't agree. Optional is a fine tool, but that tool is not
> appropriate in all cases.
>

Fair enough. So what exactly is inappropriate about this use case?

You need a way to differentiate between two states: something having a
value and something not having a value. There is a difference between
having an *empty* value and not having a value at all.

This is *exactly* the scenario that `optional` is made to cover. If there
is an empty string, you return an active optional that contains an empty
string. If there is no string at all, you return an inactive optional. So
what's wrong with using it here, besides a lack of familiarity with the
idiom?

Your original proposal did not use optional. Why did you move to optional?
> Does it benefit existing users of the class? Does it make their code
> simpler? Or more complex?
>

It makes the standard library as a whole more cohesive, as we now have an
idiomatic way to tell the difference between "empty value" and "no value at
all." `optional` should be used throughout the standard library in such
places.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



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

<br><br>On Wednesday, January 23, 2013 1:39:14 PM UTC-8, Olaf van der Spek =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wed, Jan 23, 2013 at =
10:26 PM, Christof Meerwald &lt;<a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"TjVj7YyX99IJ">cme...@cmeerw.org</a>&gt; wrote:
<br>&gt; On Wed, Jan 23, 2013 at 08:46:25PM +0100, Olaf van der Spek wrote:
<br>&gt;&gt; On Wed, Jan 23, 2013 at 10:47 AM, Christof Meerwald &lt;<a hre=
f=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"TjVj7YyX99IJ">=
cme...@cmeerw.org</a>&gt; wrote:
<br>&gt;&gt; &gt; For the other parts the distinction is probably only need=
ed if you
<br>&gt;&gt; &gt; wanted to implemented operations like normalize or resolv=
e yourself.
<br>&gt;&gt; So for the majority of use cases the distinction isn't necessa=
ry?
<br>&gt;
<br>&gt; Probably, but not having that information available would seem lik=
e a
<br>&gt; very arbitrary limitation.
<br>
<br>The info would be available via bool has_*() properties.
<br>
<br>&gt;&gt; &gt;&gt; Could the issue by solved by having bool has_*() prop=
erties?
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; It could be, but I am not convinced that it would be a be=
tter
<br>&gt;&gt; &gt; approach.
<br>&gt;&gt; Why not?
<br>&gt;&gt; It nicely avoids lots of potential for big trouble.
<br>&gt;
<br>&gt; If optional gets standardised and on the other hand the URI librar=
y
<br>&gt; uses a different approach to model optional components because it
<br>&gt; "nicely avoids lots of potential for big trouble" then I would cla=
im
<br>&gt; that something is wrong with "optional" (I haven't looked in detai=
l at
<br>&gt; optional, but I would expect that it does what the name suggests).
<br>
<br>I don't agree. Optional is a fine tool, but that tool is not
<br>appropriate in all cases.<br></blockquote><div><br>Fair enough. So what=
 exactly is inappropriate about this use case?<br><br>You need a way to dif=
ferentiate between two states: something having a value and something not h=
aving a value. There is a difference between having an <i>empty</i> value a=
nd not having a value at all.<br><br>This is <i>exactly</i> the scenario th=
at `optional` is made to cover. If there is an empty string, you return an =
active optional that contains an empty string. If there is no string at all=
, you return an inactive optional. So what's wrong with using it here, besi=
des a lack of familiarity with the idiom?<br><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;">
Your original proposal did not use optional. Why did you move to optional?
<br>Does it benefit existing users of the class? Does it make their code
<br>simpler? Or more complex?<br></blockquote><div><br>It makes the standar=
d library as a whole more cohesive, as we now have an idiomatic way to tell=
 the difference between "empty value" and "no value at all." `optional` sho=
uld be used throughout the standard library in such places. <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 post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.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_388_17019070.1358986266255--

.

On Wed, Jan 23, 2013 at 11:33 PM, Dean Michael Berris
<dberris@google.com> wrote:
> I'm opposed to adding more members to the URI class unless it's
> absolutely necessary. std::optional<> does this nicely for us
> conveying the correct semantics. It keeps the URI class simple and
> easy to understand and easy to keep a mental model of.

But ...

On Wed, Jan 23, 2013 at 10:39 PM, Olaf van der Spek
<olafvdspek@gmail.com> wrote:
> Does it benefit existing users of the class? Does it make their code
> simpler? Or more complex?


On Thu, Jan 24, 2013 at 1:11 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>> I don't agree. Optional is a fine tool, but that tool is not
>> appropriate in all cases.
>
>
> Fair enough. So what exactly is inappropriate about this use case?

> You need a way to differentiate between two states: something having a value
> and something not having a value. There is a difference between having an
> empty value and not having a value at all.

That's my question: does the majority of client code make that distinction?
And what approach would result in simpler client code, both if the
code makes the distinction and if it doesn't.
AFAIK the original proposal returned a string_ref-like value, so
existing code doesn't have this problem.



--
Olaf

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Thu, Jan 24, 2013 at 7:20 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> On Wed, Jan 23, 2013 at 11:33 PM, Dean Michael Berris
> <dberris@google.com> wrote:
>> I'm opposed to adding more members to the URI class unless it's
>> absolutely necessary. std::optional<> does this nicely for us
>> conveying the correct semantics. It keeps the URI class simple and
>> easy to understand and easy to keep a mental model of.
>
> But ...
>
> On Wed, Jan 23, 2013 at 10:39 PM, Olaf van der Spek
> <olafvdspek@gmail.com> wrote:
>> Does it benefit existing users of the class? Does it make their code
>> simpler? Or more complex?
>
>
> On Thu, Jan 24, 2013 at 1:11 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>>> I don't agree. Optional is a fine tool, but that tool is not
>>> appropriate in all cases.
>>
>>
>> Fair enough. So what exactly is inappropriate about this use case?
>
>> You need a way to differentiate between two states: something having a value
>> and something not having a value. There is a difference between having an
>> empty value and not having a value at all.
>
> That's my question: does the majority of client code make that distinction?

My implementation of an HTTP client already does.

> And what approach would result in simpler client code, both if the
> code makes the distinction and if it doesn't.

Consistency wise this is important.

> AFAIK the original proposal returned a string_ref-like value, so
> existing code doesn't have this problem.
>

Existing code uses boost::optional<>. Look at the released version of
the library in cpp-netlib version 0.9.4.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Thu, Jan 24, 2013 at 9:22 AM, Dean Michael Berris <dberris@google.com> wrote:
>>> You need a way to differentiate between two states: something having a value
>>> and something not having a value. There is a difference between having an
>>> empty value and not having a value at all.
>>
>> That's my question: does the majority of client code make that distinction?
>
> My implementation of an HTTP client already does.

Where do I find your code?

>> And what approach would result in simpler client code, both if the
>> code makes the distinction and if it doesn't.
>
> Consistency wise this is important.

That doesn't answer the question, does it?

>> AFAIK the original proposal returned a string_ref-like value, so
>> existing code doesn't have this problem.
>>
>
> Existing code uses boost::optional<>. Look at the released version of
> the library in cpp-netlib version 0.9.4.

Ah. But your original proposal didn't, right?

--
Olaf

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

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

On 24/01/2013 7:32 PM, "Olaf van der Spek" <olafvdspek@gmail.com> wrote:
>
> On Thu, Jan 24, 2013 at 9:22 AM, Dean Michael Berris <dberris@google.com>
wrote:
> >>> You need a way to differentiate between two states: something having
a value
> >>> and something not having a value. There is a difference between
having an
> >>> empty value and not having a value at all.
> >>
> >> That's my question: does the majority of client code make that
distinction?
> >
> > My implementation of an HTTP client already does.
>
> Where do I find your code?
>

cpp-netlib.org

> >> And what approach would result in simpler client code, both if the
> >> code makes the distinction and if it doesn't.
> >
> > Consistency wise this is important.
>
> That doesn't answer the question, does it?
>

It does. Consistent interfaces makes simpler client code. There's no point
in limiting the design when there's a perfectly acceptable and reasonable
implementation.

Also note that these are URI instances not just specific to HTTP. So you
cannot make the assumption that all other schemes take the same approach as
HTTP in dealing with empty or nonexistent paths.

> >> AFAIK the original proposal returned a string_ref-like value, so
> >> existing code doesn't have this problem.
> >>
> >
> > Existing code uses boost::optional<>. Look at the released version of
> > the library in cpp-netlib version 0.9.4.
>
> Ah. But your original proposal didn't, right?
>

The original returns the range including the delimiters. This was deemed
unnecessary as optional string refs would model the situation better. I
tend to agree.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--14dae9340ae30449b004d404bfce
Content-Type: text/html; charset=ISO-8859-1

<p dir="ltr"><br>
On 24/01/2013 7:32 PM, &quot;Olaf van der Spek&quot; &lt;<a href="mailto:olafvdspek@gmail.com">olafvdspek@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Thu, Jan 24, 2013 at 9:22 AM, Dean Michael Berris &lt;<a href="mailto:dberris@google.com">dberris@google.com</a>&gt; wrote:<br>
&gt; &gt;&gt;&gt; You need a way to differentiate between two states: something having a value<br>
&gt; &gt;&gt;&gt; and something not having a value. There is a difference between having an<br>
&gt; &gt;&gt;&gt; empty value and not having a value at all.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; That&#39;s my question: does the majority of client code make that distinction?<br>
&gt; &gt;<br>
&gt; &gt; My implementation of an HTTP client already does.<br>
&gt;<br>
&gt; Where do I find your code?<br>
&gt;</p>
<p dir="ltr"><a href="http://cpp-netlib.org">cpp-netlib.org</a></p>
<p dir="ltr">&gt; &gt;&gt; And what approach would result in simpler client code, both if the<br>
&gt; &gt;&gt; code makes the distinction and if it doesn&#39;t.<br>
&gt; &gt;<br>
&gt; &gt; Consistency wise this is important.<br>
&gt;<br>
&gt; That doesn&#39;t answer the question, does it?<br>
&gt;</p>
<p dir="ltr">It does. Consistent interfaces makes simpler client code. There&#39;s no point in limiting the design when there&#39;s a perfectly acceptable and reasonable implementation.</p>
<p dir="ltr">Also note that these are URI instances not just specific to HTTP. So you cannot make the assumption that all other schemes take the same approach as HTTP in dealing with empty or nonexistent paths.</p>
<p dir="ltr">&gt; &gt;&gt; AFAIK the original proposal returned a string_ref-like value, so<br>
&gt; &gt;&gt; existing code doesn&#39;t have this problem.<br>
&gt; &gt;&gt;<br>
&gt; &gt;<br>
&gt; &gt; Existing code uses boost::optional&lt;&gt;. Look at the released version of<br>
&gt; &gt; the library in cpp-netlib version 0.9.4.<br>
&gt;<br>
&gt; Ah. But your original proposal didn&#39;t, right?<br>
&gt;</p>
<p dir="ltr">The original returns the range including the delimiters. This was deemed unnecessary as optional string refs would model the situation better. I tend to agree.</p>

<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 post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

--14dae9340ae30449b004d404bfce--

.

On Thu, Jan 24, 2013 at 9:39 AM, Dean Michael Berris <dberris@google.com> wrote:
>> > My implementation of an HTTP client already does.
>>
>> Where do I find your code?
>>
>
> cpp-netlib.org

Found that site, found github, but really can't find your
"implementation of an HTTP client"

>> >> And what approach would result in simpler client code, both if the
>> >> code makes the distinction and if it doesn't.
>> >
>> > Consistency wise this is important.
>>
>> That doesn't answer the question, does it?
>>
>
> It does. Consistent interfaces makes simpler client code. There's no point

Consistency isn't the only thing that counts. Nobody will say that
consistency is bad, but often it's a trade-off.

> in limiting the design when there's a perfectly acceptable and reasonable
> implementation.
>
> Also note that these are URI instances not just specific to HTTP. So you
> cannot make the assumption that all other schemes take the same approach as
> HTTP in dealing with empty or nonexistent paths.

I'm not making that assumption.

>> Ah. But your original proposal didn't, right?
>>
>
> The original returns the range including the delimiters.

Even for host, scheme and path?
Anyway, let's have a look at client code, please.

Olaf

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

------=_Part_1931_30805856.1359019992571
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, January 24, 2013 12:20:34 AM UTC-8, Olaf van der Spek wrote:
>
> On Wed, Jan 23, 2013 at 11:33 PM, Dean Michael Berris
> <dbe...@google.com <javascript:>> wrote:
> > I'm opposed to adding more members to the URI class unless it's
> > absolutely necessary. std::optional<> does this nicely for us
> > conveying the correct semantics. It keeps the URI class simple and
> > easy to understand and easy to keep a mental model of.
>
> But ...
>
> On Wed, Jan 23, 2013 at 10:39 PM, Olaf van der Spek
> <olafv...@gmail.com <javascript:>> wrote:
> > Does it benefit existing users of the class? Does it make their code
> > simpler? Or more complex?
>
>
> On Thu, Jan 24, 2013 at 1:11 AM, Nicol Bolas <jmck...@gmail.com<javascript:>>
> wrote:
> >> I don't agree. Optional is a fine tool, but that tool is not
> >> appropriate in all cases.
> >
> >
> > Fair enough. So what exactly is inappropriate about this use case?
>
> > You need a way to differentiate between two states: something having a
> value
> > and something not having a value. There is a difference between having
> an
> > empty value and not having a value at all.
>
> That's my question: does the majority of client code make that distinction?
>

Does it have to? Does it matter what the majority of client code does?

And more importantly, do we *want* them to?

I admit that I'm not experienced in networking stuff, so I don't know the
general sense of how this is written or how often the data will not be
present. But there is clearly a three-state paradigm at play. And the way
to handle a 3-state return-by-value (present and not empty, present and
empty, not present) like this is with `optional<T>`. This is one of the
prime use-cases of optional<T>, one of the defining reasons why we need the
feature.

optional<T> should be idiomatic C++ for any return-by-value with this
3-state paradigm. How frequently one expects the value to be present or
absent is irrelevant; this is the idiom that should be used. If the user
doesn't want to care whether the value is present or absent, they can use
the features of optional<T> to retrieve a default value. This will be
explicitly spelled out in their code, thus making it easy for the reader to
see what's happening.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



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

<br><br>On Thursday, January 24, 2013 12:20:34 AM UTC-8, Olaf van der Spek =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wed, Jan 23, 2013 at =
11:33 PM, Dean Michael Berris
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
V-ryEGJj8KUJ">dbe...@google.com</a>&gt; wrote:
<br>&gt; I'm opposed to adding more members to the URI class unless it's
<br>&gt; absolutely necessary. std::optional&lt;&gt; does this nicely for u=
s
<br>&gt; conveying the correct semantics. It keeps the URI class simple and
<br>&gt; easy to understand and easy to keep a mental model of.
<br>
<br>But ...
<br>
<br>On Wed, Jan 23, 2013 at 10:39 PM, Olaf van der Spek
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
V-ryEGJj8KUJ">olafv...@gmail.com</a>&gt; wrote:
<br>&gt; Does it benefit existing users of the class? Does it make their co=
de
<br>&gt; simpler? Or more complex?
<br>
<br>
<br>On Thu, Jan 24, 2013 at 1:11 AM, Nicol Bolas &lt;<a href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"V-ryEGJj8KUJ">jmck...@gmail.co=
m</a>&gt; wrote:
<br>&gt;&gt; I don't agree. Optional is a fine tool, but that tool is not
<br>&gt;&gt; appropriate in all cases.
<br>&gt;
<br>&gt;
<br>&gt; Fair enough. So what exactly is inappropriate about this use case?
<br>
<br>&gt; You need a way to differentiate between two states: something havi=
ng a value
<br>&gt; and something not having a value. There is a difference between ha=
ving an
<br>&gt; empty value and not having a value at all.
<br>
<br>That's my question: does the majority of client code make that distinct=
ion?<br></blockquote><div><br>Does it have to? Does it matter what the majo=
rity of client code does?<br><br>And more importantly, do we <i>want</i> th=
em to?<br><br>I admit that I'm not experienced in networking stuff, so I do=
n't know the general sense of how this is written or how often the data wil=
l not be present. But there is clearly a three-state paradigm at play. And =
the way to handle a 3-state return-by-value (present and not empty, present=
 and empty, not present) like this is with `optional&lt;T&gt;`. This is one=
 of the prime use-cases of optional&lt;T&gt;, one of the defining reasons w=
hy we need the feature.<br><br>optional&lt;T&gt; should be idiomatic C++ fo=
r any return-by-value with this 3-state paradigm. How frequently one expect=
s the value to be present or absent is irrelevant; this is the idiom that s=
hould be used. If the user doesn't want to care whether the value is presen=
t or absent, they can use the features of optional&lt;T&gt; to retrieve a d=
efault value. This will be explicitly spelled out in their code, thus makin=
g it easy for the reader to see what's happening.<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 post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.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_1931_30805856.1359019992571--

.

On Thu, Jan 24, 2013 at 10:33 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>> That's my question: does the majority of client code make that
>> distinction?
>
>
> Does it have to? Does it matter what the majority of client code does?

Yes
If say 90% of the cases don't make that distinction then IMO that code
should be as simple as possible. Optimize for the common case.
Hence my suggestion to look at some client code.

> And more importantly, do we want them to?
>
> optional<T> should be idiomatic C++ for any return-by-value with this
> 3-state paradigm. How frequently one expects the value to be present or
> absent is irrelevant; this is the idiom that should be used. If the user
> doesn't want to care whether the value is present or absent, they can use
> the features of optional<T> to retrieve a default value. This will be
> explicitly spelled out in their code, thus making it easy for the reader to
> see what's happening.

That feature of optional is about to be removed from the current
optional proposal.

Shouldn't the primary goal be to have client code as simple as
possible (in most cases)?

--
Olaf

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Thu, Jan 24, 2013 at 8:43 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> On Thu, Jan 24, 2013 at 10:33 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>>> That's my question: does the majority of client code make that
>>> distinction?
>>
>>
>> Does it have to? Does it matter what the majority of client code does?
>
> Yes
> If say 90% of the cases don't make that distinction then IMO that code
> should be as simple as possible. Optimize for the common case.
> Hence my suggestion to look at some client code.
>

You're not making an argument here. You're making rhetorical questions.

Code should be as simple as possible. How could it be more simple than
optional<T>? It's obviously the right idiom and the right type.

>> And more importantly, do we want them to?
>>
>> optional<T> should be idiomatic C++ for any return-by-value with this
>> 3-state paradigm. How frequently one expects the value to be present or
>> absent is irrelevant; this is the idiom that should be used. If the user
>> doesn't want to care whether the value is present or absent, they can use
>> the features of optional<T> to retrieve a default value. This will be
>> explicitly spelled out in their code, thus making it easy for the reader to
>> see what's happening.
>
> That feature of optional is about to be removed from the current
> optional proposal.
>

What feature? That an optional can be checked whether it's set?

optional<string_ref> maybe = uri.path();
string path = maybe? string(*maybe) : string("/");

Why is this not simple?

> Shouldn't the primary goal be to have client code as simple as
> possible (in most cases)?
>

You haven't shown me code that's "much more simple" than code using
optional. Line per line optional<> is simpler than any other
alternative conveying the same concept.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

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

"A path is always defined for a URI, though the defined path may be empty=
=20
(zero length)" [=A73.3, p23].

Therefore, this accessor should not return optional<string_ref>. So we all=
=20
accessors returning optional<string_ref>, but one...

Isn't that a problem in itself?



On Thursday, January 24, 2013 11:01:56 AM UTC+1, Dean Michael Berris wrote:
>
> On Thu, Jan 24, 2013 at 8:43 PM, Olaf van der Spek <olafv...@gmail.com<ja=
vascript:>>=20
> wrote:=20
> > On Thu, Jan 24, 2013 at 10:33 AM, Nicol Bolas <jmck...@gmail.com<javasc=
ript:>>=20
> wrote:=20
> >>> That's my question: does the majority of client code make that=20
> >>> distinction?=20
> >>=20
> >>=20
> >> Does it have to? Does it matter what the majority of client code does?=
=20
> >=20
> > Yes=20
> > If say 90% of the cases don't make that distinction then IMO that code=
=20
> > should be as simple as possible. Optimize for the common case.=20
> > Hence my suggestion to look at some client code.=20
> >=20
>
> You're not making an argument here. You're making rhetorical questions.=
=20
>
> Code should be as simple as possible. How could it be more simple than=20
> optional<T>? It's obviously the right idiom and the right type.=20
>
> >> And more importantly, do we want them to?=20
> >>=20
> >> optional<T> should be idiomatic C++ for any return-by-value with this=
=20
> >> 3-state paradigm. How frequently one expects the value to be present o=
r=20
> >> absent is irrelevant; this is the idiom that should be used. If the=20
> user=20
> >> doesn't want to care whether the value is present or absent, they can=
=20
> use=20
> >> the features of optional<T> to retrieve a default value. This will be=
=20
> >> explicitly spelled out in their code, thus making it easy for the=20
> reader to=20
> >> see what's happening.=20
> >=20
> > That feature of optional is about to be removed from the current=20
> > optional proposal.=20
> >=20
>
> What feature? That an optional can be checked whether it's set?=20
>
> optional<string_ref> maybe =3D uri.path();=20
> string path =3D maybe? string(*maybe) : string("/");=20
>
> Why is this not simple?=20
>
> > Shouldn't the primary goal be to have client code as simple as=20
> > possible (in most cases)?=20
> >=20
>
> You haven't shown me code that's "much more simple" than code using=20
> optional. Line per line optional<> is simpler than any other=20
> alternative conveying the same concept.=20
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



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

"A path is always defined for a URI, though the defined path may be empty (=
zero length)" [=A73.3, p23].<div><br></div><div>Therefore, this accessor sh=
ould not return optional&lt;string_ref&gt;. So we all accessors returning o=
ptional&lt;string_ref&gt;, but one...</div><div><br></div><div>Isn't that a=
 problem in itself?</div><div><br></div><div><br><br>On Thursday, January 2=
4, 2013 11:01:56 AM UTC+1, Dean Michael Berris wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;">On Thu, Jan 24, 2013 at 8:43 PM, Olaf van der Spek &=
lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"OAIBG=
h4AZFcJ">olafv...@gmail.com</a>&gt; wrote:
<br>&gt; On Thu, Jan 24, 2013 at 10:33 AM, Nicol Bolas &lt;<a href=3D"javas=
cript:" target=3D"_blank" gdf-obfuscated-mailto=3D"OAIBGh4AZFcJ">jmck...@gm=
ail.com</a>&gt; wrote:
<br>&gt;&gt;&gt; That's my question: does the majority of client code make =
that
<br>&gt;&gt;&gt; distinction?
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; Does it have to? Does it matter what the majority of client co=
de does?
<br>&gt;
<br>&gt; Yes
<br>&gt; If say 90% of the cases don't make that distinction then IMO that =
code
<br>&gt; should be as simple as possible. Optimize for the common case.
<br>&gt; Hence my suggestion to look at some client code.
<br>&gt;
<br>
<br>You're not making an argument here. You're making rhetorical questions.
<br>
<br>Code should be as simple as possible. How could it be more simple than
<br>optional&lt;T&gt;? It's obviously the right idiom and the right type.
<br>
<br>&gt;&gt; And more importantly, do we want them to?
<br>&gt;&gt;
<br>&gt;&gt; optional&lt;T&gt; should be idiomatic C++ for any return-by-va=
lue with this
<br>&gt;&gt; 3-state paradigm. How frequently one expects the value to be p=
resent or
<br>&gt;&gt; absent is irrelevant; this is the idiom that should be used. I=
f the user
<br>&gt;&gt; doesn't want to care whether the value is present or absent, t=
hey can use
<br>&gt;&gt; the features of optional&lt;T&gt; to retrieve a default value.=
 This will be
<br>&gt;&gt; explicitly spelled out in their code, thus making it easy for =
the reader to
<br>&gt;&gt; see what's happening.
<br>&gt;
<br>&gt; That feature of optional is about to be removed from the current
<br>&gt; optional proposal.
<br>&gt;
<br>
<br>What feature? That an optional can be checked whether it's set?
<br>
<br>optional&lt;string_ref&gt; maybe =3D uri.path();
<br>string path =3D maybe? string(*maybe) : string("/");
<br>
<br>Why is this not simple?
<br>
<br>&gt; Shouldn't the primary goal be to have client code as simple as
<br>&gt; possible (in most cases)?
<br>&gt;
<br>
<br>You haven't shown me code that's "much more simple" than code using
<br>optional. Line per line optional&lt;&gt; is simpler than any other
<br>alternative conveying the same concept.
<br></blockquote></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 post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.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_3_12916261.1359022148706--

.

On Thu, Jan 24, 2013 at 11:01 AM, Dean Michael Berris
<dberris@google.com> wrote:
> On Thu, Jan 24, 2013 at 8:43 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>> On Thu, Jan 24, 2013 at 10:33 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>>>> That's my question: does the majority of client code make that
>>>> distinction?
>>>
>>>
>>> Does it have to? Does it matter what the majority of client code does?
>>
>> Yes
>> If say 90% of the cases don't make that distinction then IMO that code
>> should be as simple as possible. Optimize for the common case.
>> Hence my suggestion to look at some client code.
>>
>
> You're not making an argument here. You're making rhetorical questions.
>
> Code should be as simple as possible. How could it be more simple than
> optional<T>? It's obviously the right idiom and the right type.

optional<T> is just a return type, it's not client code. Speaking of
which, could you link me to some real-world client code, please?

>> That feature of optional is about to be removed from the current
>> optional proposal.
>>
>
> What feature? That an optional can be checked whether it's set?

get_value_or()

> optional<string_ref> maybe = uri.path();
> string path = maybe? string(*maybe) : string("/");
>
> Why is this not simple?

It's a lot less simple than string path = uri.path(); isn't it?
If there's no need to differentiate between null and empty path, then
that's all that's needed.

BTW, string path = uri.path().get_value_or("/"); is simpler than your
code (but about to be removed).

>> Shouldn't the primary goal be to have client code as simple as
>> possible (in most cases)?
>>
>
> You haven't shown me code that's "much more simple" than code using
> optional. Line per line optional<> is simpler than any other
> alternative conveying the same concept.

See above


--
Olaf

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Thu, Jan 24, 2013 at 7:48 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> On Thu, Jan 24, 2013 at 9:39 AM, Dean Michael Berris <dberris@google.com> wrote:
>>> > My implementation of an HTTP client already does.
>>>
>>> Where do I find your code?
>>>
>>
>> cpp-netlib.org
>
> Found that site, found github, but really can't find your
> "implementation of an HTTP client"
>
>>> >> And what approach would result in simpler client code, both if the
>>> >> code makes the distinction and if it doesn't.
>>> >
>>> > Consistency wise this is important.
>>>
>>> That doesn't answer the question, does it?
>>>
>>
>> It does. Consistent interfaces makes simpler client code. There's no point
>
> Consistency isn't the only thing that counts.

Yes it is. We're talking about standard interfaces here.

> Nobody will say that
> consistency is bad, but often it's a trade-off.
>

It's not a tradeoff -- if your design is not consistent, there is no
excuse for it. That is the hallmark of bad design. If you can't make
it consistent, there's a failure somewhere.

So sorry, you cannot trade consistency away. This is the reason why
the standard has been successful in defining algorithms and concepts
and this is why it has lasted this long. The algorithms have a
consistent design -- they work with iterators, they take predicates,
and they take binary or unary functions as parameters.

If you cannot make an API consistent, you have failed.

So consistency is a requirement. Then you have to model the solution
accordingly with the features available in the language.

C++ is type-safe, and so far the type-safe way of conveying
"potentially undefined value" is optional<T>.

>> in limiting the design when there's a perfectly acceptable and reasonable
>> implementation.
>>
>> Also note that these are URI instances not just specific to HTTP. So you
>> cannot make the assumption that all other schemes take the same approach as
>> HTTP in dealing with empty or nonexistent paths.
>
> I'm not making that assumption.
>

So why then would you want to have these "has_" checks when
optional<string_ref> is much more idiomatic and conveys the intent
exactly? I don't know what you're getting at.

>>> Ah. But your original proposal didn't, right?
>>>
>>
>> The original returns the range including the delimiters.
>
> Even for host, scheme and path?

The host part is not optional, because there will always be a host
part in a URI -- it may be empty though (mailto:user). The scheme is
required for URI's the last time I checked. You can't construct a URI
without a scheme, and the ":" delimiter. Paths can be omitted (again,
like mailto:someone@host).

I don't have the RFC memorized but I know Glyn took pains in modeling
the RFC as closely as he can. He's conveyed the intent in the
interface in a consistent manner with the RFC.

> Anyway, let's have a look at client code, please.
>

Look at your own peril:

https://github.com/cpp-netlib/cpp-netlib/blob/0.9-devel/boost/network/protocol/http/algorithms/linearize.hpp#L48

In this iteration the URI always returned a range (or if we had it, a
string_ref). This version has the problem that we don't handle cases
like this properly:

  http://cpp-netlib.org/?

Because the case is that the accessor treats this case as
"http://cpp-netlib.org/" which is obviously wrong. This is an attempt
at cleaning this up:

https://github.com/cpp-netlib/cpp-netlib/blob/master/http/src/network/protocol/http/algorithms/linearize.hpp#L49

But the logic in this algorithm still has the same bug.

We're in the process of re-writing this, and this code will be much
cleaner with optionals now that the interface already provides it in
the URI library's current form.

Thank you for asking BTW.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

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

I think we all agree that knowing whether a component of the uri is defined=
=20
matters.
It matter when the uri should be normalized (true for Scheme-Based=20
Normalization [=A76.2.3], but apparently not for Syntax-Based Normalization=
=20
[=A76.2.2]), when a uri reference should be transformed to a target uri=20
[=A75.2.2], when parsed uri components should be recomposed to a uri [=A75.=
3].

But, when we need to parse the query string or retrieve the fragment,=20
should we (always) process differently not defined and empty ?

Also, unless I am mistaken, the normalization, transformation and=20
recomposition use cases should be encapsulated by the uri type.

If I were to make a function to parse the uri and return a tuple with=20
different components, I'd go with optional<>. But aren't we talking about a=
=20
uri *type*?
The filesytem's path class returns path for the different accessors=20
(parent_path(), filename(), stem(), extension(), ...).
So, may be question is not whether to return string_ref or=20
optional<string_ref>, but uri?

It would then be easy to do
uri source =3D "foo://example.com:8042/over/there?name=3Dferret#nose";
uri q =3D source.query();
uri target =3D uri("http://www.example.com/") + q;
target would be "http://www.example.com/?name=3Dferret");
q would be "?name=3Dferret"=20

Yes, there is the "?", because "name=3Dferret" cannot be parse to a uri,=20
where "?name=3Dferret" can.

With the current proposal, how would I make "q"?
uri q =3D source.query() ? uri("?" + *source.query()) : uri("");


Regards,
Vincent

On Wednesday, January 23, 2013 10:01:48 AM UTC+1, Christof Meerwald wrote:
>
> On Wed, Jan 23, 2013 at 12:33:02AM -0800, Vincent Jacquet wrote:=20
> > I've found a lot of occurences of "empty" in RFC3986 ("the path may be=
=20
> empty=20
> > (no characters)", page 16; "the registered name is empty (zero length)"=
,=20
> > page 21... ) but no occurences of the word "null".=20
> > Could you please tell us which RFC you are referring to and where is th=
e=20
> > distinction between null and empty is made?=20
>
> Sorry, null was the wrong term, RFC 3986 talks about empty and=20
> undefined, for example in 5.3 "Note that we are careful to preserve=20
> the distinction between a component that is undefined, meaning that=20
> its separator was not present in the reference, and a component that=20
> is empty, meaning that the separator was present and was immediately=20
> followed by the next component separator or the end of the reference."=20
>
> It probably needs to be reviewed if the modelling of what can be=20
> undefined matches the RFC (I think a path can be empty, but not=20
> undefined).=20
>
>
> Christof=20
>
> --=20
>
> http://cmeerw.org                              sip:cmeerw at cmeerw.org=
=20
> mailto:cmeerw <javascript:> at cmeerw.org                   xmpp:cmeerw=
=20
> at cmeerw.org=20
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



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

<div>I think we all agree that knowing whether a component of the uri is de=
fined matters.</div><div>It matter when the uri should be normalized (true =
for Scheme-Based Normalization [=A76.2.3], but apparently not for Syntax-Ba=
sed Normalization [=A76.2.2]), when a uri reference should be transformed t=
o a target uri [=A75.2.2], when parsed uri components should be recomposed =
to a uri [=A75.3].</div><div><br></div><div>But, when we need to parse the =
query string or retrieve the fragment, should we (always) process different=
ly not defined and empty ?</div><div><br></div><div>Also, unless I am mista=
ken, the normalization, transformation and recomposition use cases should b=
e encapsulated by the uri type.</div><div><br></div><div>If I were to make =
a function to parse the uri and return a tuple with different components, I=
'd go with optional&lt;&gt;. But aren't we talking about a uri *type*?</div=
><div>The filesytem's path class returns path for the different accessors (=
parent_path(), filename(), stem(), extension(), ...).</div><div>So, may be =
question is not whether to return string_ref or optional&lt;string_ref&gt;,=
 but uri?</div><div><br></div><div>It would then be easy to do</div><div>ur=
i source =3D "foo://example.com:8042/over/there?name=3Dferret#nose";</div><=
div>uri q =3D source.query();</div><div>uri target =3D uri("http://www.exam=
ple.com/") + q;</div><div>target would be "http://www.example.com/?name=3Df=
erret");</div><div>q would be "?name=3Dferret"&nbsp;</div><div><br></div><d=
iv>Yes, there is the "?", because "name=3Dferret" cannot be parse to a uri,=
 where "?name=3Dferret" can.</div><div><br></div><div>With the current prop=
osal, how would I make "q"?</div><div>uri q =3D source.query() ? uri("?" + =
*source.query()) : uri("");</div><div><br></div><div><br></div><div>Regards=
,</div><div>Vincent</div><br>On Wednesday, January 23, 2013 10:01:48 AM UTC=
+1, Christof Meerwald wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On=
 Wed, Jan 23, 2013 at 12:33:02AM -0800, Vincent Jacquet wrote:
<br>&gt; I've found a lot of occurences of "empty" in RFC3986 ("the path ma=
y be empty=20
<br>&gt; (no characters)", page 16; "the registered name is empty (zero len=
gth)",=20
<br>&gt; page 21... ) but no occurences of the word "null".
<br>&gt; Could you please tell us which RFC you are referring to and where =
is the=20
<br>&gt; distinction between null and empty is made?
<br>
<br>Sorry, null was the wrong term, RFC 3986 talks about empty and
<br>undefined, for example in 5.3 "Note that we are careful to preserve
<br>the distinction between a component that is undefined, meaning that
<br>its separator was not present in the reference, and a component that
<br>is empty, meaning that the separator was present and was immediately
<br>followed by the next component separator or the end of the reference."
<br>
<br>It probably needs to be reviewed if the modelling of what can be
<br>undefined matches the RFC (I think a path can be empty, but not
<br>undefined).
<br>
<br>
<br>Christof
<br>
<br>--=20
<br>
<br><a href=3D"http://cmeerw.org" target=3D"_blank">http://cmeerw.org</a> &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp;sip:cmeerw at <a href=3D"http://cmeerw.org" tar=
get=3D"_blank">cmeerw.org</a>
<br>mailto:<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"eSehTVWWylUJ">cmeerw</a> at <a href=3D"http://cmeerw.org" target=3D"_bl=
ank">cmeerw.org</a> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; xmpp:cmeerw at <a href=3D"http://cmeerw.org" target=3D"_blank">cmee=
rw.org</a>
<br></blockquote>

<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 post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.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_564_32294011.1359023526856--

.

On Thu, Jan 24, 2013 at 9:23 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> On Thu, Jan 24, 2013 at 11:01 AM, Dean Michael Berris
> <dberris@google.com> wrote:
>> On Thu, Jan 24, 2013 at 8:43 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>>> On Thu, Jan 24, 2013 at 10:33 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>>>>> That's my question: does the majority of client code make that
>>>>> distinction?
>>>>
>>>>
>>>> Does it have to? Does it matter what the majority of client code does?
>>>
>>> Yes
>>> If say 90% of the cases don't make that distinction then IMO that code
>>> should be as simple as possible. Optimize for the common case.
>>> Hence my suggestion to look at some client code.
>>>
>>
>> You're not making an argument here. You're making rhetorical questions.
>>
>> Code should be as simple as possible. How could it be more simple than
>> optional<T>? It's obviously the right idiom and the right type.
>
> optional<T> is just a return type, it's not client code. Speaking of
> which, could you link me to some real-world client code, please?
>

I just did.

>>> That feature of optional is about to be removed from the current
>>> optional proposal.
>>>
>>
>> What feature? That an optional can be checked whether it's set?
>
> get_value_or()
>

I wouldn't use this -- I've been living with Boost.Optional for a long
time and I've never needed this feature. So yes, it's fine that it
goes away. What's your point?

>> optional<string_ref> maybe = uri.path();
>> string path = maybe? string(*maybe) : string("/");
>>
>> Why is this not simple?
>
> It's a lot less simple than string path = uri.path(); isn't it?

But how do you convey that the URI never had a path defined? An empty
path is different from one that was not provided. Tell me what the
path is in this URI:

  mailto:dberris@google.com

> If there's no need to differentiate between null and empty path, then
> that's all that's needed.
>

But there is a need for that in the concept of a URI. We're being as
faithful to the model as we possibly can be, and there's no point in
excluding a state "just because it's not common".

> BTW, string path = uri.path().get_value_or("/"); is simpler than your
> code (but about to be removed).
>

I disagree. get_value_or should go away.

string_ref path = uri.path() ? *uri.path() : "/";

This is C++, not any other programming language. We have a ternary
operator -- we should use it.

>>> Shouldn't the primary goal be to have client code as simple as
>>> possible (in most cases)?
>>>
>>
>> You haven't shown me code that's "much more simple" than code using
>> optional. Line per line optional<> is simpler than any other
>> alternative conveying the same concept.
>
> See above
>

No, your code is verbose and doesn't convey the meaning properly. You
and I may have different opinions on what's simple -- a ternary
operator is a primitive, it works with pointers, values, and it's been
there since day one. C++ programmers don't need this "get_value_or"
member. It's easy to implement it with a ternary operator.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Thu, Jan 24, 2013 at 11:29 AM, Dean Michael Berris
<dberris@google.com> wrote:
>> Consistency isn't the only thing that counts.
>
> Yes it is. We're talking about standard interfaces here.

So a consistent but unusable interface is good?

> So sorry, you cannot trade consistency away. This is the reason why
> the standard has been successful in defining algorithms and concepts
> and this is why it has lasted this long. The algorithms have a
> consistent design -- they work with iterators, they take predicates,
> and they take binary or unary functions as parameters.

Are you saying C++ doesn't have any inconsistencies?

>> Even for host, scheme and path?
>
> The host part is not optional, because there will always be a host
> part in a URI

What about relative URIs?
If it can't be optional, why is it returned as an optional?

>  -- it may be empty though (mailto:user). The scheme is
> required for URI's the last time I checked.

My browser doesn't require me to enter a scheme. Does that mean it
can't use the URI class directly?

> https://github.com/cpp-netlib/cpp-netlib/blob/0.9-devel/boost/network/protocol/http/algorithms/linearize.hpp#L48

Thanks, but that doesn't look like normal client code. Where's the
HTTP client you spoke of?
To be honest I can't even find the usage of the URI class.

> We're in the process of re-writing this, and this code will be much
> cleaner with optionals now that the interface already provides it in
> the URI library's current form.

It'd be interesting to see the version with optional and compare it.

> Thank you for asking BTW.

You're welcome.


--
Olaf

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Thu, Jan 24, 2013 at 11:36 AM, Dean Michael Berris
<dberris@google.com> wrote:
>>> optional<string_ref> maybe = uri.path();
>>> string path = maybe? string(*maybe) : string("/");
>>>
>>> Why is this not simple?
>>
>> It's a lot less simple than string path = uri.path(); isn't it?
>
> But how do you convey that the URI never had a path defined? An empty
> path is different from one that was not provided.

What's the difference?

> Tell me what the
> path is in this URI:
>
>   mailto:dberris@google.com

Null or empty, I don't know the difference.

>> If there's no need to differentiate between null and empty path, then
>> that's all that's needed.
>>
>
> But there is a need for that in the concept of a URI. We're being as
> faithful to the model as we possibly can be, and there's no point in
> excluding a state "just because it's not common".

You're right, the *concept* should define it. This does not mean it
should use optional.

But not every user has to use it.

>> BTW, string path = uri.path().get_value_or("/"); is simpler than your
>> code (but about to be removed).
>>
>
> I disagree. get_value_or should go away.

> string_ref path = uri.path() ? *uri.path() : "/";
>
> This is C++, not any other programming language. We have a ternary
> operator -- we should use it.

Did you miss the discussion about get_value_or()?
The conditional operator isn't usable with rvalues.

>>>> Shouldn't the primary goal be to have client code as simple as
>>>> possible (in most cases)?
>>>>
>>>
>>> You haven't shown me code that's "much more simple" than code using
>>> optional. Line per line optional<> is simpler than any other
>>> alternative conveying the same concept.
>>
>> See above
>>
>
> No, your code is verbose and doesn't convey the meaning properly. You

It's shorter than yours.

> and I may have different opinions on what's simple -- a ternary
> operator is a primitive, it works with pointers, values, and it's been
> there since day one. C++ programmers don't need this "get_value_or"
> member. It's easy to implement it with a ternary operator.

The conditional operator isn't usable with rvalues.

--
Olaf

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Thu, Jan 24, 2013 at 09:36:10PM +1100, Dean Michael Berris wrote:
> But how do you convey that the URI never had a path defined? An empty
> path is different from one that was not provided. Tell me what the
> path is in this URI:
>
>   mailto:dberris@google.com

The path is "dberris@google.com" - this case is similar to the xmpp
example in your proposal, also see RFC 3986, section 3.3:

  "A path consists of a sequence of path segments separated by a slash
  ("/") character.  A path is always defined for a URI, though the
  defined path may be empty (zero length).  Use of the slash character
  to indicate hierarchy is only required when a URI will be used as
  the context for relative references.  For example, the URI
  <mailto:fred@example.com> has a path of "fred@example.com", whereas
  the URI <foo://info.example.com?fred> has an empty path."


Christof

--

http://cmeerw.org                              sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org                   xmpp:cmeerw at cmeerw.org

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Thu, Jan 24, 2013 at 9:47 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> On Thu, Jan 24, 2013 at 11:29 AM, Dean Michael Berris
> <dberris@google.com> wrote:
>>> Consistency isn't the only thing that counts.
>>
>> Yes it is. We're talking about standard interfaces here.
>
> So a consistent but unusable interface is good?
>

Can you quantify "unusable"? I can quantify consistency in the
deviation from similar components.

Seriously I don't know why I bother answering these kinds of questions.

>> So sorry, you cannot trade consistency away. This is the reason why
>> the standard has been successful in defining algorithms and concepts
>> and this is why it has lasted this long. The algorithms have a
>> consistent design -- they work with iterators, they take predicates,
>> and they take binary or unary functions as parameters.
>
> Are you saying C++ doesn't have any inconsistencies?
>

Did I say that? I think you can read what I wrote.

>>> Even for host, scheme and path?
>>
>> The host part is not optional, because there will always be a host
>> part in a URI
>
> What about relative URIs?
> If it can't be optional, why is it returned as an optional?
>

Sorry, I had my brain around just absolule URI's. You're right,
they're all optional.

>>  -- it may be empty though (mailto:user). The scheme is
>> required for URI's the last time I checked.
>
> My browser doesn't require me to enter a scheme. Does that mean it
> can't use the URI class directly?
>

What does this have to do with anything? Seriously, your browser -- if
it is a web browser we're talking about -- will pick a default scheme
(typically HTTP) to parse the thing you enter. It can use the URI type
directly if it wanted to use the correct

>> https://github.com/cpp-netlib/cpp-netlib/blob/0.9-devel/boost/network/protocol/http/algorithms/linearize.hpp#L48
>
> Thanks, but that doesn't look like normal client code. Where's the
> HTTP client you spoke of?

Really, you want me to spoon-feed you the links?

Done:

http://cpp-netlib.org/latest/reference/http_client.html

This is the facade:

https://github.com/cpp-netlib/cpp-netlib/blob/master/http/src/network/protocol/http/client/facade.hpp

This is the interface for the HTTP request object:

https://github.com/cpp-netlib/cpp-netlib/blob/master/http/src/network/protocol/http/request/request.hpp#L28

And this is the implementation of one of the accessors to a request object:

https://github.com/cpp-netlib/cpp-netlib/blob/master/http/src/network/protocol/http/message/wrappers/anchor.ipp

This is exactly how client code using the URI will look like.

> To be honest I can't even find the usage of the URI class.
>

See above.

>> We're in the process of re-writing this, and this code will be much
>> cleaner with optionals now that the interface already provides it in
>> the URI library's current form.
>
> It'd be interesting to see the version with optional and compare it.
>

See above.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Thu, Jan 24, 2013 at 9:55 PM, Christof Meerwald <cmeerw@cmeerw.org> wrote:
> On Thu, Jan 24, 2013 at 09:36:10PM +1100, Dean Michael Berris wrote:
>> But how do you convey that the URI never had a path defined? An empty
>> path is different from one that was not provided. Tell me what the
>> path is in this URI:
>>
>>   mailto:dberris@google.com
>
> The path is "dberris@google.com" - this case is similar to the xmpp
> example in your proposal, also see RFC 3986, section 3.3:
>
>   "A path consists of a sequence of path segments separated by a slash
>   ("/") character.  A path is always defined for a URI, though the
>   defined path may be empty (zero length).  Use of the slash character
>   to indicate hierarchy is only required when a URI will be used as
>   the context for relative references.  For example, the URI
>   <mailto:fred@example.com> has a path of "fred@example.com", whereas
>   the URI <foo://info.example.com?fred> has an empty path."
>

Gah, you're right. My bad.

I should have said "host" or "anchor".

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Thu, Jan 24, 2013 at 12:00 PM, Dean Michael Berris
<dberris@google.com> wrote:
>>> So sorry, you cannot trade consistency away. This is the reason why
>>> the standard has been successful in defining algorithms and concepts
>>> and this is why it has lasted this long. The algorithms have a
>>> consistent design -- they work with iterators, they take predicates,
>>> and they take binary or unary functions as parameters.
>>
>> Are you saying C++ doesn't have any inconsistencies?
>>
>
> Did I say that? I think you can read what I wrote.

You said consistency is the only thing that counts.
If that's true we'd better make sure C++ doesn't have any inconsistencies.


>> My browser doesn't require me to enter a scheme. Does that mean it
>> can't use the URI class directly?
>>
>
> What does this have to do with anything? Seriously, your browser -- if
> it is a web browser we're talking about -- will pick a default scheme
> (typically HTTP) to parse the thing you enter. It can use the URI type
> directly if it wanted to use the correct

The correct what?
I'm asking because you said scheme is required. Which made me assume
the URI class would not parse the user input (without scheme).

> And this is the implementation of one of the accessors to a request object:
>
> https://github.com/cpp-netlib/cpp-netlib/blob/master/http/src/network/protocol/http/message/wrappers/anchor.ipp
>
> This is exactly how client code using the URI will look like.

  ::network::uri uri_;
  request_.get_uri(uri_);
  auto fragment = uri_.fragment();
  return fragment? std::string(*fragment) : std::string();

Looks like you map null to empty here. If fragment() would've returned
string_ref, the last two lines would be just return uri_.fragment()
The second line appears to prevent you from using a rvalue, otherwise
the entire function could've been just return
request_.get_uri().fragment()



--
Olaf

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Thu, Jan 24, 2013 at 9:54 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> On Thu, Jan 24, 2013 at 11:36 AM, Dean Michael Berris
> <dberris@google.com> wrote:
>>>> optional<string_ref> maybe = uri.path();
>>>> string path = maybe? string(*maybe) : string("/");
>>>>
>>>> Why is this not simple?
>>>
>>> It's a lot less simple than string path = uri.path(); isn't it?
>>
>> But how do you convey that the URI never had a path defined? An empty
>> path is different from one that was not provided.
>
> What's the difference?
>

That's dependent on the scheme. It may be important in some schemes,
it may not be important in others. Still it's a matter of
interpretation so you let the user decide.

>> Tell me what the
>> path is in this URI:
>>
>>   mailto:dberris@google.com
>
> Null or empty, I don't know the difference.
>

I should have picked "anchor".

The difference is "there's no anchor defined" and "there's an anchor
specified to be empty". It depends on the scheme. You should not throw
that information away especially if it may be important.

>>> If there's no need to differentiate between null and empty path, then
>>> that's all that's needed.
>>>
>>
>> But there is a need for that in the concept of a URI. We're being as
>> faithful to the model as we possibly can be, and there's no point in
>> excluding a state "just because it's not common".
>
> You're right, the *concept* should define it. This does not mean it
> should use optional.
>

But why not?

> But not every user has to use it.
>

Has to use what?

>>> BTW, string path = uri.path().get_value_or("/"); is simpler than your
>>> code (but about to be removed).
>>>
>>
>> I disagree. get_value_or should go away.
>
>> string_ref path = uri.path() ? *uri.path() : "/";
>>
>> This is C++, not any other programming language. We have a ternary
>> operator -- we should use it.
>
> Did you miss the discussion about get_value_or()?

I have it muted. I never needed get_value_or before, so I deemed it
not important.

> The conditional operator isn't usable with rvalues.
>

I don't see wording in the standard that says this. I'm looking at
5.16. What are you talking about "conditional operator isn't usable
with rvalues"?

>>>>> Shouldn't the primary goal be to have client code as simple as
>>>>> possible (in most cases)?
>>>>>
>>>>
>>>> You haven't shown me code that's "much more simple" than code using
>>>> optional. Line per line optional<> is simpler than any other
>>>> alternative conveying the same concept.
>>>
>>> See above
>>>
>>
>> No, your code is verbose and doesn't convey the meaning properly. You
>
> It's shorter than yours.
>

It's also totally unnecessary.

>> and I may have different opinions on what's simple -- a ternary
>> operator is a primitive, it works with pointers, values, and it's been
>> there since day one. C++ programmers don't need this "get_value_or"
>> member. It's easy to implement it with a ternary operator.
>
> The conditional operator isn't usable with rvalues.
>

Isn't usable? Please educate me of the wording in the standard that states this.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On 24 January 2013 13:14, Dean Michael Berris <dberris@google.com> wrote:
>> The conditional operator isn't usable with rvalues.
> I don't see wording in the standard that says this. I'm looking at
> 5.16. What are you talking about "conditional operator isn't usable
> with rvalues"?

That's not the point. You can't do

get_temp_value() ? magically_refer_to_that_value.something() : something_else();

You can do that with get_value_or(). That would speak _for_ returning
an optional<string_ref>
from the uri, as far as I can see - I can use get_value_or with it. If
I want to check whether
it is non-null and I have to do that with a conditional operator, I
have to store the return
value, whereas with get_value_or I don't have to do that, I can
compute the things I need
from a temporary.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Thu, Jan 24, 2013 at 10:14 PM, Olaf van der Spek
<olafvdspek@gmail.com> wrote:
> On Thu, Jan 24, 2013 at 12:00 PM, Dean Michael Berris
> <dberris@google.com> wrote:
>>>> So sorry, you cannot trade consistency away. This is the reason why
>>>> the standard has been successful in defining algorithms and concepts
>>>> and this is why it has lasted this long. The algorithms have a
>>>> consistent design -- they work with iterators, they take predicates,
>>>> and they take binary or unary functions as parameters.
>>>
>>> Are you saying C++ doesn't have any inconsistencies?
>>>
>>
>> Did I say that? I think you can read what I wrote.
>
> You said consistency is the only thing that counts.

When designing APIs.

> If that's true we'd better make sure C++ doesn't have any inconsistencies.
>

You're putting words in my mouth. I was talking about designing APIs.

That being said, yes this is why there are committee members that are
dedicated in making this a reality. We're human and fallible too. If
you want to help, that would be very much appreciated.

>
>>> My browser doesn't require me to enter a scheme. Does that mean it
>>> can't use the URI class directly?
>>>
>>
>> What does this have to do with anything? Seriously, your browser -- if
>> it is a web browser we're talking about -- will pick a default scheme
>> (typically HTTP) to parse the thing you enter. It can use the URI type
>> directly if it wanted to use the correct
>
> The correct what?
> I'm asking because you said scheme is required. Which made me assume
> the URI class would not parse the user input (without scheme).
>

In my haste, I left that hanging.

It can use the URI type directly if it wanted to use the correct
enforcement of the RFC -- or more to the point, if it wanted to use it
as part of its internal APIs.

I realize the proposal actually supports relative URI's (I must admit
I let Glyn define that part) and that this is even now useful in the
context of an HTTP server. Of course it has to make assumptions on the
scheme and in that context it's definitely possible.

>> And this is the implementation of one of the accessors to a request object:
>>
>> https://github.com/cpp-netlib/cpp-netlib/blob/master/http/src/network/protocol/http/message/wrappers/anchor.ipp
>>
>> This is exactly how client code using the URI will look like.
>
>   ::network::uri uri_;
>   request_.get_uri(uri_);
>   auto fragment = uri_.fragment();
>   return fragment? std::string(*fragment) : std::string();
>
> Looks like you map null to empty here.

This is a short-coming. As I said this is in the process of being re-written.

> If fragment() would've returned
> string_ref, the last two lines would be just return uri_.fragment()

Yes. The string_ref implementation in cpp-netlib has only been
recently added. I have yet to use it throughout (or actually, just use
Boost.string_ref when that's released). That's off-topic though.

> The second line appears to prevent you from using a rvalue, otherwise
> the entire function could've been just return
> request_.get_uri().fragment()
>

No, this is just a matter of style. Clang compiles this just fine and
I can't see why it's a problem from reading the standard:

struct convertible {
  operator bool () {
    return true;
  }
};

convertible f() {
  return {};
}

int main() {
  int x = f() ? 0 : 1;
}

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Thu, Jan 24, 2013 at 10:22 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 24 January 2013 13:14, Dean Michael Berris <dberris@google.com> wrote:
>>> The conditional operator isn't usable with rvalues.
>> I don't see wording in the standard that says this. I'm looking at
>> 5.16. What are you talking about "conditional operator isn't usable
>> with rvalues"?
>
> That's not the point. You can't do
>
> get_temp_value() ? magically_refer_to_that_value.something() : something_else();
>
> You can do that with get_value_or(). That would speak _for_ returning
> an optional<string_ref>
> from the uri, as far as I can see - I can use get_value_or with it. If
> I want to check whether
> it is non-null and I have to do that with a conditional operator, I
> have to store the return
> value, whereas with get_value_or I don't have to do that, I can
> compute the things I need
> from a temporary.
>

Hmmm... so what's the difference between that and:

auto value = get_temp_value();
value ? value.something() : something_else();

Or for that matter:

if (auto value = get_temp_value()) {
  // more statements
} else {
  // more statements
}

All I'm saying here is that whether there's a get_value_or() on
optional is irrelevant to whether the URI should return an optional.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On 24 January 2013 13:30, Dean Michael Berris <dberris@google.com> wrote:
>> That's not the point. You can't do
>> get_temp_value() ? magically_refer_to_that_value.something() : something_else();
> Hmmm... so what's the difference between that and:
> auto value = get_temp_value();
> value ? value.something() : something_else();

Seriously? The difference is glaringly visible, you need two
statements and a temporary
variable there, as opposed to having an expression there. :)

> All I'm saying here is that whether there's a get_value_or() on
> optional is irrelevant to whether the URI should return an optional.

I'm saying being able to use get_value_or with the return type of URI
is a big plus. You can't achieve that with has_* functions and such.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Thu, Jan 24, 2013 at 12:26 PM, Dean Michael Berris
<dberris@google.com> wrote:
>>> And this is the implementation of one of the accessors to a request object:
>>>
>>> https://github.com/cpp-netlib/cpp-netlib/blob/master/http/src/network/protocol/http/message/wrappers/anchor.ipp
>>>
>>> This is exactly how client code using the URI will look like.
>>
>>   ::network::uri uri_;
>>   request_.get_uri(uri_);
>>   auto fragment = uri_.fragment();
>>   return fragment? std::string(*fragment) : std::string();
>>
>> Looks like you map null to empty here.
>
> This is a short-coming. As I said this is in the process of being re-written.

Let's wait for the re-written code then.

>> If fragment() would've returned
>> string_ref, the last two lines would be just return uri_.fragment()
>
> Yes. The string_ref implementation in cpp-netlib has only been
> recently added. I have yet to use it throughout (or actually, just use
> Boost.string_ref when that's released). That's off-topic though.

Is it? The point is that return uri_.fragment() is only possible if
fragment() doesn't return an optional.

>> The second line appears to prevent you from using a rvalue, otherwise
>> the entire function could've been just return
>> request_.get_uri().fragment()
>>
>
> No, this is just a matter of style. Clang compiles this just fine and
> I can't see why it's a problem from reading the standard:

Of course it compiles just fine, that's not the point. The point is simplicity.

BTW, what coding style is that? Are you using trailing underscores for
both local- and member vars?


--
Olaf

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Thu, Jan 24, 2013 at 10:34 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 24 January 2013 13:30, Dean Michael Berris <dberris@google.com> wrote:
>>> That's not the point. You can't do
>>> get_temp_value() ? magically_refer_to_that_value.something() : something_else();
>> Hmmm... so what's the difference between that and:
>> auto value = get_temp_value();
>> value ? value.something() : something_else();
>
> Seriously? The difference is glaringly visible, you need two
> statements and a temporary
> variable there, as opposed to having an expression there. :)
>

I know what the actual difference is, I'm asking what the conceptual
difference is.

Would something like "optional.get(default_value)" (like how Python
dict's work) make better sense? I don't know.

Maybe I'm just blinded by familiarity with Boost.Optional and the
preference for clear constructs.

I'm just saying I won't miss it because I've never had it. ;)

>> All I'm saying here is that whether there's a get_value_or() on
>> optional is irrelevant to whether the URI should return an optional.
>
> I'm saying being able to use get_value_or with the return type of URI
> is a big plus. You can't achieve that with has_* functions and such.
>

We're in violent agreement then. :)

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Thu, Jan 24, 2013 at 10:36 PM, Olaf van der Spek
<olafvdspek@gmail.com> wrote:
> On Thu, Jan 24, 2013 at 12:26 PM, Dean Michael Berris
> <dberris@google.com> wrote:
>>>> And this is the implementation of one of the accessors to a request object:
>>>>
>>>> https://github.com/cpp-netlib/cpp-netlib/blob/master/http/src/network/protocol/http/message/wrappers/anchor.ipp
>>>>
>>>> This is exactly how client code using the URI will look like.
>>>
>>>   ::network::uri uri_;
>>>   request_.get_uri(uri_);
>>>   auto fragment = uri_.fragment();
>>>   return fragment? std::string(*fragment) : std::string();
>>>
>>> Looks like you map null to empty here.
>>
>> This is a short-coming. As I said this is in the process of being re-written.
>
> Let's wait for the re-written code then.
>

Let's.

>>> If fragment() would've returned
>>> string_ref, the last two lines would be just return uri_.fragment()
>>
>> Yes. The string_ref implementation in cpp-netlib has only been
>> recently added. I have yet to use it throughout (or actually, just use
>> Boost.string_ref when that's released). That's off-topic though.
>
> Is it? The point is that return uri_.fragment() is only possible if
> fragment() doesn't return an optional.
>

Uh, if I was going to return an optional I'll just return an optional.
That's what's going to happen anyway. This is a short-coming of the
current implementation. This was written when there was no string_ref
and it didn't occur to me at the time that returning an optional would
have been a better implementation.

I certainly have learned quite a bit between then and now. ;)

>>> The second line appears to prevent you from using a rvalue, otherwise
>>> the entire function could've been just return
>>> request_.get_uri().fragment()
>>>
>>
>> No, this is just a matter of style. Clang compiles this just fine and
>> I can't see why it's a problem from reading the standard:
>
> Of course it compiles just fine, that's not the point. The point is simplicity.
>

It's simple to me. I don't get it.

> BTW, what coding style is that? Are you using trailing underscores for
> both local- and member vars?
>

This is off-topic.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On 24 January 2013 13:39, Dean Michael Berris <dberris@google.com> wrote:
> Maybe I'm just blinded by familiarity with Boost.Optional and the
> preference for clear constructs.
> I'm just saying I won't miss it because I've never had it. ;)

Indeed. I will miss it because I have written enough value extractor
helper functions.
Widening horizons further beyond boost, I also have QSettings::value
that can take
a default value, and QVariant::value which can default-construct a
value. Such things
have been found rather useful, and conditional operator doesn't quite cut it.

>> I'm saying being able to use get_value_or with the return type of URI
>> is a big plus. You can't achieve that with has_* functions and such.
> We're in violent agreement then. :)

Yep! :)

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

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

On Thu, Jan 24, 2013 at 11:32 AM, Vincent Jacquet <vjacquet@flowgroup.fr>wrote:

> Also, unless I am mistaken, the normalization, transformation and
> recomposition use cases should be encapsulated by the uri type.
>
> If I were to make a function to parse the uri and return a tuple with
> different components, I'd go with optional<>. But aren't we talking about a
> uri *type*?
> The filesytem's path class returns path for the different accessors
> (parent_path(), filename(), stem(), extension(), ...).
> So, may be question is not whether to return string_ref or
> optional<string_ref>, but uri?
>
> It would then be easy to do
> uri source = "foo://example.com:8042/over/there?name=ferret#nose";
> uri q = source.query();
> uri target = uri("http://www.example.com/") + q;
> target would be "http://www.example.com/?name=ferret");
> q would be "?name=ferret"
>
> Yes, there is the "?", because "name=ferret" cannot be parse to a uri,
> where "?name=ferret" can.
>
> With the current proposal, how would I make "q"?
> uri q = source.query() ? uri("?" + *source.query()) : uri("");
>

This is interesting.
Dean and Glynn, did you consider returning uri?

Joel Lamotte

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Thu, Jan 24, 2013 at 11:32 AM, Vincent Jacquet <span dir=3D"ltr">&lt;<a =
href=3D"mailto:vjacquet@flowgroup.fr" target=3D"_blank">vjacquet@flowgroup.=
fr</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>Also, unless I am mistaken, the normali=
zation, transformation and recomposition use cases should be encapsulated b=
y the uri type.</div>
<div><br></div><div>If I were to make a function to parse the uri and retur=
n a tuple with different components, I&#39;d go with optional&lt;&gt;. But =
aren&#39;t we talking about a uri *type*?</div><div>The filesytem&#39;s pat=
h class returns path for the different accessors (parent_path(), filename()=
, stem(), extension(), ...).</div>
<div>So, may be question is not whether to return string_ref or optional&lt=
;string_ref&gt;, but uri?</div><div><br></div><div>It would then be easy to=
 do</div><div>uri source =3D &quot;foo://<a href=3D"http://example.com:8042=
/over/there?name=3Dferret#nose" target=3D"_blank">example.com:8042/over/the=
re?name=3Dferret#nose</a>&quot;;</div>
<div>uri q =3D source.query();</div><div>uri target =3D uri(&quot;<a href=
=3D"http://www.example.com/" target=3D"_blank">http://www.example.com/</a>&=
quot;) + q;</div><div>target would be &quot;<a href=3D"http://www.example.c=
om/?name=3Dferret" target=3D"_blank">http://www.example.com/?name=3Dferret<=
/a>&quot;);</div>
<div>q would be &quot;?name=3Dferret&quot;=A0</div><div><br></div><div>Yes,=
 there is the &quot;?&quot;, because &quot;name=3Dferret&quot; cannot be pa=
rse to a uri, where &quot;?name=3Dferret&quot; can.</div><div><br></div><di=
v>With the current proposal, how would I make &quot;q&quot;?</div>
<div>uri q =3D source.query() ? uri(&quot;?&quot; + *source.query()) : uri(=
&quot;&quot;);</div><div></div></blockquote></div><br>This is interesting.<=
/div><div class=3D"gmail_extra" style>Dean and Glynn, did you consider retu=
rning uri?</div>
<div class=3D"gmail_extra" style><br></div><div class=3D"gmail_extra" style=
>Joel Lamotte</div><div class=3D"gmail_extra" style><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 post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.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 />

--bcaec54c53d4d386ad04d407ecf7--

.

On Thu, Jan 24, 2013 at 11:26 PM, Klaim - Jo=EBl Lamotte
<mjklaim@gmail.com> wrote:
>
> On Thu, Jan 24, 2013 at 11:32 AM, Vincent Jacquet <vjacquet@flowgroup.fr>
> wrote:
>>
>> Also, unless I am mistaken, the normalization, transformation and
>> recomposition use cases should be encapsulated by the uri type.
>>
>> If I were to make a function to parse the uri and return a tuple with
>> different components, I'd go with optional<>. But aren't we talking abou=
t a
>> uri *type*?
>> The filesytem's path class returns path for the different accessors
>> (parent_path(), filename(), stem(), extension(), ...).
>> So, may be question is not whether to return string_ref or
>> optional<string_ref>, but uri?
>>
>> It would then be easy to do
>> uri source =3D "foo://example.com:8042/over/there?name=3Dferret#nose";
>> uri q =3D source.query();
>> uri target =3D uri("http://www.example.com/") + q;
>> target would be "http://www.example.com/?name=3Dferret");
>> q would be "?name=3Dferret"
>>
>> Yes, there is the "?", because "name=3Dferret" cannot be parse to a uri,
>> where "?name=3Dferret" can.
>>
>> With the current proposal, how would I make "q"?
>> uri q =3D source.query() ? uri("?" + *source.query()) : uri("");
>
>
> This is interesting.
> Dean and Glynn, did you consider returning uri?
>

No. Just off the top of my head, I think this is wasteful.

Nothing's wrong with returning an optional<string_ref>. If there's
something wrong with optional, then it should be fixed but the concept
stays the same and is consistent as far as I understand.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



.

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

Speaking of *uri*, I sincerly think there is something wrong with accessor=
=20
returning an optional<string_ref>: the string_ref part!

I want to manipulate uri, not its components, because the manipulation of=
=20
the components of a uri is scheme dependent, and I do not want to write=20
scheme dependent code all over the place.

It may be a little extreme but please consider:
"W3C recommends that all web servers support semicolon separators in=20
addition to ampersand separators[6] to allow=20
application/x-www-form-urlencoded query strings in URLs within HTML=20
documents without having to entity escape ampersands." (see=20
<http://en.wikipedia.org/wiki/Query_string>).
I didn't knew that until 5 minutes ago. If I had started to parse the query=
=20
string into a multi_map, my parsing would have been incomplete.

IMVHO the design of the uri type should not encourage to access the=20
components as a string (or string_ref or optional<string_ref>), because it=
=20
is way too tempting to "handle it myself". Ideally, it should give me a=20
scheme object that would interpret its parts.


Regards,
Vincent

On Thursday, January 24, 2013 1:42:06 PM UTC+1, Dean Michael Berris wrote:
>
> On Thu, Jan 24, 2013 at 11:26 PM, Klaim - Jo=EBl Lamotte=20
> <mjk...@gmail.com <javascript:>> wrote:=20
> >=20
> > On Thu, Jan 24, 2013 at 11:32 AM, Vincent Jacquet <vjac...@flowgroup.fr=
<javascript:>>=20
>
> > wrote:=20
> >>=20
> >> Also, unless I am mistaken, the normalization, transformation and=20
> >> recomposition use cases should be encapsulated by the uri type.=20
> >>=20
> >> If I were to make a function to parse the uri and return a tuple with=
=20
> >> different components, I'd go with optional<>. But aren't we talking=20
> about a=20
> >> uri *type*?=20
> >> The filesytem's path class returns path for the different accessors=20
> >> (parent_path(), filename(), stem(), extension(), ...).=20
> >> So, may be question is not whether to return string_ref or=20
> >> optional<string_ref>, but uri?=20
> >>=20
> >> It would then be easy to do=20
> >> uri source =3D "foo://example.com:8042/over/there?name=3Dferret#nose";=
=20
> >> uri q =3D source.query();=20
> >> uri target =3D uri("http://www.example.com/") + q;=20
> >> target would be "http://www.example.com/?name=3Dferret");=20
> >> q would be "?name=3Dferret"=20
> >>=20
> >> Yes, there is the "?", because "name=3Dferret" cannot be parse to a ur=
i,=20
> >> where "?name=3Dferret" can.=20
> >>=20
> >> With the current proposal, how would I make "q"?=20
> >> uri q =3D source.query() ? uri("?" + *source.query()) : uri("");=20
> >=20
> >=20
> > This is interesting.=20
> > Dean and Glynn, did you consider returning uri?=20
> >=20
>
> No. Just off the top of my head, I think this is wasteful.=20
>
> Nothing's wrong with returning an optional<string_ref>. If there's=20
> something wrong with optional, then it should be fixed but the concept=20
> stays the same and is consistent as far as I understand.=20
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



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

<div>Speaking of *uri*, I sincerly think there is something wrong with acce=
ssor returning an optional&lt;string_ref&gt;: the string_ref part!</div><di=
v><br></div><div>I want to manipulate uri, not its components, because the =
manipulation of the components of a uri is scheme dependent, and I do not w=
ant to write scheme dependent code all over the place.</div><div><br></div>=
It may be a little extreme but please consider:<div><span style=3D"line-hei=
ght: 19.1875px; color: rgb(0, 0, 0); font-family: sans-serif;">"W3C recomme=
nds that all web servers support semicolon separators in addition to ampers=
and separators[6] to allow application/x-www-form-urlencoded query strings =
in URLs within HTML documents without having to entity escape ampersands." =
(see &lt;http://en.wikipedia.org/wiki/Query_string&gt;).</span><br></div><d=
iv><span style=3D"line-height: 19.1875px; color: rgb(0, 0, 0); font-family:=
 sans-serif;">I didn't knew that until 5 minutes ago. If I had started to p=
arse the query string into a multi_map, my parsing would have been incomple=
te.</span><br></div><div><span style=3D"line-height: 19.1875px; color: rgb(=
0, 0, 0); font-family: sans-serif;"><br></span></div><div><span style=3D"li=
ne-height: 19.1875px; color: rgb(0, 0, 0); font-family: sans-serif;">IMVHO =
the design of the uri type should not encourage to access the components as=
 a string (or&nbsp;</span><span style=3D"color: rgb(0, 0, 0); font-family: =
sans-serif; line-height: 19.1875px;">string_ref or optional&lt;string_ref&g=
t;), because it is way too tempting to "handle it myself"</span><span style=
=3D"line-height: 19.1875px; color: rgb(0, 0, 0); font-family: sans-serif;">=
.. Ideally, it&nbsp;</span><span style=3D"line-height: 19.1875px; color: rgb=
(0, 0, 0); font-family: sans-serif;">should give me a scheme object that wo=
uld interpret its parts.</span></div><div><span style=3D"line-height: 19.18=
75px; color: rgb(0, 0, 0); font-family: sans-serif;"><br></span></div><div>=
<br></div><div><span style=3D"line-height: 19.1875px; color: rgb(0, 0, 0); =
font-family: sans-serif;">Regards,</span></div><div><span style=3D"line-hei=
ght: 19.1875px; color: rgb(0, 0, 0); font-family: sans-serif;">Vincent</spa=
n></div><div><br>On Thursday, January 24, 2013 1:42:06 PM UTC+1, Dean Micha=
el Berris wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thu, Jan 24=
, 2013 at 11:26 PM, Klaim - Jo=EBl Lamotte
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
r6i_kNYjT-EJ">mjk...@gmail.com</a>&gt; wrote:
<br>&gt;
<br>&gt; On Thu, Jan 24, 2013 at 11:32 AM, Vincent Jacquet &lt;<a href=3D"j=
avascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"r6i_kNYjT-EJ">vjac..=
..@flowgroup.fr</a>&gt;
<br>&gt; wrote:
<br>&gt;&gt;
<br>&gt;&gt; Also, unless I am mistaken, the normalization, transformation =
and
<br>&gt;&gt; recomposition use cases should be encapsulated by the uri type=
..
<br>&gt;&gt;
<br>&gt;&gt; If I were to make a function to parse the uri and return a tup=
le with
<br>&gt;&gt; different components, I'd go with optional&lt;&gt;. But aren't=
 we talking about a
<br>&gt;&gt; uri *type*?
<br>&gt;&gt; The filesytem's path class returns path for the different acce=
ssors
<br>&gt;&gt; (parent_path(), filename(), stem(), extension(), ...).
<br>&gt;&gt; So, may be question is not whether to return string_ref or
<br>&gt;&gt; optional&lt;string_ref&gt;, but uri?
<br>&gt;&gt;
<br>&gt;&gt; It would then be easy to do
<br>&gt;&gt; uri source =3D "foo://<a href=3D"http://example.com:8042/over/=
there?name=3Dferret#nose" target=3D"_blank">example.com:8042/over/<wbr>ther=
e?name=3Dferret#nose</a>";
<br>&gt;&gt; uri q =3D source.query();
<br>&gt;&gt; uri target =3D uri("<a href=3D"http://www.example.com/" target=
=3D"_blank">http://www.example.com/</a>") + q;
<br>&gt;&gt; target would be "<a href=3D"http://www.example.com/?name=3Dfer=
ret" target=3D"_blank">http://www.example.com/?name=3D<wbr>ferret</a>");
<br>&gt;&gt; q would be "?name=3Dferret"
<br>&gt;&gt;
<br>&gt;&gt; Yes, there is the "?", because "name=3Dferret" cannot be parse=
 to a uri,
<br>&gt;&gt; where "?name=3Dferret" can.
<br>&gt;&gt;
<br>&gt;&gt; With the current proposal, how would I make "q"?
<br>&gt;&gt; uri q =3D source.query() ? uri("?" + *source.query()) : uri(""=
);
<br>&gt;
<br>&gt;
<br>&gt; This is interesting.
<br>&gt; Dean and Glynn, did you consider returning uri?
<br>&gt;
<br>
<br>No. Just off the top of my head, I think this is wasteful.
<br>
<br>Nothing's wrong with returning an optional&lt;string_ref&gt;. If there'=
s
<br>something wrong with optional, then it should be fixed but the concept
<br>stays the same and is consistent as far as I understand.
<br></blockquote></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 post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.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_48_13794005.1359038971150--

.

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

On 24 January 2013 11:32, Vincent Jacquet <vjacquet@flowgroup.fr> wrote:

> I think we all agree that knowing whether a component of the uri is
> defined matters.
> It matter when the uri should be normalized (true for Scheme-Based
> Normalization [=A76.2.3], but apparently not for Syntax-Based Normalizati=
on
> [=A76.2.2]), when a uri reference should be transformed to a target uri
> [=A75.2.2], when parsed uri components should be recomposed to a uri [=A7=
5.3].
>
> But, when we need to parse the query string or retrieve the fragment,
> should we (always) process differently not defined and empty ?
>
> Also, unless I am mistaken, the normalization, transformation and
> recomposition use cases should be encapsulated by the uri type.
>
> If I were to make a function to parse the uri and return a tuple with
> different components, I'd go with optional<>. But aren't we talking about=
 a
> uri *type*?
> The filesytem's path class returns path for the different accessors
> (parent_path(), filename(), stem(), extension(), ...).
> So, may be question is not whether to return string_ref or
> optional<string_ref>, but uri?
>
> It would then be easy to do
> uri source =3D "foo://example.com:8042/over/there?name=3Dferret#nose";
> uri q =3D source.query();
> uri target =3D uri("http://www.example.com/") + q;
> target would be "http://www.example.com/?name=3Dferret");
> q would be "?name=3Dferret"
>
> Yes, there is the "?", because "name=3Dferret" cannot be parse to a uri,
> where "?name=3Dferret" can.
>
> With the current proposal, how would I make "q"?
> uri q =3D source.query() ? uri("?" + *source.query()) : uri("");
>
>
>
I acknowledge that this isn't clear in the current proposal and I thank you
for your question, but what you ask above should be able to be done by
using the uri_builder:

std::network::uri_builder builder;
builder.query("name=3Dferret"); // the builder query method should be able =
to
add the prefix ? automatically if it is missing
std::network::uri q =3D builder.uri();

And to make "target":

std::network::uri base("http://www.example.com/");
std::network::uri target =3D base.resolve(q);

Regards,
Glyn

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



--047d7bfcf91a17018704d40adde4
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 January 2013 11:32, Vincent Jacquet <span dir=3D"ltr">&lt;<a =
href=3D"mailto:vjacquet@flowgroup.fr" target=3D"_blank">vjacquet@flowgroup.=
fr</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>I think we all agree that knowing wheth=
er a component of the uri is defined matters.</div><div>It matter when the =
uri should be normalized (true for Scheme-Based Normalization [=A76.2.3], b=
ut apparently not for Syntax-Based Normalization [=A76.2.2]), when a uri re=
ference should be transformed to a target uri [=A75.2.2], when parsed uri c=
omponents should be recomposed to a uri [=A75.3].</div>

<div><br></div><div>But, when we need to parse the query string or retrieve=
 the fragment, should we (always) process differently not defined and empty=
 ?</div><div><br></div><div>Also, unless I am mistaken, the normalization, =
transformation and recomposition use cases should be encapsulated by the ur=
i type.</div>

<div><br></div><div>If I were to make a function to parse the uri and retur=
n a tuple with different components, I&#39;d go with optional&lt;&gt;. But =
aren&#39;t we talking about a uri *type*?</div><div>The filesytem&#39;s pat=
h class returns path for the different accessors (parent_path(), filename()=
, stem(), extension(), ...).</div>

<div>So, may be question is not whether to return string_ref or optional&lt=
;string_ref&gt;, but uri?</div><div><br></div><div>It would then be easy to=
 do</div><div>uri source =3D &quot;foo://<a href=3D"http://example.com:8042=
/over/there?name=3Dferret#nose" target=3D"_blank">example.com:8042/over/the=
re?name=3Dferret#nose</a>&quot;;</div>

<div>uri q =3D source.query();</div><div>uri target =3D uri(&quot;<a href=
=3D"http://www.example.com/" target=3D"_blank">http://www.example.com/</a>&=
quot;) + q;</div><div>target would be &quot;<a href=3D"http://www.example.c=
om/?name=3Dferret" target=3D"_blank">http://www.example.com/?name=3Dferret<=
/a>&quot;);</div>

<div>q would be &quot;?name=3Dferret&quot;=A0</div><div><br></div><div>Yes,=
 there is the &quot;?&quot;, because &quot;name=3Dferret&quot; cannot be pa=
rse to a uri, where &quot;?name=3Dferret&quot; can.</div><div><br></div><di=
v>With the current proposal, how would I make &quot;q&quot;?</div>

<div>uri q =3D source.query() ? uri(&quot;?&quot; + *source.query()) : uri(=
&quot;&quot;);</div><div><br></div><div><br></div></blockquote><div><br></d=
iv><div style>I acknowledge that this isn&#39;t clear in the current propos=
al and I thank you for your question, but what you ask above should be able=
 to be done by using the uri_builder:</div>
<div><br></div><div style>std::network::uri_builder builder;</div><div styl=
e>builder.query(&quot;name=3Dferret&quot;); // the builder query method sho=
uld be able to add the prefix ? automatically if it is missing</div><div st=
yle>
std::network::uri q =3D builder.uri();</div><div><br></div><div style>And t=
o make &quot;target&quot;:</div><div style><br></div><div style>std::networ=
k::uri base(&quot;<a href=3D"http://www.example.com/">http://www.example.co=
m/</a>&quot;);</div>
<div style>std::network::uri target =3D base.resolve(q);</div><div><br></di=
v><div style>Regards,</div><div style>Glyn=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 post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.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 />

--047d7bfcf91a17018704d40adde4--

.

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

On 24 January 2013 13:26, Klaim - Jo=EBl Lamotte <mjklaim@gmail.com> wrote:

>
> On Thu, Jan 24, 2013 at 11:32 AM, Vincent Jacquet <vjacquet@flowgroup.fr>=
wrote:
>
>> Also, unless I am mistaken, the normalization, transformation and
>> recomposition use cases should be encapsulated by the uri type.
>>
>> If I were to make a function to parse the uri and return a tuple with
>> different components, I'd go with optional<>. But aren't we talking abou=
t a
>> uri *type*?
>> The filesytem's path class returns path for the different accessors
>> (parent_path(), filename(), stem(), extension(), ...).
>> So, may be question is not whether to return string_ref or
>> optional<string_ref>, but uri?
>>
>> It would then be easy to do
>> uri source =3D "foo://example.com:8042/over/there?name=3Dferret#nose";
>> uri q =3D source.query();
>> uri target =3D uri("http://www.example.com/") + q;
>> target would be "http://www.example.com/?name=3Dferret");
>> q would be "?name=3Dferret"
>>
>> Yes, there is the "?", because "name=3Dferret" cannot be parse to a uri,
>> where "?name=3Dferret" can.
>>
>> With the current proposal, how would I make "q"?
>> uri q =3D source.query() ? uri("?" + *source.query()) : uri("");
>>
>
> This is interesting.
> Dean and Glynn, did you consider returning uri?
>
>
No, I always wanted to return a reference to the underlying string.
Returning a uri object means an additional string copy.

Regards,
Glyn

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



--f46d04430606d04bcd04d40add43
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 January 2013 13:26, Klaim - Jo=EBl Lamotte <span dir=3D"ltr">=
&lt;<a href=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjklaim@gmail.co=
m</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"><div class=3D"gmail_extra">=
<div><br><div class=3D"gmail_quote">On Thu, Jan 24, 2013 at 11:32 AM, Vince=
nt Jacquet <span dir=3D"ltr">&lt;<a href=3D"mailto:vjacquet@flowgroup.fr" t=
arget=3D"_blank">vjacquet@flowgroup.fr</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>Also, unless I am mistaken, the normali=
zation, transformation and recomposition use cases should be encapsulated b=
y the uri type.</div>


<div><br></div><div>If I were to make a function to parse the uri and retur=
n a tuple with different components, I&#39;d go with optional&lt;&gt;. But =
aren&#39;t we talking about a uri *type*?</div><div>The filesytem&#39;s pat=
h class returns path for the different accessors (parent_path(), filename()=
, stem(), extension(), ...).</div>


<div>So, may be question is not whether to return string_ref or optional&lt=
;string_ref&gt;, but uri?</div><div><br></div><div>It would then be easy to=
 do</div><div>uri source =3D &quot;foo://<a href=3D"http://example.com:8042=
/over/there?name=3Dferret#nose" target=3D"_blank">example.com:8042/over/the=
re?name=3Dferret#nose</a>&quot;;</div>


<div>uri q =3D source.query();</div><div>uri target =3D uri(&quot;<a href=
=3D"http://www.example.com/" target=3D"_blank">http://www.example.com/</a>&=
quot;) + q;</div><div>target would be &quot;<a href=3D"http://www.example.c=
om/?name=3Dferret" target=3D"_blank">http://www.example.com/?name=3Dferret<=
/a>&quot;);</div>


<div>q would be &quot;?name=3Dferret&quot;=A0</div><div><br></div><div>Yes,=
 there is the &quot;?&quot;, because &quot;name=3Dferret&quot; cannot be pa=
rse to a uri, where &quot;?name=3Dferret&quot; can.</div><div><br></div><di=
v>With the current proposal, how would I make &quot;q&quot;?</div>


<div>uri q =3D source.query() ? uri(&quot;?&quot; + *source.query()) : uri(=
&quot;&quot;);</div><div></div></blockquote></div><br></div>This is interes=
ting.</div><div class=3D"gmail_extra">Dean and Glynn, did you consider retu=
rning uri?</div>


<div class=3D"gmail_extra"><br></div></div></blockquote><div><br></div><div=
>No, I always wanted to return a reference to the underlying string. Return=
ing a uri object means an additional string copy.</div><div>
<br></div><div></div></div></div><div class=3D"gmail_extra" style>Regards,<=
/div><div class=3D"gmail_extra" style>Glyn</div><div class=3D"gmail_extra">=
<br></div><div class=3D"gmail_extra"><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 post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.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 />

--f46d04430606d04bcd04d40add43--

.

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

On 24 January 2013 12:26, Dean Michael Berris <dberris@google.com> wrote:

>
>
> It can use the URI type directly if it wanted to use the correct
> enforcement of the RFC -- or more to the point, if it wanted to use it
> as part of its internal APIs.
>
> I realize the proposal actually supports relative URI's (I must admit
> I let Glyn define that part) and that this is even now useful in the
> context of an HTTP server. Of course it has to make assumptions on the
> scheme and in that context it's definitely possible.
>
>
The proposal does support relative URIs. Relative URIs can be created in
one of two ways:

1. As the return value of "uri::relativize"
2. By using "uri_builder"

I will acknowledge now that that "uri_builder" is a weak part of this
proposal as it doesn't go far enough into the details of how to validate
each part, and I hope to encourage comments on this part of the proposal.

Regards,
Glyn

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--089e0103ee906cb5a804d40addc1
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 January 2013 12:26, Dean Michael Berris <span dir=3D"ltr">&lt=
;<a href=3D"mailto:dberris@google.com" target=3D"_blank">dberris@google.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>
<div><br>
It can use the URI type directly if it wanted to use the correct<br>
</div>enforcement of the RFC -- or more to the point, if it wanted to use i=
t<br>
as part of its internal APIs.<br>
<br>
I realize the proposal actually supports relative URI&#39;s (I must admit<b=
r>
I let Glyn define that part) and that this is even now useful in the<br>
context of an HTTP server. Of course it has to make assumptions on the<br>
scheme and in that context it&#39;s definitely possible.<br>
<div><br></div></blockquote><div><br></div><div>The proposal does support r=
elative URIs. Relative URIs can be created in one of two ways:</div><div><b=
r></div><div>1. As the return value of &quot;uri::relativize&quot;</div>

<div>2. By using &quot;uri_builder&quot;</div><div><br></div><div>I will ac=
knowledge now that that &quot;uri_builder&quot; is a weak part of this prop=
osal as it doesn&#39;t go far enough into the details of how to validate ea=
ch part, and I hope to encourage comments on this part of the proposal.</di=
v>
<div><br></div><div>Regards,</div><div style>Glyn</div>
<div><br></div><div><br></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 post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.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 />

--089e0103ee906cb5a804d40addc1--

.

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

On 24 January 2013 15:49, Vincent Jacquet <vjacquet@flowgroup.fr> wrote:

> Speaking of *uri*, I sincerly think there is something wrong with accessor
> returning an optional<string_ref>: the string_ref part!
>
> I want to manipulate uri, not its components, because the manipulation of
> the components of a uri is scheme dependent, and I do not want to write
> scheme dependent code all over the place.
>
> It may be a little extreme but please consider:
> "W3C recommends that all web servers support semicolon separators in
> addition to ampersand separators[6] to allow
> application/x-www-form-urlencoded query strings in URLs within HTML
> documents without having to entity escape ampersands." (see <
> http://en.wikipedia.org/wiki/Query_string>).
> I didn't knew that until 5 minutes ago. If I had started to parse the
> query string into a multi_map, my parsing would have been incomplete.
>
>
I was surprised to see this as well when I first encountered it while
implementing the URI in cpp-netlib. However, this doesn't really affect
this proposal as this is a scheme-specific detail and the proposed uri is
limited to being generic.


> IMVHO the design of the uri type should not encourage to access the
> components as a string (or string_ref or optional<string_ref>), because
> it is way too tempting to "handle it myself". Ideally, it should give me
> a scheme object that would interpret its parts.
>
>
I'm sorry, I don't understand what you want in the last sentence. If you
want scheme-specific processing, I think there is definitely room for other
proposals for scheme-specific URIs, particularly for HTTP.

Regards,
Glyn

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--089e0122f17061eb1304d40ade19
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 January 2013 15:49, Vincent Jacquet <span dir=3D"ltr">&lt;<a =
href=3D"mailto:vjacquet@flowgroup.fr" target=3D"_blank">vjacquet@flowgroup.=
fr</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>Speaking of *uri*, I sincerly think the=
re is something wrong with accessor returning an optional&lt;string_ref&gt;=
: the string_ref part!</div>
<div><br></div><div>I want to manipulate uri, not its components, because t=
he manipulation of the components of a uri is scheme dependent, and I do no=
t want to write scheme dependent code all over the place.</div><div><br>
</div>It may be a little extreme but please consider:<div><span style=3D"li=
ne-height:19.1875px;font-family:sans-serif">&quot;W3C recommends that all w=
eb servers support semicolon separators in addition to ampersand separators=
[6] to allow application/x-www-form-urlencoded query strings in URLs within=
 HTML documents without having to entity escape ampersands.&quot; (see &lt;=
<a href=3D"http://en.wikipedia.org/wiki/Query_string" target=3D"_blank">htt=
p://en.wikipedia.org/wiki/Query_string</a>&gt;).</span><br>
</div><div><span style=3D"line-height:19.1875px;font-family:sans-serif">I d=
idn&#39;t knew that until 5 minutes ago. If I had started to parse the quer=
y string into a multi_map, my parsing would have been incomplete.</span><br=
>
</div><div><span style=3D"line-height:19.1875px;font-family:sans-serif"><br=
></span></div></blockquote><div><br></div><div style>I was surprised to see=
 this as well when I first encountered it while implementing the URI in cpp=
-netlib. However, this doesn&#39;t really affect this proposal as this is a=
 scheme-specific detail and the proposed uri is limited to being generic.</=
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><span style=3D"line-heigh=
t:19.1875px;font-family:sans-serif"></span></div><div><span style=3D"line-h=
eight:19.1875px;font-family:sans-serif">IMVHO the design of the uri type sh=
ould not encourage to access the components as a string (or=A0</span><span =
style=3D"line-height:19.1875px;font-family:sans-serif">string_ref or option=
al&lt;string_ref&gt;), because it is way too tempting to &quot;handle it my=
self&quot;</span><span style=3D"line-height:19.1875px;font-family:sans-seri=
f">. Ideally, it=A0</span><span style=3D"line-height:19.1875px;font-family:=
sans-serif">should give me a scheme object that would interpret its parts.<=
/span></div>
<div><span style=3D"line-height:19.1875px;font-family:sans-serif"><br></spa=
n></div></blockquote><div><br></div><div style>I&#39;m sorry, I don&#39;t u=
nderstand what you want in the last sentence. If you want scheme-specific p=
rocessing, I think there is definitely room for other proposals for scheme-=
specific URIs, particularly for HTTP.</div>
<div style><br></div><div style>Regards,</div><div style>Glyn</div><div><br=
></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 post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.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 />

--089e0122f17061eb1304d40ade19--

.

On Wed, Jan 23, 2013 at 5:33 PM, Dean Michael Berris <dberris@google.com> wrote:
>
> std::optional<std::string_ref> is perfect in this use case. Here's the
> list of reasons:
>
> - If the URI has a part, it should return a reference to that part of
> the string.
> - If the URI does not have that part explicitly defined, you return an
> uninitialised std::optional<>.
> - If the URI does have that part explicitly defined but empty, you
> return a std::optional<> that had a default-constructed
> std::string_ref.
>
> It's also good for value semantics.
>
> I'm opposed to adding more members to the URI class unless it's
> absolutely necessary. std::optional<> does this nicely for us
> conveying the correct semantics. It keeps the URI class simple and
> easy to understand and easy to keep a mental model of.
>

Note that if string_ref itself distinquished between null and empty,
we wouldn't need optional at all.
ie a string_ref which is pointer + length would be:

[ 0xabcd1234, 0 ]   = points to one-past-question-mark, has length 0
[ 0, 0 ] = no question-mark in URI

And similar for [ begin, end ] style of string_ref:

[ 0xabcd1234, 0xabcd1234 ]
[ 0, 0 ]

Tony

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

------=_Part_366_26164348.1359049655559
Content-Type: text/plain; charset=ISO-8859-1



> No, I always wanted to return a reference to the underlying string.
> Returning a uri object means an additional string copy.
>
> Regards,
> Glyn
>


There might be a few more assignments involved but, if your uri holds a
shared_ptr<char*>, you might not need an additional string copy. Your
assertion might be implementation specific. Anyway, I agree it would cost
more to create a new uri than to return string_ref or optional<string_ref>.

I am currious: you are saying that you always wanted to return a reference
to the underlying string. Why? What do you want to do with it?

Thanks,
Vincent

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_366_26164348.1359049655559
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;"><div dir=3D"ltr"><div><div=
 class=3D"gmail_quote"><div>No, I always wanted to return a reference to th=
e underlying string. Returning a uri object means an additional string copy=
..</div><div>
<br></div><div></div></div></div><div>Regards,</div><div>Glyn&nbsp;</div></=
div></blockquote><div><br></div><div><br></div><div>There might be a few mo=
re assignments involved but, if your uri holds a shared_ptr&lt;char*&gt;, y=
ou might not need an additional string copy. Your assertion might be implem=
entation specific. Anyway, I agree it would cost more to create a new uri t=
han to return string_ref or optional&lt;string_ref&gt;.</div><div><br></div=
><div>I am currious: you are saying that you always wanted to return a refe=
rence to the underlying string. Why? What do you want to do with it?<br></d=
iv><div><br></div><div>Thanks,</div><div>Vincent</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 post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.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_366_26164348.1359049655559--

.

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

On 24 January 2013 11:26, Tony V E <tvaneerd@gmail.com> wrote:

>
> Note that if string_ref itself distinquished between null and empty,
> we wouldn't need optional at all.
>

That just moves the problem.


> ie a string_ref which is pointer + length would be:
>
> [ 0xabcd1234, 0 ]   = points to one-past-question-mark, has length 0
> [ 0, 0 ] = no question-mark in URI
>

It also means one cannot easily create a string_ref out of a vector<char>
(since vector.data() is allowed to return nullptr).

If the URI library wants to reserve its own special address for meaning a
"null" string_ref for itself, that would be fine, but I wouldn't use
nullptr as that address.
--
 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 post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



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

On 24 January 2013 11:26, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mailto:=
tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> wro=
te:<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 class=3D"im"><br>
</div>Note that if string_ref itself distinquished between null and empty,<=
br>
we wouldn&#39;t need optional at all.<br></blockquote><div><br>That just mo=
ves the problem.<br>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
ie a string_ref which is pointer + length would be:<br>
<br>
[ 0xabcd1234, 0 ] =A0 =3D points to one-past-question-mark, has length 0<br=
>
[ 0, 0 ] =3D no question-mark in URI<br></blockquote><div><br>It also means=
 one cannot easily create a string_ref out of a vector&lt;char&gt; (since v=
ector.data() is allowed to return nullptr).<br><br>If the URI library wants=
 to reserve its own special address for meaning a &quot;null&quot; string_r=
ef for itself, that would be fine, but I wouldn&#39;t use nullptr as that a=
ddress.<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 post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.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 />

--20cf3074b4f87cbf4704d40c7b1b--

.

On Thu, Jan 24, 2013 at 6:52 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> That just moves the problem.

Why? IMO it'd solve it.

> It also means one cannot easily create a string_ref out of a vector<char>
> (since vector.data() is allowed to return nullptr).

Why not?
It may just mean the resulting string_ref would be null.

--
Olaf

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

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

On 24 January 2013 12:05, Olaf van der Spek <olafvdspek@gmail.com> wrote:

> On Thu, Jan 24, 2013 at 6:52 PM, Nevin Liber <nevin@eviloverlord.com>
> wrote:
> > That just moves the problem.
>
> Why? IMO it'd solve it.
>
> > It also means one cannot easily create a string_ref out of a vector<char>
> > (since vector.data() is allowed to return nullptr).
>
> Why not?
> It may just mean the resulting string_ref would be null.
>

Because that is not what is meant by vector<char>, as it has doesn't model
the nullable concept.  For a typical implementation:

vector<char> v;
string_ref vnull(v.data(), v.size());
v.reserve(1);
string_ref vempty(v.data(), v.size());

It is unexpected that vnull and vempty represent two different things, and
that is only because of a side effect of the implementation.
--
 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 post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



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

On 24 January 2013 12:05, Olaf van der Spek <span dir=3D"ltr">&lt;<a href=
=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com</a>=
&gt;</span> wrote:<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 class=3D"im">On Thu, Jan 24, 2013 at 6:52 PM, Nevin Liber &lt;<a href=
=3D"mailto:nevin@eviloverlord.com">nevin@eviloverlord.com</a>&gt; wrote:<br=
>
&gt; That just moves the problem.<br>
<br>
</div>Why? IMO it&#39;d solve it.<br>
<div class=3D"im"><br>
&gt; It also means one cannot easily create a string_ref out of a vector&lt=
;char&gt;<br>
&gt; (since vector.data() is allowed to return nullptr).<br>
<br>
</div>Why not?<br>
It may just mean the resulting string_ref would be null.<br clear=3D"all"><=
/blockquote><div><br>Because that is not what is meant by vector&lt;char&gt=
;, as it has doesn&#39;t model the nullable concept.=A0 For a typical imple=
mentation:<br>

<br>vector&lt;char&gt; v;<br>string_ref vnull(v.data(), v.size());<br>v.res=
erve(1);<br>string_ref vempty(v.data(), v.size());<br><br>It is unexpected =
that vnull and vempty represent two different things, and that is only beca=
use of a side effect of the implementation.<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 post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.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 />

--047d7bb70dfe3d1d2504d40d141f--

.

------=_Part_32_9304019.1359058933243
Content-Type: text/plain; charset=ISO-8859-1

"this is a scheme-specific detail and the proposed uri is limited to being
generic".
How do you implement scheme_based_normalization or
protocol_based_normalization then ?



On Thursday, January 24, 2013 4:57:32 PM UTC+1, Glyn Matthews wrote:
>
>
>
>
> On 24 January 2013 15:49, Vincent Jacquet <vjac...@flowgroup.fr<javascript:>
> > wrote:
>
>> Speaking of *uri*, I sincerly think there is something wrong with
>> accessor returning an optional<string_ref>: the string_ref part!
>>
>> I want to manipulate uri, not its components, because the manipulation of
>> the components of a uri is scheme dependent, and I do not want to write
>> scheme dependent code all over the place.
>>
>> It may be a little extreme but please consider:
>> "W3C recommends that all web servers support semicolon separators in
>> addition to ampersand separators[6] to allow
>> application/x-www-form-urlencoded query strings in URLs within HTML
>> documents without having to entity escape ampersands." (see <
>> http://en.wikipedia.org/wiki/Query_string>).
>> I didn't knew that until 5 minutes ago. If I had started to parse the
>> query string into a multi_map, my parsing would have been incomplete.
>>
>>
> I was surprised to see this as well when I first encountered it while
> implementing the URI in cpp-netlib. However, this doesn't really affect
> this proposal as this is a scheme-specific detail and the proposed uri is
> limited to being generic.
>
>
>> IMVHO the design of the uri type should not encourage to access the
>> components as a string (or string_ref or optional<string_ref>), because
>> it is way too tempting to "handle it myself". Ideally, it should give me
>> a scheme object that would interpret its parts.
>>
>>
> I'm sorry, I don't understand what you want in the last sentence. If you
> want scheme-specific processing, I think there is definitely room for other
> proposals for scheme-specific URIs, particularly for HTTP.
>
> Regards,
> Glyn
>
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



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

"this is a scheme-specific detail and the proposed uri is limited to being =
generic".&nbsp;<div>How do you implement&nbsp;<span style=3D"color: rgb(0, =
0, 0);">scheme_based_normalization or protocol_based_normalization then ?</=
span></div><div><font color=3D"#000000"><br></font></div><div><font color=
=3D"#000000"><br></font><br>On Thursday, January 24, 2013 4:57:32 PM UTC+1,=
 Glyn Matthews wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br><div><br><br><div class=3D"gmail_quote">On 24 January 2013 15:=
49, Vincent Jacquet <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"pdQn2t-5gt8J">vjac...@flowgroup.fr</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>Speaking of *uri*, I sincerly think the=
re is something wrong with accessor returning an optional&lt;string_ref&gt;=
: the string_ref part!</div>
<div><br></div><div>I want to manipulate uri, not its components, because t=
he manipulation of the components of a uri is scheme dependent, and I do no=
t want to write scheme dependent code all over the place.</div><div><br>
</div>It may be a little extreme but please consider:<div><span style=3D"li=
ne-height:19.1875px;font-family:sans-serif">"W3C recommends that all web se=
rvers support semicolon separators in addition to ampersand separators[6] t=
o allow application/x-www-form-<wbr>urlencoded query strings in URLs within=
 HTML documents without having to entity escape ampersands." (see &lt;<a hr=
ef=3D"http://en.wikipedia.org/wiki/Query_string" target=3D"_blank">http://e=
n.wikipedia.org/wiki/<wbr>Query_string</a>&gt;).</span><br>
</div><div><span style=3D"line-height:19.1875px;font-family:sans-serif">I d=
idn't knew that until 5 minutes ago. If I had started to parse the query st=
ring into a multi_map, my parsing would have been incomplete.</span><br>
</div><div><span style=3D"line-height:19.1875px;font-family:sans-serif"><br=
></span></div></blockquote><div><br></div><div>I was surprised to see this =
as well when I first encountered it while implementing the URI in cpp-netli=
b. However, this doesn't really affect this proposal as this is a scheme-sp=
ecific detail and the proposed uri is limited to being generic.</div>
<div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div><span style=3D"line-he=
ight:19.1875px;font-family:sans-serif"></span></div><div><span style=3D"lin=
e-height:19.1875px;font-family:sans-serif">IMVHO the design of the uri type=
 should not encourage to access the components as a string (or&nbsp;</span>=
<span style=3D"line-height:19.1875px;font-family:sans-serif">string_ref or =
optional&lt;string_ref&gt;), because it is way too tempting to "handle it m=
yself"</span><span style=3D"line-height:19.1875px;font-family:sans-serif">.=
 Ideally, it&nbsp;</span><span style=3D"line-height:19.1875px;font-family:s=
ans-serif">should give me a scheme object that would interpret its parts.</=
span></div>
<div><span style=3D"line-height:19.1875px;font-family:sans-serif"><br></spa=
n></div></blockquote><div><br></div><div>I'm sorry, I don't understand what=
 you want in the last sentence. If you want scheme-specific processing, I t=
hink there is definitely room for other proposals for scheme-specific URIs,=
 particularly for HTTP.</div>
<div><br></div><div>Regards,</div><div>Glyn</div><div><br></div></div></div=
></div>
</blockquote></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 post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.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_32_9304019.1359058933243--

.

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

On 24 January 2013 18:47, Vincent Jacquet <vjacquet@flowgroup.fr> wrote:

>
> No, I always wanted to return a reference to the underlying string.
>> Returning a uri object means an additional string copy.
>>
>> Regards,
>> Glyn
>>
>
>
> There might be a few more assignments involved but, if your uri holds a
> shared_ptr<char*>, you might not need an additional string copy. Your
> assertion might be implementation specific. Anyway, I agree it would cost
> more to create a new uri than to return string_ref or optional<string_ref>.
>
> I am currious: you are saying that you always wanted to return a reference
> to the underlying string. Why? What do you want to do with it?
>
>
That was what I wanted when I first started implementing the URI in
cpp-netlib, long before I'd heard of string_ref. The only reason is one of
efficiency, I saw no need to copy each string part as some other
implementations do.

Regards,
Glyn

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--f46d0435c03caac38204d41d1fc9
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 January 2013 18:47, Vincent Jacquet <span dir=3D"ltr">&lt;<a =
href=3D"mailto:vjacquet@flowgroup.fr" target=3D"_blank">vjacquet@flowgroup.=
fr</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><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>No, I always wanted t=
o return a reference to the underlying string. Returning a uri object means=
 an additional string copy.</div><div>
<br></div><div></div></div></div><div>Regards,</div><div>Glyn=A0</div></div=
></blockquote><div><br></div><div><br></div></div><div>There might be a few=
 more assignments involved but, if your uri holds a shared_ptr&lt;char*&gt;=
, you might not need an additional string copy. Your assertion might be imp=
lementation specific. Anyway, I agree it would cost more to create a new ur=
i than to return string_ref or optional&lt;string_ref&gt;.</div>


<div><br></div><div>I am currious: you are saying that you always wanted to=
 return a reference to the underlying string. Why? What do you want to do w=
ith it?<br></div><div><br></div></blockquote><div><br></div><div>That was w=
hat I wanted when I first started implementing the URI in cpp-netlib, long =
before I&#39;d heard of string_ref. The only reason is one of efficiency, I=
 saw no need to copy each string part as some other implementations do.</di=
v>

<div></div></div><br></div><div class=3D"gmail_extra">Regards,</div><div cl=
ass=3D"gmail_extra">Glyn</div><div class=3D"gmail_extra"><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 post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.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 />

--f46d0435c03caac38204d41d1fc9--

.

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

On 24 January 2013 21:22, Vincent Jacquet <vjacquet@flowgroup.fr> wrote:

> "this is a scheme-specific detail and the proposed uri is limited to being
> generic".
> How do you implement scheme_based_normalization or
> protocol_based_normalization then ?
>
>
The proposal currently states that it won't implement each of these steps:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3507.html#the-comparison-ladder

An open question therefore is how to extend the proposal to allow at least
scheme-based normalization.

Regards,
Gltyn

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--f46d043be2403fa5af04d41d2080
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 January 2013 21:22, Vincent Jacquet <span dir=3D"ltr">&lt;<a =
href=3D"mailto:vjacquet@flowgroup.fr" target=3D"_blank">vjacquet@flowgroup.=
fr</a>&gt;</span> wrote:<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"><div>&quot;this is a scheme-specific detail and the propos=
ed uri is limited to being generic&quot;.=A0</div>
<div>
How do you implement=A0<span>scheme_based_normalization or protocol_based_n=
ormalization then ?</span></div><div><br></div></blockquote><div>=A0</div><=
div style>The proposal currently states that it won&#39;t implement each of=
 these steps:</div>
<div style><br></div><div style><a href=3D"http://www.open-std.org/jtc1/sc2=
2/wg21/docs/papers/2013/n3507.html#the-comparison-ladder">http://www.open-s=
td.org/jtc1/sc22/wg21/docs/papers/2013/n3507.html#the-comparison-ladder</a>=
<br>
</div><div style><br></div><div style>An open question therefore is how to =
extend the proposal to allow at least scheme-based normalization.</div><div=
 style><br></div><div style>Regards,</div><div style>Gltyn</div><div><br>
</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 post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.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 />

--f46d043be2403fa5af04d41d2080--

.

On Fri, Jan 25, 2013 at 2:44 PM, Glyn Matthews <glynos@acm.org> wrote:
>> I am currious: you are saying that you always wanted to return a reference
>> to the underlying string. Why? What do you want to do with it?
>>
>
> That was what I wanted when I first started implementing the URI in
> cpp-netlib, long before I'd heard of string_ref. The only reason is one of
> efficiency, I saw no need to copy each string part as some other
> implementations do.

But the implementation still copies the input string, right?
Would there be a way to avoid this copy too?

--
Olaf

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.