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

bufio: Support empty final token from a SplitFunc #11836

Closed
spakin opened this issue Jul 23, 2015 · 2 comments
Closed

bufio: Support empty final token from a SplitFunc #11836

spakin opened this issue Jul 23, 2015 · 2 comments

Comments

@spakin
Copy link

spakin commented Jul 23, 2015

This is in reference to the golang-nuts thread How to return an empty final token from a bufio.SplitFunc.

Problem: It's not currently possible to write a "pure" bufio.SplitFunc function that either (a) returns an empty final token or (b) wants to discard all text beyond some point in the input stream. Instead, a package must implement a bufio.SplitFunc as a method on a state object, as in @robpike's demonstration of how to treat newlines as separators.

Proposed solution: Modify the implementation of Scanner.Scan to check the concrete type of the error returned by the bufio.SplitFunc function. If it's some sentinel value such as io.EOF or, say, a new bufio.EndOfScan, Scanner.Scan should store the returned token, as it does in the normal, non-error case, and return false. A subsequent scan could then continue reading the input stream from where the previous scan left off, making the proposed solution additionally useful for parsing a block of one token type followed by a block of a different token type. The proposed change to Scanner.Scan should not affect any existing code, especially if a new Error type like bufio.EndOfScan is used as the sentinel.

— Scott

@robpike robpike added this to the Go1.6 milestone Jul 23, 2015
@robpike
Copy link
Contributor

robpike commented Jul 23, 2015

Needs to be thought about carefully but I observe that the test case in scan_test.go for this will loop forever if the explicit counter is removed from the loop.

@robpike robpike modified the milestones: Go1.6Early, Go1.6 Aug 26, 2015
@gopherbot
Copy link

CL https://golang.org/cl/14924 mentions this issue.

@golang golang locked and limited conversation to collaborators Sep 27, 2016
@rsc rsc unassigned robpike Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants