Tricky semantics of ranges & potentially numerous Phobos bugs

deadalnix deadalnix at gmail.com
Tue Oct 16 08:45:01 PDT 2012


Le 16/10/2012 15:30, H. S. Teoh a écrit :
> On Mon, Oct 15, 2012 at 10:59:26PM -0700, Jonathan M Davis wrote:
>> On Monday, October 15, 2012 22:48:15 Jonathan M Davis wrote:
>>> So, I don't really know what the right answer is, but I _really_
>>> don't like the idea of having to worry about the result of front
>>> changing after a call to popFront in every single function that ever
>>> uses front. In the general case, I just don't see how that's
>>> tenable. I'd _much_ rather that it be up to the programmer using
>>> abnormal ranges such as ByLine to use them correctly.
>>
>> And actually, it seems to me that issues like this make it look like
>> it was a mistake to make ranges like ByLine ranges in the first place.
>> They should have just defined opApply so that they'd work nicely in
>> foreach but not with range- based functions. They're clearly not going
>> to work with a _lot_ of range-based functions.
> [...]
>
> But nothing about the definition of a range, as currently defined in
> std.range, guarantees that whatever value was returned by .front is
> still valid after popFront() is called.
>
> I'm not saying that this should be the "correct" behaviour, but the
> current definition does not prohibit a range from, say, reusing an array
> to compute its next element. For example, one may have a range that
> returns the permutations of a given array, in which popFront() permutes
> the elements in-place. In this case, .front will become invalid once
> popFront() is called. Many of the current range-based functions will not
> work correctly in this case.
>
> Of course, it's arguable whether such ranges should be admissible, but
> as far as the current definition goes, I don't see anything that states
> otherwise. If we don't make such things clear, then we're bound to run
> into pathological cases where bugs will creep in because of unstated
> assumptions in the code.
>
>
> T
>

The default semantic should be the safe one.

Providing backdoor for experienced developer is useful, but it does arm 
as default behavior.


More information about the Digitalmars-d mailing list