Hi guys.
Thank for the comments.
Nice to know that someone have had the D-Cassandra combo working.
Knud
On Thursday, 5 July 2012 at 06:27:55 UTC, Walter Bright wrote:
On 7/4/2012 10:22 PM, Jonathan M Davis wrote:
On Wednesday, July 04, 2012 21:46:29 Walter Bright wrote:
It would be nice to have a D source code formatter. But it
needs a champion.
Who's up for it?
Doesn't that need a lexer and p
On 07/05/2012 01:26 AM, Jonathan M Davis wrote:
I wonder how the results look on gdc when using the improved popFront, given
how surprising they were with consumeFront.
Improved popFront, gdc as before (-frelease -finline-functions -fweb -O3):
ascii 22.69%: old [2 secs, 449 ms, 248 μs, and 7
On 7/4/2012 10:22 PM, Jonathan M Davis wrote:
On Wednesday, July 04, 2012 21:46:29 Walter Bright wrote:
It would be nice to have a D source code formatter. But it needs a champion.
Who's up for it?
Doesn't that need a lexer and parser for D first (which I'd _love_ to do but
just haven't had ti
Hi,
My test code:
> import std.stdio;
> void main() {
> void delegate()[] functions;
> foreach (i; 0 .. 5) {
> functions ~= {
> printf("%d\n", i);
> };
}
> foreach (func; functions) {
> func();
> }
> }
output:
$ dmd
DMD64 D Compiler v2
On Thursday, July 05, 2012 00:04:03 Andrei Alexandrescu wrote:
> On 7/4/12 10:11 PM, Jonathan M Davis wrote:
> > On Wednesday, July 04, 2012 21:33:31 Andrei Alexandrescu wrote:
> >> Great. Could you please post some code so we play with it? Thanks.
> >
> > Okay. You can use this:
> [snip]
>
> Tha
On Wednesday, July 04, 2012 21:46:29 Walter Bright wrote:
> It would be nice to have a D source code formatter. But it needs a champion.
> Who's up for it?
Doesn't that need a lexer and parser for D first (which I'd _love_ to do but
just haven't had time to get around to)?
- Jonathan M Davis
On 7/5/12 12:46 AM, Walter Bright wrote:
It would be nice to have a D source code formatter. But it needs a
champion. Who's up for it?
Yes please.
Andrei
It would be nice to have a D source code formatter. But it needs a champion.
Who's up for it?
On 7/4/12 10:11 PM, Jonathan M Davis wrote:
On Wednesday, July 04, 2012 21:33:31 Andrei Alexandrescu wrote:
Great. Could you please post some code so we play with it? Thanks.
Okay. You can use this:
[snip]
Thanks. I made the following change to popFront:
@trusted void popFront(A)(ref A a)
i
On Wednesday, July 04, 2012 23:53:35 Ed McCardell wrote:
> On 07/04/2012 10:11 PM, Jonathan M Davis wrote:
> > Just adjust the strings to try different strings, and adjust then number
> > of
> > iterations if you need to. It prints out a two lines looking like:
> >
> > ascii 82.89%: old [5 secs,
On 07/04/2012 10:11 PM, Jonathan M Davis wrote:
Just adjust the strings to try different strings, and adjust then number of
iterations if you need to. It prints out a two lines looking like:
ascii 82.89%: old [5 secs, 176 ms, 602 μs, and 8 hnsecs], new [4 secs, 290
ms, 683 μs, and 6 hnsecs]
un
On Wednesday, July 04, 2012 21:33:31 Andrei Alexandrescu wrote:
> Great. Could you please post some code so we play with it? Thanks.
Okay. You can use this:
--
import std.array;
import std.conv;
import std.datetime;
import std.range;
import std.stdio;
import std.string;
import std.traits;
On 7/4/12 3:19 PM, Jonathan M Davis wrote:
In theory all of these redundant operations can be done away with
optimization techniques, but probably some aren't. So we should look
first at optimizing this flow heavily before looking at an API addition
that has disadvantages in other dimensions.
T
On Wednesday, 4 July 2012 at 11:18:36 UTC, Iain Buclaw wrote:
On 4 July 2012 11:52, Jacob Carlborg wrote:
On 2012-07-04 02:34, Jonathan M Davis wrote:
On Wednesday, July 04, 2012 00:42:22 Iain Buclaw wrote:
Just so long as it isn't Gentoo. :o)
Afterall, out of all of the linux distros out
Regardless of what the final result of this discussion is, I must say that I
think that it manages to nicely highlight the benefits of discussing designs
before actually incorporating them into Phobos (or any major project). There
have been some good suggestions in this thread. The reviews for n
Another option would be to create a wrapper range for strings to be used when
they already have to be wrapped in another range. Functions which want to make
string processing more efficient can already specialize on strings (and often
do), so they can deal with the consumeFront issue directly if
On Thursday, July 05, 2012 00:03:02 Timon Gehr wrote:
> On 07/04/2012 11:53 PM, deadalnix wrote:
> > Le 04/07/2012 20:40, Jonathan M Davis a écrit :
> >> On Wednesday, July 04, 2012 12:55:44 Tobias Pankrath wrote:
> Many languages does this (it doesn't mean it is the right thing
> to do).
On Wednesday, July 04, 2012 23:56:33 RivenTheMage wrote:
> > The problem is that while in most cases, separating getting the
> > element referred to by the iterator (or the front of the range)
> > separately
> > from iterating is more efficient than having the iterator
> > return an element when
>
On 07/04/2012 11:53 PM, deadalnix wrote:
Le 04/07/2012 20:40, Jonathan M Davis a écrit :
On Wednesday, July 04, 2012 12:55:44 Tobias Pankrath wrote:
Many languages does this (it doesn't mean it is the right thing
to do). Do you know why this shouldn't be done ?
In C++ it was exception safety,
Le 04/07/2012 21:45, Jonathan M Davis a écrit :
On Wednesday, July 04, 2012 12:19:15 Jonathan M Davis wrote:
But at present, I'm seeing a performance improvement of approximately 70 -
80% in iterating over strings with consumeFront rather than front and
popFront (depending on the compiler flags
Le 04/07/2012 22:34, Tobias Pankrath a écrit :
Yes. But the cost of copying the value and the cost of the exception are
separate.
The argument is not about performance, it's about loosing values.
If you implement popFront as
{
popFront(); // current popFront
return front
The problem is that while in most cases, separating getting the
element referred to by the iterator (or the front of the range)
separately
from iterating is more efficient than having the iterator
return an element when
you iterate it
Yes, but iterators don't need that separation at all. AFAI
Le 04/07/2012 20:40, Jonathan M Davis a écrit :
On Wednesday, July 04, 2012 12:55:44 Tobias Pankrath wrote:
Many languages does this (it doesn't mean it is the right thing
to do). Do you know why this shouldn't be done ?
In C++ it was exception safety, wasn't it?
I believe that it was purely
On 7/4/2012 7:19 AM, Iain Buclaw wrote:
Morning,
I've noticed that 256bit vector support has been added to the D frontend during
the development stages of 2.060 whilst was looking around in druntime core.
https://github.com/D-Programming-Language/druntime/commit/fcc91588e89fa48b699f0efe0cdfb8c2
On Wednesday, July 04, 2012 21:39:00 Mehrdad wrote:
> IMO the root cause of this problem is something else.
>
>
> The problem is that we're trying to use slices as ranges, and
> they don't fit in the model.
>
> e.g.: If you're using immutable(char)[] to represent a string,
> you're /going/ to ru
On Wednesday, July 04, 2012 22:26:16 RivenTheMage wrote:
> > Currently I think that idea was very bad, given that it would
> > be difficult to find all ranges which invalidate previous front
> > value on popFront.
>
> It seems, consumeFront() is attempt to implement a forward
> iterator on top of
On Wednesday, July 04, 2012 22:34:46 Tobias Pankrath wrote:
> > Yes. But the cost of copying the value and the cost of the
> > exception are
> > separate.
>
> The argument is not about performance, it's about loosing values.
>
> > Simply popping off the element could throw an exception (in the
>
Yes. But the cost of copying the value and the cost of the
exception are
separate.
The argument is not about performance, it's about loosing values.
Simply popping off the element could throw an exception (in the
case
of strings in D, you'll get a UTFException if the string is
malformed). S
Currently I think that idea was very bad, given that it would
be difficult to find all ranges which invalidate previous front
value on popFront.
It seems, consumeFront() is attempt to implement a forward
iterator on top of a range. Maybe the problem is mixing up two
different abstractions.
On Wednesday, July 04, 2012 22:10:36 Tobias Pankrath wrote:
> On Wednesday, 4 July 2012 at 18:40:50 UTC, Jonathan M Davis wrote:
> > On Wednesday, July 04, 2012 12:55:44 Tobias Pankrath wrote:
> >> > Many languages does this (it doesn't mean it is the right
> >> > thing
> >> > to do). Do you know w
On Wednesday, 4 July 2012 at 18:40:50 UTC, Jonathan M Davis wrote:
On Wednesday, July 04, 2012 12:55:44 Tobias Pankrath wrote:
> Many languages does this (it doesn't mean it is the right
> thing
> to do). Do you know why this shouldn't be done ?
In C++ it was exception safety, wasn't it?
I b
On Wednesday, July 04, 2012 12:19:15 Jonathan M Davis wrote:
> But at present, I'm seeing a performance improvement of approximately 70 -
> 80% in iterating over strings with consumeFront rather than front and
> popFront (depending on the compiler flags and strings used).
I should clarify that. It
IMO the root cause of this problem is something else.
The problem is that we're trying to use slices as ranges, and
they don't fit in the model.
e.g.: If you're using immutable(char)[] to represent a string,
you're /going/ to run into problems like this (like we already
have).
The right t
On Wednesday, July 04, 2012 11:17:53 Andrei Alexandrescu wrote:
> On 7/4/12 8:33 AM, deadalnix wrote:
> > Le 04/07/2012 13:04, Roman D. Boiko a écrit :
> >> On Wednesday, 4 July 2012 at 10:54:41 UTC, deadalnix wrote:
> >>> I do agree with that. However, the current proposal have the same
> >>> draw
On Wednesday, July 04, 2012 06:42:32 Ed McCardell wrote:
> On 07/04/2012 04:50 AM, Jonathan M Davis wrote:
> > But reducing code was never my concern (nor Dmitry's in considering
> > proposing essentially the same thing). It's efficiency that's the problem
> > - particularly with strings. IIRC, wit
On Wednesday, July 04, 2012 12:55:44 Tobias Pankrath wrote:
> > Many languages does this (it doesn't mean it is the right thing
> > to do). Do you know why this shouldn't be done ?
>
> In C++ it was exception safety, wasn't it?
I believe that it was purely a question of speed. If popFront returns
On 02/07/12 18:57, kenji hara wrote:
D does not provide index for the range iteration.
Instead, you can create 'zipped' range.
Oh, cool. That's a nice feature that I can think of other uses for ... :-)
On 02/07/12 18:43, bearophile wrote:
It's not a bug, it's caused by how ranges like retro work. retro yields a single
item. In D you can't overload on return values, so foreach can't try to call a
second retro.front overload that yields an (index,item) tuple (that later
foreach is able to unpack
Le 04/07/2012 17:17, Andrei Alexandrescu a écrit :
On 7/4/12 8:33 AM, deadalnix wrote:
Le 04/07/2012 13:04, Roman D. Boiko a écrit :
On Wednesday, 4 July 2012 at 10:54:41 UTC, deadalnix wrote:
I do agree with that. However, the current proposal have the same
drawback but on the code that use t
On 7/4/12 8:33 AM, deadalnix wrote:
Le 04/07/2012 13:04, Roman D. Boiko a écrit :
On Wednesday, 4 July 2012 at 10:54:41 UTC, deadalnix wrote:
I do agree with that. However, the current proposal have the same
drawback but on the code that use the range.
Both solutions are messy IMO.
What is e
Code:
https://github.com/D-Programming-Language/phobos/pull/646
Docs:
http://dl.dropbox.com/u/24218791/d/phobos/std_hash_hash.html
http://dl.dropbox.com/u/24218791/d/phobos/std_hash_crc.html
http://dl.dropbox.com/u/24218791/d/phobos/std_hash_md.html
http://dl.dropbox.com/u/24218791/d/phobos/std_has
On 4 July 2012 15:48, d coder wrote:
>
>> Obtain the gdc sources and install into gcc-core (I
>> will tarball a copy up that includes the zlib sources too and post a
>> link).
>
>
> Greetings
>
> Where would I find the gdc source?
>
Working on that, will post it on my project site this afternoon.
On 04-07-2012 16:48, d coder wrote:
Obtain the gdc sources and install into gcc-core (I
will tarball a copy up that includes the zlib sources too and post a
link).
Greetings
Where would I find the gdc source?
https://github.com/D-Programming-GDC/GDC
Then rebuild gcc with
> Obtain the gdc sources and install into gcc-core (I
> will tarball a copy up that includes the zlib sources too and post a
> link).
>
Greetings
Where would I find the gdc source?
Then rebuild gcc with the same options above above, but with
> --enable-languages=d included.
Would this option e
Morning,
I've noticed that 256bit vector support has been added to the D
frontend during the development stages of 2.060 whilst was
looking around in druntime core.
https://github.com/D-Programming-Language/druntime/commit/fcc91588e89fa48b699f0efe0cdfb8c23e2bb4ae
Is anyone willing to object
On 04-Jul-12 16:40, Tobias Pankrath wrote:
You have to maintain 2 version of you algorithm. This is more work to
test, to maintain, and it is likely to introduce more bugs.
More code == more bugs. More NPATH = more bugs and harder to test and
to maintain.
In addition, this will result in practi
On Wednesday, 4 July 2012 at 12:24:14 UTC,
trav...@phare.normalesup.org (Christophe Travert) wrote:
I am not sure what would be worse, in the long run, between
asking developpers to make front remain valid after popFront
until next call to front, or having two different standard ways
to iterate
On Wednesday, 4 July 2012 at 12:40:41 UTC, Tobias Pankrath wrote:
You have to maintain 2 version of you algorithm. This is more
work to test, to maintain, and it is likely to introduce more
bugs.
More code == more bugs. More NPATH = more bugs and harder to
test and to maintain.
In addition,
You have to maintain 2 version of you algorithm. This is more
work to test, to maintain, and it is likely to introduce more
bugs.
More code == more bugs. More NPATH = more bugs and harder to
test and to maintain.
In addition, this will result in practice in less generic code,
because one ma
Le 04/07/2012 13:04, Roman D. Boiko a écrit :
On Wednesday, 4 July 2012 at 10:54:41 UTC, deadalnix wrote:
I do agree with that. However, the current proposal have the same
drawback but on the code that use the range.
Both solutions are messy IMO.
What is error-prone in current client code?
I
"Roman D. Boiko" , dans le message (digitalmars.D:171108), a écrit :
>
> What is error-prone in current client code?
>
> If particular algorithm wants to take advantage of a potential
> speed-up, it may decide to check whether hasConsume!Range, and
> call consumeFront instead of front + popFron
On 07/04/2012 12:50 PM, deadalnix wrote:
Le 04/07/2012 06:32, Jonathan M Davis a écrit :
Okay, given the fact that takeFront wouldn't work with ranges like
std.stdio.ByLine, the code as proposed won't work. So, here's an adjusted
proposal:
https://github.com/jmdavis/phobos/commit/14b88d9d5528f8
On 04-Jul-12 14:50, deadalnix wrote:
Le 04/07/2012 06:32, Jonathan M Davis a écrit :
Okay, given the fact that takeFront wouldn't work with ranges like
std.stdio.ByLine, the code as proposed won't work. So, here's an adjusted
proposal:
https://github.com/jmdavis/phobos/commit/14b88d9d5528f8736a
On 4 July 2012 11:52, Jacob Carlborg wrote:
> On 2012-07-04 02:34, Jonathan M Davis wrote:
>>
>> On Wednesday, July 04, 2012 00:42:22 Iain Buclaw wrote:
>>>
>>> Just so long as it isn't Gentoo. :o)
>>>
>>> Afterall, out of all of the linux distros out there, I would say that
>>> gentoo takes the l
On Wednesday, 4 July 2012 at 10:54:41 UTC, deadalnix wrote:
I do agree with that. However, the current proposal have the
same drawback but on the code that use the range.
Both solutions are messy IMO.
What is error-prone in current client code?
If particular algorithm wants to take advantage
Many languages does this (it doesn't mean it is the right thing
to do). Do you know why this shouldn't be done ?
In C++ it was exception safety, wasn't it?
Le 04/07/2012 10:14, Jonathan M Davis a écrit :
On Wednesday, July 04, 2012 09:55:57 Roman D. Boiko wrote:
On Wednesday, 4 July 2012 at 04:33:14 UTC, Jonathan M Davis wrote:
If no one has any major objections to this scheme or can
provide a better proposal, I'll create a pull request from what
On 2012-07-04 02:34, Jonathan M Davis wrote:
On Wednesday, July 04, 2012 00:42:22 Iain Buclaw wrote:
Just so long as it isn't Gentoo. :o)
Afterall, out of all of the linux distros out there, I would say that
gentoo takes the least time to mess around...
LOL. I did use Gentoo for a while, but
Le 04/07/2012 06:32, Jonathan M Davis a écrit :
Okay, given the fact that takeFront wouldn't work with ranges like
std.stdio.ByLine, the code as proposed won't work. So, here's an adjusted
proposal:
https://github.com/jmdavis/phobos/commit/14b88d9d5528f8736ae6014013bba82367e83620
As suggested,
On 07/04/2012 04:50 AM, Jonathan M Davis wrote:
But reducing code was never my concern (nor Dmitry's in considering proposing
essentially the same thing). It's efficiency that's the problem - particularly
with strings. IIRC, with the tests that I ran, it took about 33% longer to use
front and pop
Le 03/07/2012 19:27, monarch_dodra a écrit :
On Tuesday, 3 July 2012 at 17:22:17 UTC, Wouter Verhelst wrote:
Jonathan M Davis writes:
Couldn't you just overload popFront?
have a void popFront which throws off the first element without
returning anything, and an auto popFront which does return
On Wednesday, July 04, 2012 09:21:35 Christophe Travert wrote:
> What change would you expect in the langage? making pure function
> automatically @safe? That may not be such a ba idea. However, that is
> not even enough, you could still create bug from optimizations with
> casting outside the pure
Denis Shelomovskij , dans le message (digitalmars.D:171072), a écrit :
> Since issue 8185 has been closed, I'm still very confused. I just
> understood that endless discussion doesn't result in anything.
>
> See example from http://d.puremagic.com/issues/show_bug.cgi?id=8185#c40
> ---
> int f(siz
On Wednesday, July 04, 2012 10:43:04 Roman D. Boiko wrote:
> On Wednesday, 4 July 2012 at 08:31:05 UTC, Jonathan M Davis wrote:
> > But if the default is that there is no consumeFront, then it'll
> > only be there when the programmer determines that they need it
> > and defines it. So, the default
On Wednesday, 4 July 2012 at 08:40:46 UTC, Jonathan M Davis wrote:
It depends on the API. All that the word read indicates is that
data was read.
It doesn't indicate anything about what was read from or what
happened to it.
In some cases, read doesn't alter what's read at all. In others
it does
On Wednesday, July 04, 2012 10:37:41 Mehrdad wrote:
> On Wednesday, 4 July 2012 at 08:35:30 UTC, Dmitry Olshansky wrote:
> > On 04-Jul-12 12:29, Mehrdad wrote:
> >> On Wednesday, 4 July 2012 at 08:25:59 UTC, Roman D. Boiko
> >>
> >> wrote:
> >>> That would be almost perfect. But has drawbacks:
> >
On Wednesday, 4 July 2012 at 08:31:05 UTC, Jonathan M Davis wrote:
But if the default is that there is no consumeFront, then it'll
only be there when the programmer determines that they need it
and defines it. So, the default is safe, but the option of
efficiency is there if the programmer code
On Wednesday, July 04, 2012 10:25:18 Mehrdad wrote:
> On Wednesday, 4 July 2012 at 08:13:20 UTC, Tobias Pankrath wrote:
> > The name must imply that the range will be changed, i.e. after
> > the call the value is not part of the range anymore.
> >
> > consume does this, fetch does this, too. read
On 04-Jul-12 12:29, Mehrdad wrote:
On Wednesday, 4 July 2012 at 08:25:59 UTC, Roman D. Boiko wrote:
That would be almost perfect. But has drawbacks:
* if element is big and may be not needed in all calls to popFront
(when the user wants to ignore elements), there would be some overhead;
Could
On Wednesday, 4 July 2012 at 08:35:30 UTC, Dmitry Olshansky wrote:
On 04-Jul-12 12:29, Mehrdad wrote:
On Wednesday, 4 July 2012 at 08:25:59 UTC, Roman D. Boiko
wrote:
That would be almost perfect. But has drawbacks:
* if element is big and may be not needed in all calls to
popFront
(when the
On Wednesday, 4 July 2012 at 08:25:19 UTC, Mehrdad wrote:
Where have you last ever seen a read() method whose default
behavior was NOT to modify the
collection/range/iterator/stream/whatever?
That's a good question. When writing it, I was thinking about
real world analogies like reading a b
On Wednesday, 4 July 2012 at 08:31:05 UTC, Jonathan M Davis wrote:
He was suggesting that a range like ByLine define consumeFront
and then play games to make it work. So, instead of doing the
equivalent of
auto retval = range.front;
range.popFront();
return retval;
only more efficiently, it w
On Wednesday, July 04, 2012 10:20:58 Mehrdad wrote:
> On Wednesday, 4 July 2012 at 08:18:35 UTC, Mehrdad wrote:
> > On Wednesday, 4 July 2012 at 08:16:32 UTC, Roman D. Boiko wrote:
> >> On Wednesday, 4 July 2012 at 08:13:10 UTC, Mehrdad wrote:
> >>> What's wrong with moveFront()?
> >>
> >> It has
On Wednesday, 4 July 2012 at 08:14:54 UTC, Jonathan M Davis wrote:
On Wednesday, July 04, 2012 09:55:57 Roman D. Boiko wrote:
Still would be nice to get your (or community) feedback on my
previous proposals to localize custom logic inside ranges which
invalidate value returned from front.
It s
On Wednesday, July 04, 2012 10:16:05 Mehrdad wrote:
> On Wednesday, 4 July 2012 at 08:14:54 UTC, Jonathan M Davis wrote:
> > On Wednesday, July 04, 2012 09:55:57 Roman D. Boiko wrote:
> >> On Wednesday, 4 July 2012 at 04:33:14 UTC, Jonathan M Davis
> >>
> >> wrote:
> >> > If no one has any major o
On Wednesday, 4 July 2012 at 08:25:59 UTC, Roman D. Boiko wrote:
That would be almost perfect. But has drawbacks:
* if element is big and may be not needed in all calls to
popFront (when the user wants to ignore elements), there would
be some overhead;
Could you give an example of such a ran
On Wednesday, 4 July 2012 at 08:20:59 UTC, Mehrdad wrote:
I propose we just allow (but not require) popFront() to return
ElementType!(R) instead of void?
That way, people who need the performance can check to see the
return type, and use it without front() if needed.
That would be almost per
On Wednesday, 4 July 2012 at 08:25:19 UTC, Mehrdad wrote:
Where have you last ever seen a read() method whose default
behavior was NOT to modify the
collection/range/iterator/stream/whatever?
+1
On Wednesday, 4 July 2012 at 08:13:20 UTC, Tobias Pankrath wrote:
The name must imply that the range will be changed, i.e. after
the call the value is not part of the range anymore.
consume does this, fetch does this, too. read does not
Where have you last ever seen a read() method whose d
On Wednesday, 4 July 2012 at 08:18:35 UTC, Mehrdad wrote:
On Wednesday, 4 July 2012 at 08:16:32 UTC, Roman D. Boiko wrote:
On Wednesday, 4 July 2012 at 08:13:10 UTC, Mehrdad wrote:
What's wrong with moveFront()?
It has different semantics. For example, it is only supported
for ranges which h
On Wednesday, July 04, 2012 11:59:10 Denis Shelomovskij wrote:
> Since issue 8185 has been closed, I'm still very confused. I just
> understood that endless discussion doesn't result in anything.
>
> See example from http://d.puremagic.com/issues/show_bug.cgi?id=8185#c40
> ---
> int f(size_t p) pu
On Wednesday, 4 July 2012 at 08:16:32 UTC, Roman D. Boiko wrote:
On Wednesday, 4 July 2012 at 08:13:10 UTC, Mehrdad wrote:
What's wrong with moveFront()?
It has different semantics. For example, it is only supported
for ranges which have movable elements. After moveFront, the
element which w
On Wednesday, 4 July 2012 at 08:14:54 UTC, Jonathan M Davis wrote:
On Wednesday, July 04, 2012 09:55:57 Roman D. Boiko wrote:
On Wednesday, 4 July 2012 at 04:33:14 UTC, Jonathan M Davis
wrote:
> If no one has any major objections to this scheme or can
> provide a better proposal, I'll create a
On Wednesday, 4 July 2012 at 08:13:10 UTC, Mehrdad wrote:
What's wrong with moveFront()?
It has different semantics. For example, it is only supported for
ranges which have movable elements. After moveFront, the element
which was placed in the front position is replaced by E.init (E
is eleme
On Wednesday, 4 July 2012 at 08:13:10 UTC, Mehrdad wrote:
What's wrong with moveFront()?
+ it's used in std.container, too.
- in std.container the length of the container is invariant
under moveFront,
with the proposal here this would not be the case. So it's
similar but inconsistent.
On Wednesday, 4 July 2012 at 07:58:11 UTC, Roman D. Boiko wrote:
On Wednesday, 4 July 2012 at 07:53:32 UTC, Roman D. Boiko wrote:
On Wednesday, 4 July 2012 at 07:40:55 UTC, monarch_dodra wrote:
I'll propose "spendFront", which is pretty much the same
thing, but is less loaded. I'm not entirely
On Wednesday, July 04, 2012 09:55:57 Roman D. Boiko wrote:
> On Wednesday, 4 July 2012 at 04:33:14 UTC, Jonathan M Davis wrote:
> > If no one has any major objections to this scheme or can
> > provide a better proposal, I'll create a pull request from what
> > I have.
>
> No objections.
>
> Still
On Wednesday, 4 July 2012 at 08:12:46 UTC, Jonathan M Davis wrote:
On Wednesday, July 04, 2012 09:58:09 Roman D. Boiko wrote:
On Wednesday, 4 July 2012 at 07:53:32 UTC, Roman D. Boiko
wrote:
> On Wednesday, 4 July 2012 at 07:40:55 UTC, monarch_dodra
> wrote:
>> I'll propose "spendFront", which
What's wrong with moveFront()?
On Wednesday, July 04, 2012 09:58:09 Roman D. Boiko wrote:
> On Wednesday, 4 July 2012 at 07:53:32 UTC, Roman D. Boiko wrote:
> > On Wednesday, 4 July 2012 at 07:40:55 UTC, monarch_dodra wrote:
> >> I'll propose "spendFront", which is pretty much the same
> >> thing, but is less loaded. I'm not ent
Since issue 8185 has been closed, I'm still very confused. I just
understood that endless discussion doesn't result in anything.
See example from http://d.puremagic.com/issues/show_bug.cgi?id=8185#c40
---
int f(size_t p) pure
{
return *cast(int*) p;
}
void g(size_t p, ref size_t) pure
{
On Wednesday, 4 July 2012 at 04:33:14 UTC, Jonathan M Davis wrote:
If no one has any major objections to this scheme or can
provide a better proposal, I'll create a pull request from what
I have.
No objections.
Still would be nice to get your (or community) feedback on my
previous proposals
On Wednesday, 4 July 2012 at 07:53:32 UTC, Roman D. Boiko wrote:
On Wednesday, 4 July 2012 at 07:40:55 UTC, monarch_dodra wrote:
I'll propose "spendFront", which is pretty much the same
thing, but is less loaded. I'm not entirely sure if it carries
the meaning as well? I think it is a worth dis
On Wednesday, 4 July 2012 at 07:40:55 UTC, monarch_dodra wrote:
I'll propose "spendFront", which is pretty much the same thing,
but is less loaded. I'm not entirely sure if it carries the
meaning as well? I think it is a worth discussion.
I'm not a native speaker, but I feel that "spend" would
On Wednesday, 4 July 2012 at 04:33:14 UTC, Jonathan M Davis wrote:
Okay, given the fact that takeFront wouldn't work with ranges
like
std.stdio.ByLine, the code as proposed won't work. So, here's
an adjusted
proposal:
https://github.com/jmdavis/phobos/commit/14b88d9d5528f8736ae6014013bba82367e
96 matches
Mail list logo
