Topic: ranges, string_ref, A URI Library for C++
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 24 Jan 2013 14:27:14 -0500
Raw View
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
--
---
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.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 24 Jan 2013 12:32:03 -0800 (PST)
Raw View
------=_Part_11_12358366.1359059523915
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, January 24, 2013 11:27:14 AM UTC-8, Tony V E wrote:
>
> On Thu, Jan 24, 2013 at 1:35 PM, Nevin Liber <ne...@eviloverlord.com<javascript:>>
> wrote:
> > On 24 January 2013 12:05, Olaf van der Spek <olafv...@gmail.com<javascript:>>
> wrote:
> >>
> >> On Thu, Jan 24, 2013 at 6:52 PM, Nevin Liber <ne...@eviloverlord.com<javascript:>>
>
> >> 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:ne...@eviloverlord.com <javascript:>>
> (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
>
No. Absolutely not. We already have a library facility for "nullable"
objects. 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.
Furthermore, `empty` for a "null string_ref" should return *false*. Because
it's not empty; it doesn't exist.
--
---
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_11_12358366.1359059523915
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Thursday, January 24, 2013 11:27:14 AM UTC-8, Tony V E wrote:<bl=
ockquote 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 1:35 PM, =
Nevin Liber <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=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>
<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 />
------=_Part_11_12358366.1359059523915--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 24 Jan 2013 16:32:16 -0500
Raw View
On Thu, Jan 24, 2013 at 3:32 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> No. Absolutely not. We already have a library facility for "nullable"
> objects. It's called `optional`. That's what should be used. Period.
I'm not sure optional will be the best answer for all cases. Sounds
like nullable or optional is a concept with a number of
implementations (NaN, pointers, EOF,...). Some of those may be seen
as hacks, however.
> 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.
>
You may be right. I'm just trying to explore both sides. There is at
least the advantage that a nullable string_ref is likely 'free' (not
requiring extra memory beyond what the implementation already needs).
Also, is null a state that a string_ref can get in? Or will we make
it impossible (ie throw in the constructor, etc)? If it is not
impossible, how do I tell if I have one? (size() == 0 && empty() ==
false) ?
> Furthermore, `empty` for a "null string_ref" should return false. Because
> it's not empty; it doesn't exist.
>
Philosophically, I may agree. However, I expect that might cause
crashes. if ( ! strref.empty() ) use_it(strref); ....
It might be more pragmatic to have it return true.
I think the real question is whether a "null string_ref" is ever
allowed to occur. Can we prevent it (if that's what we want?) What
is the cost? Or do we just make it undefined behaviour?
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.
.