Review the Ranges chapter

[acehreli]

Andrew says:

My main purpose for contacting you today is that my experience differs form your explanation of what happens to elements of ranges. In the "Iterating by shortening" section of chapter 81 you provide a demonstration of an array being shortened during iteration. In your very next example, you demonstrate how to avoid data loss using an alias to the original data. This becomes the basis for all further discussion on ranges with the assertion that all ranges must explicitly protect agains data lost.

In the "InputRange Example" section, the first full implementation of a range appears and while it demonstrates the versatility of ranges it does not show that data was actually lost... so all further discussion of data loss is still based on the earlier example of slicing.

Finally, in "Ranges without actual elements" you discuss how to guard against data lost. So far so good. Except this is the section that catches my eye. Here you explicitly assert that the student length did not change. So I found myself asking why didn't you do that before when you first implemented the range? Having gone back and make the assertion myself, it turns out that no data was lost. This lead me to believe that something had change in the compiler so I switch form 2.074.1 to 2.060.0 with no difference in result. Then I implemented a different range trying to achieve the same result as you but ultimately failed. The only time that I could get the same result was when passing a pure string to print(). Please observe:

struct Kanji { string data;

this(string str) { this.data = str; } @property bool empty() const { return data.length == 0; }

@property auto ref front() { return data.front; }

void popFront() { data.popFront(); } }

void main() { Kanji kanji = Kanji("これは素晴らしいです。自分で作ったんですか？"); auto length = kanji.data.length; print(kanji); foreach (moji; kanji) { writeln(moji); } assert(kanji.data.length == length); }

So my question is basically this, can this feature/misfeature be relied upon? Can you please demonstrate other instances in which the data is lost because currently the only one I have seen and can produce is with a pure string.