Topic: [Ranges] ranges, string_ref, A URI Library
Author: Sean Parent <sean_parent@mac.com>
Date: Thu, 24 Jan 2013 12:02:30 -0800
Raw View
--047d7b2ee87574c97204d40e4a29
Content-Type: text/plain; charset=ISO-8859-1
Yes - empty ranges are not equal and denote a position. Two ranges are
equal iff every position in the interval [begin, end] are equal.
Sean
On Thu, Jan 24, 2013 at 11:27 AM, Tony V E <tvaneerd@gmail.com> wrote:
> On Thu, Jan 24, 2013 at 1:35 PM, Nevin Liber <nevin@eviloverlord.com>
> wrote:
> > 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
> >
>
>
> That's an interesting case, although I'm not sure it is important
> enough to base decisions on.
>
> Let's take this one step beyond string_ref and consider ranges. - with
> the assumption that string_ref should closely align with ranges. (I
> mean we started with URIs, moved through optional to string_ref, why
> stop there?)
>
> - In math, (with open-close interval notation) the interval (0,0) is
> typically not considered the same as (1,1), although they are both
> empty.
>
> - might ranges have a way to extend their range (extend_front(int) or
> whatever)? So an empty range at the beginning of a string is not the
> same as an empty range at the middle because once you extend by 1 you
> get different ranges.
>
> basically, does a range devolve into a position? If so, empty ranges
> are not all equivalent.
>
> Hmmmm, I actually haven't yet said anything about null ranges - just
> various empties. ie ranges that point into empty regions of the
> string, but nothing about ranges that don't point into the string at
> all. Note that (end,end) can't be used as the "null range" - it
> wouldn't solve the URI query case - it doesn't differentiate
> "www.example.com/foo?" from "www.example.com/foo" as the query, in
> both cases, would be (end, end).
>
>
> Well, without moving to actual null vs empty, I'll just point out that
> I think that
>
> (range1.empty() && range2.empty()) != (range1 == range2)
>
> And that the same should be true for string_ref,
> And that that is at least one step towards string_ref having separate
> concepts of null and empty.
>
> Tony
> _______________________________________________
> Ranges mailing list
> Ranges@isocpp.open-std.org
> http://www.open-std.org/mailman/listinfo/ranges
>
--
---
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.
--047d7b2ee87574c97204d40e4a29
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Yes - empty ranges are not equal and denote a position. Tw=
o ranges are equal iff every position in the interval [begin, end] are equa=
l.<div><br></div><div style>Sean</div></div><div class=3D"gmail_extra"><br>=
<br>
<div class=3D"gmail_quote">On Thu, Jan 24, 2013 at 11:27 AM, Tony V E <span=
dir=3D"ltr"><<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tv=
aneerd@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote"=
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thu, Jan 24, 2013 at 1:35 PM, Nevin Liber <<a href=3D"mailto:nevin@ev=
iloverlord.com">nevin@eviloverlord.com</a>> wrote:<br>
> On 24 January 2013 12:05, Olaf van der Spek <<a href=3D"mailto:olaf=
vdspek@gmail.com">olafvdspek@gmail.com</a>> wrote:<br>
>><br>
>> On Thu, Jan 24, 2013 at 6:52 PM, Nevin Liber <<a href=3D"mailto=
:nevin@eviloverlord.com">nevin@eviloverlord.com</a>><br>
>> wrote:<br>
>> > That just moves the problem.<br>
>><br>
>> Why? IMO it'd solve it.<br>
>><br>
>> > It also means one cannot easily create a string_ref out of a<=
br>
>> > vector<char><br>
>> > (since vector.data() is allowed to return nullptr).<br>
>><br>
>> Why not?<br>
>> It may just mean the resulting string_ref would be null.<br>
><br>
><br>
> Because that is not what is meant by vector<char>, as it has doe=
sn't model<br>
> the nullable concept. =A0For a typical implementation:<br>
><br>
> vector<char> v;<br>
> string_ref vnull(v.data(), v.size());<br>
> v.reserve(1);<br>
> string_ref vempty(v.data(), v.size());<br>
><br>
> It is unexpected that vnull and vempty represent two different things,=
and<br>
> that is only because of a side effect of the implementation.<br>
> --<br>
> =A0Nevin ":-)" Liber =A0<mailto:<a href=3D"mailto:nevin@e=
viloverlord.com">nevin@eviloverlord.com</a>> =A0<a href=3D"tel:%28847%29=
%20691-1404" value=3D"+18476911404">(847) 691-1404</a><br>
><br>
<br>
<br>
That's an interesting case, although I'm not sure it is important<b=
r>
enough to base decisions on.<br>
<br>
Let's take this one step beyond string_ref and consider ranges. - with<=
br>
the assumption that string_ref should closely align with ranges. =A0(I<br>
mean we started with URIs, moved through optional to string_ref, why<br>
stop there?)<br>
<br>
- In math, (with open-close interval notation) the interval (0,0) is<br>
typically not considered the same as (1,1), although they are both<br>
empty.<br>
<br>
- might ranges have a way to extend their range (extend_front(int) or<br>
whatever)? =A0So an empty range at the beginning of a string is not the<br>
same as an empty range at the middle because once you extend by 1 you<br>
get different ranges.<br>
<br>
basically, does a range devolve into a position? =A0If so, empty ranges<br>
are not all equivalent.<br>
<br>
Hmmmm, I actually haven't yet said anything about null ranges - just<br=
>
various empties. =A0ie ranges that point into empty regions of the<br>
string, but nothing about ranges that don't point into the string at<br=
>
all. =A0Note that (end,end) can't be used as the "null range"=
- it<br>
wouldn't solve the URI query case - it doesn't differentiate<br>
"<a href=3D"http://www.example.com/foo" target=3D"_blank">www.example.=
com/foo</a>?" from "<a href=3D"http://www.example.com/foo" target=
=3D"_blank">www.example.com/foo</a>" as the query, in<br>
both cases, would be (end, end).<br>
<br>
<br>
Well, without moving to actual null vs empty, I'll just point out that<=
br>
I think that<br>
<br>
=A0 =A0 =A0 (range1.empty() && range2.empty()) !=3D (range1 =3D=3D =
range2)<br>
<br>
And that the same should be true for string_ref,<br>
And that that is at least one step towards string_ref having separate<br>
concepts of null and empty.<br>
<br>
Tony<br>
_______________________________________________<br>
Ranges mailing list<br>
<a href=3D"mailto:Ranges@isocpp.open-std.org">Ranges@isocpp.open-std.org</a=
><br>
<a href=3D"http://www.open-std.org/mailman/listinfo/ranges" target=3D"_blan=
k">http://www.open-std.org/mailman/listinfo/ranges</a><br>
</blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--047d7b2ee87574c97204d40e4a29--
.
Author: Sean Parent <sean.parent@gmail.com>
Date: Thu, 24 Jan 2013 14:14:51 -0800
Raw View
--Apple-Mail-01F0F9AC-3390-48AB-A9E7-C1CA6F7F8925
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Sent from my iPad
On Jan 24, 2013, at 12:32 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>=20
>=20
> On Thursday, January 24, 2013 11:27:14 AM UTC-8, Tony V E wrote:
>>=20
>> On Thu, Jan 24, 2013 at 1:35 PM, Nevin Liber <ne...@eviloverlord.com> wr=
ote:=20
>> > On 24 January 2013 12:05, Olaf van der Spek <olafv...@gmail.com> wrote=
:=20
>> >>=20
>> >> On Thu, Jan 24, 2013 at 6:52 PM, Nevin Liber <ne...@eviloverlord.com>=
=20
>> >> wrote:=20
>> >> > That just moves the problem.=20
>> >>=20
>> >> Why? IMO it'd solve it.=20
>> >>=20
>> >> > It also means one cannot easily create a string_ref out of a=20
>> >> > vector<char>=20
>> >> > (since vector.data() is allowed to return nullptr).=20
>> >>=20
>> >> Why not?=20
>> >> It may just mean the resulting string_ref would be null.=20
>> >=20
>> >=20
>> > Because that is not what is meant by vector<char>, as it has doesn't m=
odel=20
>> > the nullable concept. For a typical implementation:=20
>> >=20
>> > vector<char> v;=20
>> > string_ref vnull(v.data(), v.size());=20
>> > v.reserve(1);=20
>> > string_ref vempty(v.data(), v.size());=20
>> >=20
>> > It is unexpected that vnull and vempty represent two different things,=
and=20
>> > that is only because of a side effect of the implementation.=20
>> > --=20
>> > Nevin ":-)" Liber <mailto:ne...@eviloverlord.com> (847) 691-1404=20
>> >=20
>>=20
>>=20
>> That's an interesting case, although I'm not sure it is important=20
>> enough to base decisions on.=20
>>=20
>> Let's take this one step beyond string_ref and consider ranges. - with=
=20
>> the assumption that string_ref should closely align with ranges. (I=20
>> mean we started with URIs, moved through optional to string_ref, why=20
>> stop there?)=20
>>=20
>> - In math, (with open-close interval notation) the interval (0,0) is=20
>> typically not considered the same as (1,1), although they are both=20
>> empty.=20
>>=20
>> - might ranges have a way to extend their range (extend_front(int) or=20
>> whatever)? So an empty range at the beginning of a string is not the=20
>> same as an empty range at the middle because once you extend by 1 you=20
>> get different ranges.=20
>>=20
>> basically, does a range devolve into a position? If so, empty ranges=20
>> are not all equivalent.=20
>>=20
>> Hmmmm, I actually haven't yet said anything about null ranges - just=20
>> various empties. ie ranges that point into empty regions of the=20
>> string, but nothing about ranges that don't point into the string at=20
>> all. Note that (end,end) can't be used as the "null range" - it=20
>> wouldn't solve the URI query case - it doesn't differentiate=20
>> "www.example.com/foo?" from "www.example.com/foo" as the query, in=20
>> both cases, would be (end, end).=20
>>=20
>>=20
>> Well, without moving to actual null vs empty, I'll just point out that=
=20
>> I think that=20
>>=20
>> (range1.empty() && range2.empty()) !=3D (range1 =3D=3D range2)=20
>>=20
>> And that the same should be true for string_ref,=20
>> And that that is at least one step towards string_ref having separate=20
>> concepts of null and empty.=20
>>=20
>> Tony=20
>=20
> No. Absolutely not. We already have a library facility for "nullable" obj=
ects. It's called `optional`. That's what should be used. Period. Trying to=
finangle some notion of "null string_ref" vs. "empty string_ref" via some =
kind of range nonsense would be exceedingly confusing to the user.
>=20
> Furthermore, `empty` for a "null string_ref" should return false. Because=
it's not empty; it doesn't exist.
I don't know much about string_ref but I would thin a null string ref would=
return the valid, and empty, range of [null, null).
Sean
> _______________________________________________
> Ranges mailing list
> Ranges@isocpp.open-std.org
> http://www.open-std.org/mailman/listinfo/ranges
--=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.
--Apple-Mail-01F0F9AC-3390-48AB-A9E7-C1CA6F7F8925
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div><br><br>Sent from my iPad</div><di=
v><br>On Jan 24, 2013, at 12:32 PM, Nicol Bolas <<a href=3D"mailto:jmcke=
sson@gmail.com">jmckesson@gmail.com</a>> wrote:<br><br></div><blockquote=
type=3D"cite"><div><br><br>On Thursday, January 24, 2013 11:27:14 AM UTC-8=
, Tony V E wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thu, Jan 2=
4, 2013 at 1:35 PM, Nevin Liber <<a href=3D"javascript:" target=3D"_blan=
k" gdf-obfuscated-mailto=3D"FzKTX6dbqwwJ">ne...@eviloverlord.com</a>> wr=
ote:
<br>> On 24 January 2013 12:05, Olaf van der Spek <<a href=3D"javascr=
ipt:" target=3D"_blank" gdf-obfuscated-mailto=3D"FzKTX6dbqwwJ">olafv...@gma=
il.com</a>> wrote:
<br>>>
<br>>> On Thu, Jan 24, 2013 at 6:52 PM, Nevin Liber <<a href=3D"ja=
vascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"FzKTX6dbqwwJ">ne...@e=
viloverlord.com</a>>
<br>>> wrote:
<br>>> > That just moves the problem.
<br>>>
<br>>> Why? IMO it'd solve it.
<br>>>
<br>>> > It also means one cannot easily create a string_ref out o=
f a
<br>>> > vector<char>
<br>>> > (since vector.data() is allowed to return nullptr).
<br>>>
<br>>> Why not?
<br>>> It may just mean the resulting string_ref would be null.
<br>>
<br>>
<br>> Because that is not what is meant by vector<char>, as it has=
doesn't model
<br>> the nullable concept. For a typical implementation:
<br>>
<br>> vector<char> v;
<br>> string_ref vnull(v.data(), v.size());
<br>> v.reserve(1);
<br>> string_ref vempty(v.data(), v.size());
<br>>
<br>> It is unexpected that vnull and vempty represent two different thi=
ngs, and
<br>> that is only because of a side effect of the implementation.
<br>> --
<br>> Nevin ":-)" Liber <mailto:<a href=3D"javascript:" t=
arget=3D"_blank" gdf-obfuscated-mailto=3D"FzKTX6dbqwwJ">ne...@eviloverlord.=
<wbr>com</a>> (847) 691-1404
<br>>
<br>
<br>
<br>That's an interesting case, although I'm not sure it is important
<br>enough to base decisions on.
<br>
<br>Let's take this one step beyond string_ref and consider ranges. - with
<br>the assumption that string_ref should closely align with ranges. =
(I
<br>mean we started with URIs, moved through optional to string_ref, why
<br>stop there?)
<br>
<br>- In math, (with open-close interval notation) the interval (0,0) is
<br>typically not considered the same as (1,1), although they are both
<br>empty.
<br>
<br>- might ranges have a way to extend their range (extend_front(int) or
<br>whatever)? So an empty range at the beginning of a string is not =
the
<br>same as an empty range at the middle because once you extend by 1 you
<br>get different ranges.
<br>
<br>basically, does a range devolve into a position? If so, empty ran=
ges
<br>are not all equivalent.
<br>
<br>Hmmmm, I actually haven't yet said anything about null ranges - just
<br>various empties. ie ranges that point into empty regions of the
<br>string, but nothing about ranges that don't point into the string at
<br>all. Note that (end,end) can't be used as the "null range" - it
<br>wouldn't solve the URI query case - it doesn't differentiate
<br>"<a href=3D"http://www.example.com/foo" target=3D"_blank">www.example.c=
om/foo</a>?" from "<a href=3D"http://www.example.com/foo" target=3D"_blank"=
>www.example.com/foo</a>" as the query, in
<br>both cases, would be (end, end).
<br>
<br>
<br>Well, without moving to actual null vs empty, I'll just point out that
<br>I think that
<br>
<br> (range1.empty() && range2.empty()) !=3D (r=
ange1 =3D=3D range2)
<br>
<br>And that the same should be true for string_ref,
<br>And that that is at least one step towards string_ref having separate
<br>concepts of null and empty.
<br>
<br>Tony
<br></blockquote><div><br>No. Absolutely not. We already have a library fac=
ility for "nullable" objects. It's called `optional`. That's what should be=
used. Period. Trying to finangle some notion of "null string_ref" vs. "emp=
ty string_ref" via some kind of range nonsense would be exceedingly confusi=
ng to the user.<br><br>Furthermore, `empty` for a "null string_ref" should =
return <i>false</i>. Because it's not empty; it doesn't exist.<br></div>
</div></blockquote><div><br></div><div>I don't know much about string_ref b=
ut I would thin a null string ref would return the valid, and empty, range =
of [null, null).</div><div><br></div><div>Sean</div><div><br></div><blockqu=
ote type=3D"cite"><div><span>______________________________________________=
_</span><br><span>Ranges mailing list</span><br><span><a href=3D"mailto:Ran=
ges@isocpp.open-std.org">Ranges@isocpp.open-std.org</a></span><br><span><a =
href=3D"http://www.open-std.org/mailman/listinfo/ranges">http://www.open-st=
d.org/mailman/listinfo/ranges</a></span><br></div></blockquote></body></htm=
l>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--Apple-Mail-01F0F9AC-3390-48AB-A9E7-C1CA6F7F8925--
.
Author: Sean Parent <sean_parent@mac.com>
Date: Thu, 24 Jan 2013 14:15:41 -0800
Raw View
--Boundary_(ID_pEKLBKO87eubuUINCkTyEQ)
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: quoted-printable
Sent from my iPad
On Jan 24, 2013, at 12:32 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>=20
>=20
> On Thursday, January 24, 2013 11:27:14 AM UTC-8, Tony V E wrote:
>>=20
>> On Thu, Jan 24, 2013 at 1:35 PM, Nevin Liber <ne...@eviloverlord.com> wr=
ote:=20
>> > On 24 January 2013 12:05, Olaf van der Spek <olafv...@gmail.com> wrote=
:=20
>> >>=20
>> >> On Thu, Jan 24, 2013 at 6:52 PM, Nevin Liber <ne...@eviloverlord.com>=
=20
>> >> wrote:=20
>> >> > That just moves the problem.=20
>> >>=20
>> >> Why? IMO it'd solve it.=20
>> >>=20
>> >> > It also means one cannot easily create a string_ref out of a=20
>> >> > vector<char>=20
>> >> > (since vector.data() is allowed to return nullptr).=20
>> >>=20
>> >> Why not?=20
>> >> It may just mean the resulting string_ref would be null.=20
>> >=20
>> >=20
>> > Because that is not what is meant by vector<char>, as it has doesn't m=
odel=20
>> > the nullable concept. For a typical implementation:=20
>> >=20
>> > vector<char> v;=20
>> > string_ref vnull(v.data(), v.size());=20
>> > v.reserve(1);=20
>> > string_ref vempty(v.data(), v.size());=20
>> >=20
>> > It is unexpected that vnull and vempty represent two different things,=
and=20
>> > that is only because of a side effect of the implementation.=20
>> > --=20
>> > Nevin ":-)" Liber <mailto:ne...@eviloverlord.com> (847) 691-1404=20
>> >=20
>>=20
>>=20
>> That's an interesting case, although I'm not sure it is important=20
>> enough to base decisions on.=20
>>=20
>> Let's take this one step beyond string_ref and consider ranges. - with=
=20
>> the assumption that string_ref should closely align with ranges. (I=20
>> mean we started with URIs, moved through optional to string_ref, why=20
>> stop there?)=20
>>=20
>> - In math, (with open-close interval notation) the interval (0,0) is=20
>> typically not considered the same as (1,1), although they are both=20
>> empty.=20
>>=20
>> - might ranges have a way to extend their range (extend_front(int) or=20
>> whatever)? So an empty range at the beginning of a string is not the=20
>> same as an empty range at the middle because once you extend by 1 you=20
>> get different ranges.=20
>>=20
>> basically, does a range devolve into a position? If so, empty ranges=20
>> are not all equivalent.=20
>>=20
>> Hmmmm, I actually haven't yet said anything about null ranges - just=20
>> various empties. ie ranges that point into empty regions of the=20
>> string, but nothing about ranges that don't point into the string at=20
>> all. Note that (end,end) can't be used as the "null range" - it=20
>> wouldn't solve the URI query case - it doesn't differentiate=20
>> "www.example.com/foo?" from "www.example.com/foo" as the query, in=20
>> both cases, would be (end, end).=20
>>=20
>>=20
>> Well, without moving to actual null vs empty, I'll just point out that=
=20
>> I think that=20
>>=20
>> (range1.empty() && range2.empty()) !=3D (range1 =3D=3D range2)=20
>>=20
>> And that the same should be true for string_ref,=20
>> And that that is at least one step towards string_ref having separate=20
>> concepts of null and empty.=20
>>=20
>> Tony
>=20
> No. Absolutely not. We already have a library facility for "nullable" obj=
ects. It's called `optional`. That's what should be used. Period. Trying to=
finangle some notion of "null string_ref" vs. "empty string_ref" via some =
kind of range nonsense would be exceedingly confusing to the user.
>=20
> Furthermore, `empty` for a "null string_ref" should return false. Because=
it's not empty; it doesn't exist.
I don't know much about string_ref but I would thin a null string ref would=
return the valid, and empty, range of [null, null).
Sean
> _______________________________________________
> Ranges mailing list
> Ranges@isocpp.open-std.org
> http://www.open-std.org/mailman/listinfo/ranges
--=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.
--Boundary_(ID_pEKLBKO87eubuUINCkTyEQ)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div><span></span></div><div><meta http=
-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8"><div><br><br=
>Sent from my iPad</div><div><br>On Jan 24, 2013, at 12:32 PM, Nicol Bolas =
<<a href=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.com</a>> wrot=
e:<br><br></div><blockquote type=3D"cite"><div><br><br>On Thursday, January=
24, 2013 11:27:14 AM UTC-8, Tony V E wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;">On Thu, Jan 24, 2013 at 1:35 PM, Nevin Liber <<a href=3D"j=
avascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"FzKTX6dbqwwJ">ne...@=
eviloverlord.com</a>> wrote:
<br>> On 24 January 2013 12:05, Olaf van der Spek <<a href=3D"javascr=
ipt:" target=3D"_blank" gdf-obfuscated-mailto=3D"FzKTX6dbqwwJ">olafv...@gma=
il.com</a>> wrote:
<br>>>
<br>>> On Thu, Jan 24, 2013 at 6:52 PM, Nevin Liber <<a href=3D"ja=
vascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"FzKTX6dbqwwJ">ne...@e=
viloverlord.com</a>>
<br>>> wrote:
<br>>> > That just moves the problem.
<br>>>
<br>>> Why? IMO it'd solve it.
<br>>>
<br>>> > It also means one cannot easily create a string_ref out o=
f a
<br>>> > vector<char>
<br>>> > (since vector.data() is allowed to return nullptr).
<br>>>
<br>>> Why not?
<br>>> It may just mean the resulting string_ref would be null.
<br>>
<br>>
<br>> Because that is not what is meant by vector<char>, as it has=
doesn't model
<br>> the nullable concept. For a typical implementation:
<br>>
<br>> vector<char> v;
<br>> string_ref vnull(v.data(), v.size());
<br>> v.reserve(1);
<br>> string_ref vempty(v.data(), v.size());
<br>>
<br>> It is unexpected that vnull and vempty represent two different thi=
ngs, and
<br>> that is only because of a side effect of the implementation.
<br>> --
<br>> Nevin ":-)" Liber <mailto:<a href=3D"javascript:" t=
arget=3D"_blank" gdf-obfuscated-mailto=3D"FzKTX6dbqwwJ">ne...@eviloverlord.=
<wbr>com</a>> (847) 691-1404
<br>>
<br>
<br>
<br>That's an interesting case, although I'm not sure it is important
<br>enough to base decisions on.
<br>
<br>Let's take this one step beyond string_ref and consider ranges. - with
<br>the assumption that string_ref should closely align with ranges. =
(I
<br>mean we started with URIs, moved through optional to string_ref, why
<br>stop there?)
<br>
<br>- In math, (with open-close interval notation) the interval (0,0) is
<br>typically not considered the same as (1,1), although they are both
<br>empty.
<br>
<br>- might ranges have a way to extend their range (extend_front(int) or
<br>whatever)? So an empty range at the beginning of a string is not =
the
<br>same as an empty range at the middle because once you extend by 1 you
<br>get different ranges.
<br>
<br>basically, does a range devolve into a position? If so, empty ran=
ges
<br>are not all equivalent.
<br>
<br>Hmmmm, I actually haven't yet said anything about null ranges - just
<br>various empties. ie ranges that point into empty regions of the
<br>string, but nothing about ranges that don't point into the string at
<br>all. Note that (end,end) can't be used as the "null range" - it
<br>wouldn't solve the URI query case - it doesn't differentiate
<br>"<a href=3D"http://www.example.com/foo" target=3D"_blank">www.example.c=
om/foo</a>?" from "<a href=3D"http://www.example.com/foo" target=3D"_blank"=
>www.example.com/foo</a>" as the query, in
<br>both cases, would be (end, end).
<br>
<br>
<br>Well, without moving to actual null vs empty, I'll just point out that
<br>I think that
<br>
<br> (range1.empty() && range2.empty()) !=3D (r=
ange1 =3D=3D range2)
<br>
<br>And that the same should be true for string_ref,
<br>And that that is at least one step towards string_ref having separate
<br>concepts of null and empty.
<br>
<br>Tony
<br></blockquote><div><br>No. Absolutely not. We already have a library fac=
ility for "nullable" objects. It's called `optional`. That's what should be=
used. Period. Trying to finangle some notion of "null string_ref" vs. "emp=
ty string_ref" via some kind of range nonsense would be exceedingly confusi=
ng to the user.<br><br>Furthermore, `empty` for a "null string_ref" should =
return <i>false</i>. Because it's not empty; it doesn't exist.<br></div>
</div></blockquote><div><br></div><div>I don't know much about string_ref b=
ut I would thin a null string ref would return the valid, and empty, range =
of [null, null).</div><div><br></div><div>Sean</div><div><br></div><blockqu=
ote type=3D"cite"><div><span>______________________________________________=
_</span><br><span>Ranges mailing list</span><br><span><a href=3D"mailto:Ran=
ges@isocpp.open-std.org">Ranges@isocpp.open-std.org</a></span><br><span><a =
href=3D"http://www.open-std.org/mailman/listinfo/ranges">http://www.open-st=
d.org/mailman/listinfo/ranges</a></span><br></div></blockquote></div></body=
></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
--Boundary_(ID_pEKLBKO87eubuUINCkTyEQ)--
.