dxml 0.2.0 released

Jonathan M Davis newsgroup.d at jmdavisprog.com
Thu Feb 15 02:40:03 UTC 2018


On Thursday, February 15, 2018 01:55:28 rikki cattermole via Digitalmars-d-
announce wrote:
> On 14/02/2018 5:13 PM, Jonathan M Davis wrote:
> > On Wednesday, February 14, 2018 14:09:21 rikki cattermole via
> > Digitalmars-d->
> > announce wrote:
> >> On 14/02/2018 2:02 PM, Adrian Matoga wrote:
> >>> On Wednesday, 14 February 2018 at 10:57:26 UTC, rikki cattermole 
wrote:
> >>>> See lines:
> >>>> - Input!IR temp = input;
> >>>> - input = temp;
> >>>>
> >>>>             bool commentLine() {
> >>>>
> >>>>          Input!IR temp = input;
> >>>>
> >>>> (...)
> >>>>
> >>>>          if (!temp.empty) {
> >>>>
> >>>> (...)
> >>>>
> >>>>              input = temp;
> >>>>              return true;
> >>>>
> >>>>          } else
> >>>>
> >>>>              return false;
> >>>>
> >>>>      }
> >>>
> >>> `temp = input.save` is exactly what you want here, which means forward
> >>> range is required. Your example won't work for range objects with
> >>> reference semantics.
> >>
> >> Ah I must be thinking of ranges that support indexing.
> >
> > Random access ranges are also forward ranges and would require a call to
> > save here.
> >
> > - Jonathan M Davis
>
> Luckily in my code I can forget that ;)

LOL. That's actually part of what makes writing range-based libraries so
much harder to get right than simply using ranges in your program. When a
piece of code is used with only a few types of ranges (or even only one type
of range, as is often the case), then it's generally not very hard to write
code that works just fine, but as soon as you have to worry about arbitrary
ranges, you get all kinds of nonsense that you have to worry about in order
to make sure that the code works correctly for any range that's passed to
it. save is the classic example of something that a lot of range-based code
gets wrong, because for most ranges, it really doesn't matter, but for those
ranges where it does, a single missed call to save results in code that
doesn't work properly. To get it right, you basically have to call save
every time you pass a range to a range-based function that is not supposed
to consume the range, and folks rarely get that right. Certainly, pretty
much any range-based code that doesn't have unit tests which include
reference-type ranges is going to be wrong for reference-type ranges. Even
Phobos has had quite a few issues with that historically.

- Jonathan M Davis



More information about the Digitalmars-d-announce mailing list