I have commented to the pull.
I don't like adding convenient interfaces to std.format module.
https://github.com/D-Programming-Language/phobos/pull/777#issuecomment-8385551
Kenji Hara
2012/9/8 monarch_dodra monarchdo...@gmail.com:
On Friday, 7 September 2012 at 15:34:12 UTC, monarch_dodra
2012/9/8 monarch_dodra monarchdo...@gmail.com:
[snip]
Still, I find it horrible to have to create a named dummy variable just
when I simply want to pass a copy of my range.
Why you are afraid to declaring dummy variable?
formattedRead is a parser, not an algorithm (as I said in the pull
On Saturday, 8 September 2012 at 12:10:26 UTC, kenji hara wrote:
2012/9/8 monarch_dodra monarchdo...@gmail.com:
[snip]
Still, I find it horrible to have to create a named dummy
variable just
when I simply want to pass a copy of my range.
Why you are afraid to declaring dummy variable?
On Saturday, 8 September 2012 at 12:10:26 UTC, kenji hara wrote:
2012/9/8 monarch_dodra monarchdo...@gmail.com:
[snip]
Still, I find it horrible to have to create a named dummy
variable just
when I simply want to pass a copy of my range.
Why you are afraid to declaring dummy variable?
On Thu, 23 Aug 2012 07:33:13 -0400, monarch_dodra monarchdo...@gmail.com
wrote:
As title implies:
import std.stdio;
import std.format;
void main()
{
string s = 42;
int v;
formattedRead(s, %d, v);
writefln([%s] [%s], s, v);
}
[] [42]
Is this the expected behavior?
On Friday, 7 September 2012 at 13:58:43 UTC, Steven Schveighoffer
wrote:
On Thu, 23 Aug 2012 07:33:13 -0400, monarch_dodra
The only issue is, what if you *do* want ref behavior for
strings? You would need to wrap the string into a ref'd range.
That is not a good proposition. Unfortunately,
On Fri, 07 Sep 2012 10:35:37 -0400, monarch_dodra monarchdo...@gmail.com
wrote:
On Friday, 7 September 2012 at 13:58:43 UTC, Steven Schveighoffer wrote:
On Thu, 23 Aug 2012 07:33:13 -0400, monarch_dodra
The only issue is, what if you *do* want ref behavior for strings? You
would need to
On Friday, September 07, 2012 10:52:07 Steven Schveighoffer wrote:
We have three situations:
1. input range is a ref type already (i.e. a class or a pImpl struct), no
need to pass this by ref, just wastes cycles doing double dereference.
2. input range is a value type, and you want to
On Friday, 7 September 2012 at 14:51:45 UTC, Steven Schveighoffer
wrote:
On Fri, 07 Sep 2012 10:35:37 -0400, monarch_dodra
This looks ugly. Returning a tuple and having to split the
result is horrible, I hated dealing with that in C++ (and I
even wrote stuff that returned pairs!)
Not only
On Friday, 7 September 2012 at 15:34:12 UTC, monarch_dodra wrote:
I think this is a good solution. Do you see anything I may have
failed to see?
I've made a pull request out of it.
https://github.com/D-Programming-Language/phobos/pull/777
On Fri, 07 Sep 2012 11:04:36 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Friday, September 07, 2012 10:52:07 Steven Schveighoffer wrote:
We have three situations:
1. input range is a ref type already (i.e. a class or a pImpl struct),
no
need to pass this by ref, just wastes
On Fri, 07 Sep 2012 11:34:28 -0400, monarch_dodra monarchdo...@gmail.com
wrote:
On Friday, 7 September 2012 at 14:51:45 UTC, Steven Schveighoffer wrote:
On Fri, 07 Sep 2012 10:35:37 -0400, monarch_dodra
This looks ugly. Returning a tuple and having to split the result is
horrible, I
On Friday, 7 September 2012 at 18:15:00 UTC, Steven Schveighoffer
wrote:
Well, this does work. But I don't like that the semantics
depend on whether the value is an rvalue or not.
Note that even ranges that are true input ranges (i.e. a file)
still consume their data, even as rvalues,
On Thursday, 23 August 2012 at 11:33:19 UTC, monarch_dodra wrote:
As title implies:
import std.stdio;
import std.format;
void main()
{
string s = 42;
int v;
formattedRead(s, %d, v);
writefln([%s] [%s], s, v);
}
[] [42]
Is this the expected behavior?
Yes, both parse
On Friday, 24 August 2012 at 11:18:55 UTC, Dmitry Olshansky wrote:
On Thursday, 23 August 2012 at 11:33:19 UTC, monarch_dodra
wrote:
I've traced the root issue to formattedRead's signature, which
is:
uint formattedRead(R, Char, S...)(ref R r, const(Char)[] fmt,
S args);
As I explained
24.08.2012 16:16, monarch_dodra пишет:
On Friday, 24 August 2012 at 11:18:55 UTC, Dmitry Olshansky wrote:
On Thursday, 23 August 2012 at 11:33:19 UTC, monarch_dodra wrote:
I've traced the root issue to formattedRead's signature, which is:
uint formattedRead(R, Char, S...)(ref R r,
On Friday, 24 August 2012 at 11:18:55 UTC, Dmitry Olshansky wrote:
C's scanf is a poor argument as it uses pointers instead of ref
(and it can't do ref as there is no ref in C :) ). Yet it
doesn't allow to read things in a couple of calls AFAIK. In C
scanf returns number of arguments
On Friday, 24 August 2012 at 13:08:43 UTC, Denis Shelomovskij
wrote:
24.08.2012 16:16, monarch_dodra пишет:
On Friday, 24 August 2012 at 11:18:55 UTC, Dmitry Olshansky
wrote:
On Thursday, 23 August 2012 at 11:33:19 UTC, monarch_dodra
wrote:
I've traced the root issue to formattedRead's
On 24-Aug-12 17:43, Tove wrote:
On Friday, 24 August 2012 at 11:18:55 UTC, Dmitry Olshansky wrote:
C's scanf is a poor argument as it uses pointers instead of ref (and
it can't do ref as there is no ref in C :) ). Yet it doesn't allow to
read things in a couple of calls AFAIK. In C scanf
As title implies:
import std.stdio;
import std.format;
void main()
{
string s = 42;
int v;
formattedRead(s, %d, v);
writefln([%s] [%s], s, v);
}
[] [42]
Is this the expected behavior?
Furthermore, it is not possible to try to save s:
import std.stdio;
import
20 matches
Mail list logo
