er.com
--- Comment #1 from Jack Stouffer <j...@jackstouffer.com> ---
This issue doesn't just apply to ranges of char or wchar. Consider
import std.utf;
import std.conv;
void main()
{
auto res = "1234567".byDchar.to!int; // fails
auto res2 = "1234567".byDc
https://issues.dlang.org/show_bug.cgi?id=15800
Issue ID: 15800
Summary: std.conv.to!int does not work with ranges of char or
wchar
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
On Thursday, 8 May 2014 at 17:46:06 UTC, Andrei Alexandrescu
wrote:
A discussion is building around
https://github.com/D-Programming-Language/phobos/pull/2149,
which is a nice initiative by Walter to allow Phobos users to
avoid or control memory allocation.
First instance of the pull request
On Thursday, 8 May 2014 at 21:38:12 UTC, Andrei Alexandrescu
wrote:
Interesting. So then the range returned by format() will save
everything passed to it, which means...
int fun(int[] a)
{
auto before = format(Before: %s, a);
foreach (ref e; a) ++e;
auto after = format(After: %s, a);
On 08/05/14 23:33, Walter Bright wrote:
It's true that when I first encountered C#'s LINQ, I was surprised that
it was lazy.
It's also true that most of std.algorithm is lazy. Apart from coming up
with a new naming convention (and renaming algorithms in Phobos), I
don't see any obvious
On Thursday, 8 May 2014 at 22:27:11 UTC, Luís Marques wrote:
(I guess that's one
drawback of providing functional programming without
immutability?)
Another issue is iteration might be not repeatable, especially if
a closure accidentally slips into the range. In C# iteration is
not
A discussion is building around
https://github.com/D-Programming-Language/phobos/pull/2149, which is a
nice initiative by Walter to allow Phobos users to avoid or control
memory allocation.
First instance of the pull request copied the inputs into an output range.
The second instance (right
On Thu, May 08, 2014 at 10:46:12AM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
A discussion is building around
https://github.com/D-Programming-Language/phobos/pull/2149, which is a
nice initiative by Walter to allow Phobos users to avoid or control
memory allocation.
First
On 5/8/2014 10:46 AM, Andrei Alexandrescu wrote:
A discussion is building around
https://github.com/D-Programming-Language/phobos/pull/2149, which is a nice
initiative by Walter to allow Phobos users to avoid or control memory
allocation.
The setExtension() function is itself not very
On Thu, May 08, 2014 at 11:27:54AM -0700, Walter Bright via Digitalmars-d wrote:
On 5/8/2014 10:46 AM, Andrei Alexandrescu wrote:
A discussion is building around
https://github.com/D-Programming-Language/phobos/pull/2149, which is a nice
initiative by Walter to allow Phobos users to avoid or
On 5/8/2014 1:46 PM, Andrei Alexandrescu wrote:
However output range means the string operation will be done eagerly,
whereas lazy has advantages (nice piping, saving on work etc).
Isn't eagerness what we have array() for?
Also, while naming is often just bikeshedding, in this case I think
On 5/8/2014 10:46 AM, Andrei Alexandrescu wrote:
However output range means the string operation will be done eagerly, whereas
lazy has advantages (nice piping, saving on work etc).
The lazy vs eager issue seems at first blush to be an esoteric, potayto-potahto
bikeshed.
But I think it's
On 5/8/2014 11:19 AM, H. S. Teoh via Digitalmars-d wrote:
In case 1, the user has to manually create various intermediate buffers
to store intermediate results. I used a trivial example here, but in
application code, the processing you need is usually far more complex.
This means creating lots
On 5/8/2014 2:19 PM, H. S. Teoh via Digitalmars-d wrote:
This way, you maximize the usability of the function -- it can
participate in UFCS chains, compose with other std.algorithm functions,
etc..
I think that actually raises an issue worth considering. I posit that
the results of an
On 5/8/2014 2:46 PM, Walter Bright wrote:
But to make a lazy version from an eager one means reimplementing it.
Or yield()-ing inside the eager one's sink.
And note also there is such as thing as a stackless fiber, so I'm not
certain a full-fledged context-switching fiber would necessarily
On Thursday, 8 May 2014 at 17:46:06 UTC, Andrei Alexandrescu
wrote:
A discussion is building around
https://github.com/D-Programming-Language/phobos/pull/2149,
which is a nice initiative by Walter to allow Phobos users to
avoid or control memory allocation.
First instance of the pull request
On 5/8/2014 12:22 PM, Nick Sabalausky wrote:
On 5/8/2014 2:46 PM, Walter Bright wrote:
But to make a lazy version from an eager one means reimplementing it.
Or yield()-ing inside the eager one's sink.
The data is still supplied to it.
On Thursday, 8 May 2014 at 18:21:32 UTC, H. S. Teoh via
Digitalmars-d wrote:
I've thought about input ranges vs. output ranges for a bit. I
think it
doesn't make sense for functions that process data to take an
output
range: output ranges are data sinks, and should only be used
for the
On 5/8/14, 11:27 AM, Walter Bright wrote:
On 5/8/2014 10:46 AM, Andrei Alexandrescu wrote:
A discussion is building around
https://github.com/D-Programming-Language/phobos/pull/2149, which is a
nice
initiative by Walter to allow Phobos users to avoid or control memory
allocation.
The
On 5/8/2014 2:20 PM, Andrei Alexandrescu wrote:
Some may be surprised that auto c = setExtension(a, b) doesn't actually just do
it. So changing a and/or b before using c would yield surprising result for
someone coming from a background of eager-string languages.
It's true that when I first
On 5/8/14, 1:41 PM, Luís Marques l...@luismarques.eu wrote:
On Thursday, 8 May 2014 at 18:21:32 UTC, H. S. Teoh via
Digitalmars-d wrote:
I've thought about input ranges vs. output ranges for a bit. I think it
doesn't make sense for functions that process data to take an output
range: output
On Thu, May 08, 2014 at 02:38:18PM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
On 5/8/14, 1:41 PM, Luís Marques l...@luismarques.eu wrote:
On Thursday, 8 May 2014 at 18:21:32 UTC, H. S. Teoh via
Digitalmars-d wrote:
I've thought about input ranges vs. output ranges for a bit. I
On Thu, May 08, 2014 at 02:54:32PM -0700, H. S. Teoh via Digitalmars-d wrote:
On Thu, May 08, 2014 at 02:38:18PM -0700, Andrei Alexandrescu via
Digitalmars-d wrote:
On 5/8/14, 1:41 PM, Luís Marques l...@luismarques.eu wrote:
[...]
I agree with H. S. Teoh. Indeed, I was thinking of trying to
On Thursday, 8 May 2014 at 21:38:12 UTC, Andrei Alexandrescu
wrote:
int fun(int[] a)
{
auto before = format(Before: %s, a);
foreach (ref e; a) ++e;
auto after = format(After: %s, a);
writeln(before, \n---\n, after);
}
*ouch*
You might think that's bad, but there's nothing in that
On 5/8/14, 10:46 AM, Andrei Alexandrescu wrote:
[snip]
Here's a list of algorithms in std.algorithm that would need to be
looked at if we want to handle ranges of char and wchar properly (at
least versions with predicates). When I say looked at I mean modified
appropriately to handle ranges
On 5/8/14, 3:33 PM, Andrei Alexandrescu wrote:
Of these, only a fraction (maybe 60-70%) are actually used with strings.
Still that leaves a significant amount of work to do if we want
std.algorithm to work smoothly with ranges of char/wchar. Here
smoothly means if it compiles and runs it won't
On 5/8/2014 4:13 PM, Walter Bright wrote:
8/2014 12:22 PM, Nick Sabalausky wrote:
On 5/8/2014 2:46 PM, Walter Bright wrote:
But to make a lazy version from an eager one means reimplementing it.
Or yield()-ing inside the eager one's sink.
The data is still supplied to it.
I think I've
On 5/8/2014 4:24 PM, Nick Sabalausky wrote:
On 5/8/2014 4:13 PM, Walter Bright wrote:
8/2014 12:22 PM, Nick Sabalausky wrote:
On 5/8/2014 2:46 PM, Walter Bright wrote:
But to make a lazy version from an eager one means reimplementing it.
Or yield()-ing inside the eager one's sink.
The
Classification of functions in http://dlang.org/phobos/std_path.html:
1. Functions that allocate GC memory and return an array:
dirName, setExtension, defaultExtension, buildPath, buildNormalizedPath,
absolutePath, relativePath, expandTilde
These are prime candidates to be converted into
29 matches
Mail list logo
