Optional pass by value for formattedRead #777

Closed
wants to merge 1 commit into
from

Projects

None yet

2 participants

@monarchdodra
Collaborator

D2 test results for 764

Per http://forum.dlang.org/thread/fvcjygswtrfxqtffmdef@forum.dlang.org

This gives an non-pass-by-ref overload to formattedRead, so that it can take r-value arguments.

The goal is to allow calls to formatted read directly from save'd ranges, or from the output of other functions, without forcing the developer to storing them in a named (dummy) temporary (groan).

This change, AFAIK, should have zero impact on existing code.

The example code was added upon, as well as duplicated in a unittest to validate documentation.

PS: The approach to using an overload should be superior to using "auto-ref", as it doesn't duplicate the compiled payload of the main template... I think... but I'm not 100% certain of the mechanics behind auto ref...

@monarchdodra @monarchdodra monarchdodra Pass by value for formattedRead
To bind to R-Values. Added unit test.
28de877
@9rnsr
Member
9rnsr commented Sep 8, 2012

I'm against to this pull request.
This is a convenient enhancement. It would introduce no new features, but just provides an convenient notation.

First, formattedRead is a (poor) parser, not an algorithm. So in theory, it would consume the input, and would return the rest.
After all, it is a design of formattedRead that receives only lvalue value with ref.

Next, std.format module is designed as providing utilities which for the library writers to implement writef compatible formatting features, in my opinion. In Phobos, writef(ln), readf, BigInt.toString use std.format. Therefore, formattedWrite and formattedRead should have just flexible interfaces for the library makers, not provide convenient interfaces for the end-user programmers.

@monarchdodra
Collaborator

Well, at this point, it is not about "consume the input or not" anymore, it is just about allow this:
formattedRead(s.save, "%s", &v);
To compile. This seems like a sensible request to me, for both library implementers and end user programmers.
I don't see why it would be a "design" to accept only lvalues?

You say the function is not to provide for "end-users", but what else should a end user call? This is an actual question, you make it sound like there is an alternative, and I'd like to know it.
I asked the question here:
http://forum.dlang.org/thread/ianoqmaginhqrosavsqw@forum.dlang.org
Thanks for having taken the time to review I am listening to what you are saying.

@monarchdodra
Collaborator

Closing request per discussion.

@monarchdodra monarchdodra referenced this pull request Jun 5, 2013
Closed

Fixed issue #10019 #1282

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