Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Input range + filter + chain => First element vanishes #9877

Closed
dlangBugzillaToGithub opened this issue Sep 20, 2024 · 1 comment
Closed

Comments

@dlangBugzillaToGithub
Copy link

qigezx+dc40d6nao940k reported this on 2024-09-20T12:56:08Z

Transfered from https://issues.dlang.org/show_bug.cgi?id=24774

Description

Chaining another range after a filtered input range omits the first element.

Minimal example:

import std.stdio;
import std.algorithm;
import std.range;

void main(){
	int i = 0;
	int gen(){
		return i++;
	}

	auto r1 = generate!gen.until!(x=> x>10);
	auto r2 = only(100);

	// Will print [7.8,9,10,100]
	// 6 is missing
	r1.filter!"a>5".chain(r2).writeln;

	// By adding "array" before chain, it will behave properly
	// [6,7,8,9,10,100]
	// r1.array.filter!"a>5".chain(r2).writeln;
	// r1.filter!"a>5".array.chain(r2).writeln;
}

>dmd --version
DMD64 D Compiler v2.109.1

Copyright (C) 1999-2024 by The D Language Foundation, All Rights Reserved written by Walter Bright

os: linux x64
@thewilsonator thewilsonator removed OS:Linux Issues specific to Linux Arch:x86_64 Issues specific to x86_64 P1 labels Dec 6, 2024
Inkrementator added a commit to Inkrementator/phobos that referenced this issue Feb 19, 2025
The constructor of the result of std.range.chain copies it's input tuple
and then has to check which of the input-ranges in the first non-empty
one. The member function empty is not guaranteed to be const, filter is
probably the most prominent function that has to be "primed". On the
first call to empty(), filter will try to advance all it's input ranges
to the first element that matches the predicate.
For ranges with full value semantics, using the old input object instead
of the new internal buffer means that the work of priming is done twice.
If any ranges have reference semantics, the references gets advances,
but the value-semantic parts of the range-composition gets reset.

This fixes dlang#10561 and dlang#9877
thewilsonator pushed a commit that referenced this issue Feb 19, 2025
The constructor of the result of std.range.chain copies it's input tuple
and then has to check which of the input-ranges in the first non-empty
one. The member function empty is not guaranteed to be const, filter is
probably the most prominent function that has to be "primed". On the
first call to empty(), filter will try to advance all it's input ranges
to the first element that matches the predicate.
For ranges with full value semantics, using the old input object instead
of the new internal buffer means that the work of priming is done twice.
If any ranges have reference semantics, the references gets advances,
but the value-semantic parts of the range-composition gets reset.

This fixes #10561 and #9877
@thewilsonator
Copy link
Contributor

Fixed by #10643

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants