On Wednesday, June 26, 2013 08:30:20 monarch_dodra wrote:
> In regards to Take/TakeExactly, it might be best to implement
> both as a common struct? eg:
>
> private struct TakeImplementation(bool Exactly = false)
> {...}
> alias Take = TakeImplementation!false;
> private alias TakeExactly = TakeIm
On Tuesday, 25 June 2013 at 22:39:07 UTC, Jonathan M Davis wrote:
On Wednesday, June 26, 2013 00:11:29 Timon Gehr wrote:
On 06/25/2013 10:37 PM, Jonathan M Davis wrote:
> On Tuesday, June 25, 2013 21:42:17 Timon Gehr wrote:
>> Take will check the wrapped range's 'empty' repeatedly.
>> takeExact
On Sunday, June 23, 2013 07:47:16 Andrei Alexandrescu wrote:
> On 6/23/13 7:39 AM, Andrei Alexandrescu wrote:
> > Again, we can make things work by introducing a primitive for
> > bidirectional ranges:
> >
> > R before(R r1, R r2);
> >
> > Assuming r2 is reachable from r1, returns the portion of
On Wednesday, June 26, 2013 00:11:29 Timon Gehr wrote:
> On 06/25/2013 10:37 PM, Jonathan M Davis wrote:
> > On Tuesday, June 25, 2013 21:42:17 Timon Gehr wrote:
> >> Take will check the wrapped range's 'empty' repeatedly. takeExactly does
> >> not need to do that at all.
> >
> > It only does that
On 06/25/2013 10:37 PM, Jonathan M Davis wrote:
On Tuesday, June 25, 2013 21:42:17 Timon Gehr wrote:
On 06/25/2013 09:21 PM, Jonathan M Davis wrote:
On Tuesday, June 25, 2013 19:33:32 Timon Gehr wrote:
On 06/25/2013 07:16 PM, Andrei Alexandrescu wrote:
On 6/25/13 4:47 AM, Timon Gehr wrote:
G
On Tuesday, June 25, 2013 16:37:06 Jonathan M Davis wrote:
> On Tuesday, June 25, 2013 21:42:17 Timon Gehr wrote:
> > On 06/25/2013 09:21 PM, Jonathan M Davis wrote:
> > > I suppose that takeExactly's Result type (in the case where it actually
> > > creates its own type) could (and should) forward
On Tuesday, June 25, 2013 21:42:17 Timon Gehr wrote:
> On 06/25/2013 09:21 PM, Jonathan M Davis wrote:
> > On Tuesday, June 25, 2013 19:33:32 Timon Gehr wrote:
> >> On 06/25/2013 07:16 PM, Andrei Alexandrescu wrote:
> >>> On 6/25/13 4:47 AM, Timon Gehr wrote:
> Good point, but takeExactly curr
On 06/25/2013 09:21 PM, Jonathan M Davis wrote:
On Tuesday, June 25, 2013 19:33:32 Timon Gehr wrote:
On 06/25/2013 07:16 PM, Andrei Alexandrescu wrote:
On 6/25/13 4:47 AM, Timon Gehr wrote:
Good point, but takeExactly currently is not a better choice due to its
poor quality of implementation.
On Tuesday, June 25, 2013 19:33:32 Timon Gehr wrote:
> On 06/25/2013 07:16 PM, Andrei Alexandrescu wrote:
> > On 6/25/13 4:47 AM, Timon Gehr wrote:
> >> Good point, but takeExactly currently is not a better choice due to its
> >> poor quality of implementation.
> >>
> >> https://github.com/D-Progr
On 06/25/2013 07:16 PM, Andrei Alexandrescu wrote:
On 6/25/13 4:47 AM, Timon Gehr wrote:
Good point, but takeExactly currently is not a better choice due to its
poor quality of implementation.
https://github.com/D-Programming-Language/phobos/blob/master/std/range.d#L2904
What's wrong with i
On 6/25/13 4:47 AM, Timon Gehr wrote:
Good point, but takeExactly currently is not a better choice due to its
poor quality of implementation.
https://github.com/D-Programming-Language/phobos/blob/master/std/range.d#L2904
What's wrong with it?
Andrei
On Tuesday, June 25, 2013 13:47:19 Timon Gehr wrote:
> Good point, but takeExactly currently is not a better choice due to its
> poor quality of implementation.
What's the problem with takeExactly's implementation?
- Jonathan M Davis
On 06/25/2013 08:39 AM, monarch_dodra wrote:
On Monday, 24 June 2013 at 23:11:29 UTC, Timon Gehr wrote:
On 06/23/2013 11:20 PM, Timon Gehr wrote:
On 06/23/2013 01:34 PM, monarch_dodra wrote:
...
But as soon as you need an algorithm that actually *handles* ranges:
swaps them, merges them, sear
On Mon, Jun 24, 2013 at 11:46 PM, monarch_dodra wrote:
> On Monday, 24 June 2013 at 22:27:19 UTC, Brad Anderson wrote:
>
>> On Sunday, 23 June 2013 at 01:34:53 UTC, Andrei Alexandrescu wrote:
>>
>>> On 6/22/13 2:58 PM, monarch_dodra wrote:
>>>
long story short: we don't have rfind. C++ does.
On Monday, 24 June 2013 at 22:27:19 UTC, Brad Anderson wrote:
On Sunday, 23 June 2013 at 01:34:53 UTC, Andrei Alexandrescu
wrote:
On 6/22/13 2:58 PM, monarch_dodra wrote:
long story short: we don't have rfind. C++ does.
We do, just that it's for random-access ranges. C++ offers it
for bidire
On Monday, 24 June 2013 at 23:11:29 UTC, Timon Gehr wrote:
On 06/23/2013 11:20 PM, Timon Gehr wrote:
On 06/23/2013 01:34 PM, monarch_dodra wrote:
...
But as soon as you need an algorithm that actually *handles*
ranges:
swaps them, merges them, searches in them and splices them,
then things
On 06/23/2013 11:20 PM, Timon Gehr wrote:
On 06/23/2013 01:34 PM, monarch_dodra wrote:
...
But as soon as you need an algorithm that actually *handles* ranges:
swaps them, merges them, searches in them and splices them, then things
get hairy.
For example, try implementing a sort (either merge
On 06/24/2013 09:02 AM, deadalnix wrote:
On Sunday, 23 June 2013 at 11:34:25 UTC, monarch_dodra wrote:
For example, try implementing a sort (either merge or q) with a
non-sliceable range... very very hard...
https://github.com/deadalnix/Dsort/blob/master/sort/bubble.d
(That's neither merge-
On Sunday, 23 June 2013 at 01:34:53 UTC, Andrei Alexandrescu
wrote:
On 6/22/13 2:58 PM, monarch_dodra wrote:
long story short: we don't have rfind. C++ does.
We do, just that it's for random-access ranges. C++ offers it
for bidirectional ranges too. We could of course support it if
bidirecti
On Sunday, 23 June 2013 at 11:34:25 UTC, monarch_dodra wrote:
For example, try implementing a sort (either merge or q) with a
non-sliceable range... very very hard...
https://github.com/deadalnix/Dsort/blob/master/sort/bubble.d
On 06/23/2013 01:34 PM, monarch_dodra wrote:
...
But as soon as you need an algorithm that actually *handles* ranges:
swaps them, merges them, searches in them and splices them, then things
get hairy.
For example, try implementing a sort (either merge or q) with a
non-sliceable range... very ve
On 6/23/13 9:33 AM, monarch_dodra wrote:
BTW, kind of off topic, but since we are talking about bidirectional
ranges, and DList is the most relevant object: Do you think you would
have time to review my DList fix?
https://github.com/D-Programming-Language/phobos/pull/953
As Dmity said: "are we a
On Sunday, 23 June 2013 at 14:47:17 UTC, Andrei Alexandrescu
wrote:
On 6/23/13 7:39 AM, Andrei Alexandrescu wrote:
Again, we can make things work by introducing a primitive for
bidirectional ranges:
R before(R r1, R r2);
Assuming r2 is reachable from r1, returns the portion of r1
that lies
be
On Sunday, 23 June 2013 at 14:47:17 UTC, Andrei Alexandrescu
wrote:
On 6/23/13 7:39 AM, Andrei Alexandrescu wrote:
Again, we can make things work by introducing a primitive for
bidirectional ranges:
R before(R r1, R r2);
Assuming r2 is reachable from r1, returns the portion of r1
that lies
be
On 6/23/13 7:39 AM, Andrei Alexandrescu wrote:
Again, we can make things work by introducing a primitive for
bidirectional ranges:
R before(R r1, R r2);
Assuming r2 is reachable from r1, returns the portion of r1 that lies
before r2. (Definition: a range r2 is reachable from another range r1 if
23-Jun-2013 06:13, Brad Anderson пишет:
On Sunday, 23 June 2013 at 01:34:53 UTC, Andrei Alexandrescu wrote:
On 6/22/13 2:58 PM, monarch_dodra wrote:
long story short: we don't have rfind. C++ does.
We do, just that it's for random-access ranges. C++ offers it for
bidirectional ranges too. We
On 6/23/13 4:04 AM, monarch_dodra wrote:
R range;
auto r3 = findSplit(range);
void do_it(r3[0]);
void do_it(r3[1]);
void do_it(r3[2]);
This will actually instantiate 2 different do_it functions.
Yah, this is a good summary. If individual iterators are accessible,
findSplit can return three ra
On Sunday, 23 June 2013 at 11:04:17 UTC, monarch_dodra wrote:
It's a bit more than that, it's also about limiting template
bloat. For example:
To mitigate template bloat, you can downgrade compile-time
polymorphism to runtime polymorphism. D provides the facilities
for this, e.g. using the ab
On 06/23/2013 12:34 PM, monarch_dodra wrote:
> That's a very "I have a range and want to iterate on it" view. Which is fine
> and
> it works in that case (and I have no problems there).
>
> But as soon as you need an algorithm that actually *handles* ranges: swaps
> them,
> merges them, searches
On Sunday, 23 June 2013 at 11:06:07 UTC, Joseph Rushton Wakeling
wrote:
On 06/23/2013 10:54 AM, monarch_dodra wrote:
Not quite, it returns an object that returns those items when
iterated on. But
it is not the same type.
Why does that matter to you? One of the nice things about
ranges is th
On 06/23/2013 10:54 AM, monarch_dodra wrote:
> Not quite, it returns an object that returns those items when iterated on. But
> it is not the same type.
Why does that matter to you? One of the nice things about ranges is that the
strict object type seems to matter less than the interface and the
On Sunday, 23 June 2013 at 10:37:34 UTC, Vladimir Panteleev wrote:
The problem always boils down the fact that while we can get
the same iteration scheme, it's never the same range type:
Range r = some_range;
r = r.until!"a == 5"; //Does not compile Until!Range and Range
do not match
r = r.tak
On Sunday, 23 June 2013 at 09:54:56 UTC, monarch_dodra wrote:
Isn't this what `until` does?
Not quite, it returns an object that returns those items when
iterated on. But it is not the same type.
OK, I think we had a misunderstanding what "iterate" meant. I
used it in the meaning "iterate t
On Sunday, 23 June 2013 at 09:44:09 UTC, Vladimir Panteleev wrote:
On Sunday, 23 June 2013 at 09:10:03 UTC, monarch_dodra wrote:
All of these will *iterate* over part of said range, but none
will actually return the subrange I iterated on.
`until` does not iterate, it simply returns a range wh
On Sunday, 23 June 2013 at 09:10:03 UTC, monarch_dodra wrote:
All of these will *iterate* over part of said range, but none
will actually return the subrange I iterated on.
`until` does not iterate, it simply returns a range which ends
when your condition is satisfied.
V
[ . . X
rvalue references
SCNR
On Sunday, 23 June 2013 at 04:08:22 UTC, Vladimir Panteleev wrote:
On Saturday, 22 June 2013 at 20:09:01 UTC, monarch_dodra wrote:
#2: Extremelly bad compatibility with simple no
bidir/non-slicing ranges: There is no way to iterate over a
specific part of a range, and making a range out of what
On Saturday, 22 June 2013 at 20:09:01 UTC, monarch_dodra wrote:
#2: Extremelly bad compatibility with simple no
bidir/non-slicing ranges: There is no way to iterate over a
specific part of a range, and making a range out of what was
just iterated over. For example "Get the beggining of this
ra
On Sunday, 23 June 2013 at 01:34:53 UTC, Andrei Alexandrescu
wrote:
On 6/22/13 2:58 PM, monarch_dodra wrote:
long story short: we don't have rfind. C++ does.
We do, just that it's for random-access ranges. C++ offers it
for bidirectional ranges too. We could of course support it if
bidirecti
On Sat, Jun 22, 2013 at 4:15 PM, Timon Gehr wrote:
> On 06/23/2013 12:55 AM, H. S. Teoh wrote:
>
>> On Sat, Jun 22, 2013 at 10:57:53PM +0200, Jacob Carlborg wrote:
>>
>>> On 2013-06-22 18:40, H. S. Teoh wrote:
>>>
>>> Yeah that one made my eyes glaze over. I still have trouble wrapping my
b
On 6/22/13 2:58 PM, monarch_dodra wrote:
long story short: we don't have rfind. C++ does.
We do, just that it's for random-access ranges. C++ offers it for
bidirectional ranges too. We could of course support it if bidirectional
ranges were required to have something like r1.before(r2) that,
On 06/23/2013 12:55 AM, H. S. Teoh wrote:
On Sat, Jun 22, 2013 at 10:57:53PM +0200, Jacob Carlborg wrote:
On 2013-06-22 18:40, H. S. Teoh wrote:
Yeah that one made my eyes glaze over. I still have trouble wrapping my
brain around the strange syntax of is(), and why its diverse uses have
been s
On Sat, Jun 22, 2013 at 10:57:53PM +0200, Jacob Carlborg wrote:
> On 2013-06-22 18:40, H. S. Teoh wrote:
>
> >Yeah that one made my eyes glaze over. I still have trouble wrapping my
> >brain around the strange syntax of is(), and why its diverse uses have
> >been shoehorned into deceptively simila
On Sat, Jun 22, 2013 at 07:35:30PM +0200, DLearner wrote:
> Hi H. S. Teoh, I noticed that when you replied to a post, your
> reply usually started a new thread instead of showing in the thread
> the original post belongs to, this makes readers difficult follow
> original discussions.
[...]
I'm usi
On 06/22/2013 10:58 PM, monarch_dodra wrote:
> I mean that once you have an iota=>map=>filter=>whatnot...
>
> This scales well with ranges. With iterators though, you increase the
> complexity
> by 2 (front + back iterator) for every level. This ends up making the checks
> more expensive they the
On Saturday, 22 June 2013 at 21:28:47 UTC, Joseph Rushton
Wakeling wrote:
On 06/22/2013 09:08 PM, monarch_dodra wrote:
Personally, I've found ranges to be a very useful and powerful
*high level*
abstraction. They lend themselves work very well for adapting
and chaining
(which iterators don't).
On 06/22/2013 09:08 PM, monarch_dodra wrote:
> Personally, I've found ranges to be a very useful and powerful *high level*
> abstraction. They lend themselves work very well for adapting and chaining
> (which iterators don't). However, they do come with *some* downsides (IMO):
> #1: Performance iss
On 2013-06-22 18:40, H. S. Teoh wrote:
Yeah that one made my eyes glaze over. I still have trouble wrapping my
brain around the strange syntax of is(), and why its diverse uses have
been shoehorned into deceptively similar syntax.
Isn't quite a lot of the is-expression features undocumented?
On Saturday, 22 June 2013 at 19:40:28 UTC, Joseph Rushton
Wakeling wrote:
On 06/22/2013 05:17 PM, Andrej Mitrovic wrote:
Anyway, what features are you using now that you thought you'd
never
use when you started out using D?
Ranges, of course :-)
When I was first using D I knew that there wer
On 06/22/2013 05:17 PM, Andrej Mitrovic wrote:
> Anyway, what features are you using now that you thought you'd never
> use when you started out using D?
Ranges, of course :-)
When I was first using D I knew that there were these things called ranges that
were supposedly D's superior solution to
Hi H. S. Teoh, I noticed that when you replied to a post, your
reply usually started a new thread instead of showing in the
thread the original post belongs to, this makes readers difficult
follow original discussions.
On Saturday, 22 June 2013 at 16:42:24 UTC, H. S. Teoh wrote:
On Sat, Jun 2
On Saturday, 22 June 2013 at 16:19:20 UTC, Andrej Mitrovic wrote:
On Saturday, 22 June 2013 at 16:17:55 UTC, Andrej Mitrovic
wrote:
Anyway, what features are you using now that you thought you'd
never
use when you started out using D?
Apologies for the title, should have said "going". Too muc
On Sat, Jun 22, 2013 at 06:17:41PM +0200, Andrej Mitrovic wrote:
> I remember just a few years ago I was avoiding learning to use
> templates, thinking they're super-complicated and that I'd **never**
> actually need them. I used to read about them in the pages of the
> language reference, but noth
On Saturday, 22 June 2013 at 16:17:55 UTC, Andrej Mitrovic wrote:
Anyway, what features are you using now that you thought you'd
never
use when you started out using D?
Apologies for the title, should have said "going". Too much pizza
I suppose.. (makes me sleepy)
I remember just a few years ago I was avoiding learning to use
templates, thinking they're super-complicated and that I'd **never**
actually need them. I used to read about them in the pages of the
language reference, but nothing actually *clicked* while reading those
pages. I also remember reading
55 matches
Mail list logo
