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, I renamed takeFront and takeBack to consumeFront
On Wednesday, 4 July 2012 at 00:35:07 UTC, Jonathan M Davis wrote:
On Wednesday, July 04, 2012 00:42:22 Iain Buclaw wrote:
On 3 July 2012 17:39, Jonathan M Davis
wrote:
> On Tuesday, July 03, 2012 17:05:52 Iain Buclaw wrote:
>> Also, I say you should drop Ubuntu in favour of Debian. :o)
>
> N
On Wednesday, July 04, 2012 00:42:22 Iain Buclaw wrote:
> On 3 July 2012 17:39, Jonathan M Davis wrote:
> > On Tuesday, July 03, 2012 17:05:52 Iain Buclaw wrote:
> >> Also, I say you should drop Ubuntu in favour of Debian. :o)
> >
> > No, no, no. Use Arch! ;)
> >
> > - Jonathan M Davis
>
> Just
On 3 July 2012 17:39, Jonathan M Davis wrote:
> On Tuesday, July 03, 2012 17:05:52 Iain Buclaw wrote:
>> Also, I say you should drop Ubuntu in favour of Debian. :o)
>
> No, no, no. Use Arch! ;)
>
> - Jonathan M Davis
Just so long as it isn't Gentoo. :o)
Afterall, out of all of the linux distros
On Tue, Jul 03, 2012 at 11:55:24PM +0200, F i L wrote:
> On Tuesday, 3 July 2012 at 16:39:21 UTC, Jonathan M Davis wrote:
> >On Tuesday, July 03, 2012 17:05:52 Iain Buclaw wrote:
> >>Also, I say you should drop Ubuntu in favour of Debian. :o)
+1.
> >No, no, no. Use Arch! ;)
-1. ;-)
> Yes!
[..
On Tuesday, July 03, 2012 23:55:24 F i L wrote:
> On Tuesday, 3 July 2012 at 16:39:21 UTC, Jonathan M Davis wrote:
> > On Tuesday, July 03, 2012 17:05:52 Iain Buclaw wrote:
> >> Also, I say you should drop Ubuntu in favour of Debian. :o)
> >
> > No, no, no. Use Arch! ;)
> >
> > - Jonathan M Davis
On Tuesday, 3 July 2012 at 16:39:21 UTC, Jonathan M Davis wrote:
On Tuesday, July 03, 2012 17:05:52 Iain Buclaw wrote:
Also, I say you should drop Ubuntu in favour of Debian. :o)
No, no, no. Use Arch! ;)
- Jonathan M Davis
Yes!
foreach (linux; linuxDistros)
{
if (linux == user.favDistr
monarch_dodra:
As far as I can recall, I've always been taught that pop does
NOT (should not) return a value. Rationale being it makes you
pay for a read/copy you may not have asked for.
I think it's also a matter of exception safety.
That's the way C++ does it, and is what I've come to exp
On 03-Jul-12 20:37, Jonathan M Davis wrote:
This seems like it probably merits a bit of discussion, so I'm bringing it up
here rather than simply opening a pull request.
At present, for some ranges (variably-lengthed ranges such as strings in
particular), calling front incurs a cost which popFro
Still, ranges which invalidate front on popFront could defer that
(store a flag that popFront or consumeFront has been called and
invalidate value previously returned from front in the next call
to front). That would be intrusive with respect to such ranges,
and a breaking change. But it would
On Tuesday, 3 July 2012 at 18:12:54 UTC,
trav...@phare.normalesup.org (Christophe Travert) wrote:
Range have been designed with the idea that front is valid
until next
call to popFront. If popFront was to be called right after
front, then
it would just be a popFront that returns a value, and m
Range have been designed with the idea that front is valid until next
call to popFront. If popFront was to be called right after front, then
it would just be a popFront that returns a value, and maybe a justPop or
something if you don't want to copy the value.
It's delicate to come now and dec
On Tuesday, 3 July 2012 at 18:00:55 UTC, Jonathan M Davis wrote:
On Tuesday, July 03, 2012 10:40:07 Jonathan M Davis wrote:
On Tuesday, July 03, 2012 17:31:21 Christophe Travert wrote:
> takeFront implementation is dangerous for ranges which
> invalidates their
> front value when popFront is ca
On Tuesday, 3 July 2012 at 17:40:24 UTC, Jonathan M Davis wrote:
On Tuesday, July 03, 2012 17:31:21 Christophe Travert wrote:
takeFront implementation is dangerous for ranges which
invalidates their
front value when popFront is called, for instance,
File.byLine. Thus
takeFront will have to be u
On Tuesday, July 03, 2012 10:40:07 Jonathan M Davis wrote:
> On Tuesday, July 03, 2012 17:31:21 Christophe Travert wrote:
> > takeFront implementation is dangerous for ranges which invalidates their
> > front value when popFront is called, for instance, File.byLine. Thus
> > takeFront will have to
On Tuesday, 3 July 2012 at 17:40:24 UTC, Jonathan M Davis wrote:
On Tuesday, July 03, 2012 17:31:21 Christophe Travert wrote:
takeFront implementation is dangerous for ranges which
invalidates their
front value when popFront is called, for instance,
File.byLine. Thus
takeFront will have to be u
On Tuesday, July 03, 2012 19:29:44 Tobias Pankrath wrote:
> consumeFront?
That seems like a good suggestion.
- Jonathan M Davis
On Tuesday, July 03, 2012 17:31:21 Christophe Travert wrote:
> takeFront implementation is dangerous for ranges which invalidates their
> front value when popFront is called, for instance, File.byLine. Thus
> takeFront will have to be used with care: any range implement takeFront
> (because of the
On Tuesday, July 03, 2012 19:17:40 Roman D. Boiko wrote:
> The name takeFront is too similar to take, which has very
> different semantics.
I have similar concerns, but takeFront and takeBack were the best that I could
come up with. frontPopFront or retPopFront and the like would be horrible. So,
takeFront implementation is dangerous for ranges which invalidates their
front value when popFront is called, for instance, File.byLine. Thus
takeFront will have to be used with care: any range implement takeFront
(because of the template and USFC), but it may not be valid. That makes
the range
On Tuesday, 3 July 2012 at 17:29:45 UTC, Tobias Pankrath wrote:
consumeFront?
+1
consumeFront?
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 data.
I'd always been taught that "pop" mean
On Tuesday, 3 July 2012 at 16:37:20 UTC, Jonathan M Davis wrote:
...
Oh, and if we go with this, ideally, the compiler would be
updated to use
takeFront for foreach instead of front and popFront if a range
implements it
(but still do it the current way if it doesn't). So, if
typeof(range)
imp
Jonathan M Davis writes:
> This seems like it probably merits a bit of discussion, so I'm bringing it up
> here rather than simply opening a pull request.
>
> At present, for some ranges (variably-lengthed ranges such as strings in
> particular), calling front incurs a cost which popFront at le
The name takeFront is too similar to take, which has very
different semantics.
Iain Buclaw writes:
> On 3 July 2012 13:29, Iain Buclaw wrote:
> Also, I say you should drop Ubuntu in favour of Debian. :o)
ACK ;-)
--
The volume of a pizza of thickness a and radius z can be described by
the following formula:
pi zz a
On Tuesday, July 03, 2012 17:05:52 Iain Buclaw wrote:
> Also, I say you should drop Ubuntu in favour of Debian. :o)
No, no, no. Use Arch! ;)
- Jonathan M Davis
This seems like it probably merits a bit of discussion, so I'm bringing it up
here rather than simply opening a pull request.
At present, for some ranges (variably-lengthed ranges such as strings in
particular), calling front incurs a cost which popFront at least partially
duplicates. So, the r
On 3 July 2012 13:29, Iain Buclaw wrote:
> On 3 July 2012 13:00, akaz wrote:
>> On Tuesday, 3 July 2012 at 10:12:39 UTC, Iain Buclaw wrote:
>>>
>>> Hi,
>>>
>>> I'm going to be pushing gdc-4.8 package into debian this weekend (give
>>> about a fortnight for it to land in sid) - is
>>
>>
>> Hi,
>>
On Sat, Jun 30, 2012 at 6:27 AM, bearophile wrote:
> Tobias Pankrath:
>
>
> But I would generally avoid SList.
>>
>
> It's not good.
>
> And in general linked lists are quite overrated. On modern CPUs it's not
> easy to find situations where a linked list is better than a dynamic array
> or a chu
On Tuesday, 3 July 2012 at 11:43:04 UTC, Iain Buclaw wrote:
On 3 July 2012 11:55, Jakob Bornecrantz
wrote:
On Tuesday, 3 July 2012 at 10:12:39 UTC, Iain Buclaw wrote:
Hi,
I'm going to be pushing gdc-4.8 package into debian this
weekend (give
about a fortnight for it to land in sid) - is any
On Tuesday, 3 July 2012 at 14:30:38 UTC, Andrei Alexandrescu
wrote:
On 7/3/12 10:01 AM, Jesse Phillips wrote:
On Monday, 2 July 2012 at 14:05:31 UTC, Bernard Helyer wrote:
My main point is that it doesn't work. Even the given example
does not
work. It should either be fixed or ditched.
It do
On 7/3/12 10:01 AM, Jesse Phillips wrote:
On Monday, 2 July 2012 at 14:05:31 UTC, Bernard Helyer wrote:
My main point is that it doesn't work. Even the given example does not
work. It should either be fixed or ditched.
It does work, it just requires a sorted range instead of an arbitrary
range
On Tuesday, 3 July 2012 at 14:10:42 UTC, strongdrink wrote:
(First, sorry for not using code tags.. please let me know how
to do them) :)
Hey guys, I am fairly new to the D language... and am trying to
compile a small D SFML2 program. I installed derelict and such
already...
Linux deskarch
(First, sorry for not using code tags.. please let me know how to
do them) :)
Hey guys, I am fairly new to the D language... and am trying to
compile a small D SFML2 program. I installed derelict and such
already...
Linux deskarch 3.4.4-2-ARCH #1 SMP PREEMPT Sun Jun 24 18:59:47
CEST 2012 x8
On Monday, 2 July 2012 at 14:05:31 UTC, Bernard Helyer wrote:
My main point is that it doesn't work. Even the given example
does not work. It should either be fixed or ditched.
It does work, it just requires a sorted range instead of an
arbitrary range.
std.range.assumeSorted()
std.algorithm
On 3 July 2012 13:00, akaz wrote:
> On Tuesday, 3 July 2012 at 10:12:39 UTC, Iain Buclaw wrote:
>>
>> Hi,
>>
>> I'm going to be pushing gdc-4.8 package into debian this weekend (give
>> about a fortnight for it to land in sid) - is
>
>
> Hi,
>
> I understand there will be no gdc-4.7 package, so t
On Tuesday, 3 July 2012 at 10:12:39 UTC, Iain Buclaw wrote:
Hi,
I'm going to be pushing gdc-4.8 package into debian this
weekend (give about a fortnight for it to land in sid) - is
Hi,
I understand there will be no gdc-4.7 package, so this won't be
available on Ubuntu 12.10 which (currentl
On 3 July 2012 11:55, Jakob Bornecrantz wrote:
> On Tuesday, 3 July 2012 at 10:12:39 UTC, Iain Buclaw wrote:
>>
>> Hi,
>>
>> I'm going to be pushing gdc-4.8 package into debian this weekend (give
>> about a fortnight for it to land in sid) - is anyone interested in porting
>> Druntime / Phobos ove
On 3 July 2012 11:26, d coder wrote:
>>
>> I'm going to be pushing gdc-4.8 package into debian this weekend (give
>> about a fortnight for it to land in sid) - is anyone interested in porting
>> Druntime / Phobos over to the architectures that Debian supports? I can
>> give anyone a quick crash c
On Tuesday, 3 July 2012 at 10:12:39 UTC, Iain Buclaw wrote:
Hi,
I'm going to be pushing gdc-4.8 package into debian this
weekend (give about a fortnight for it to land in sid) - is
anyone interested in porting Druntime / Phobos over to the
architectures that Debian supports? I can give anyon
>
>
> I'm going to be pushing gdc-4.8 package into debian this weekend (give
> about a fortnight for it to land in sid) - is anyone interested in porting
> Druntime / Phobos over to the architectures that Debian supports? I can
> give anyone a quick crash course through building a cross compiler i
On Tuesday, 3 July 2012 at 10:12:39 UTC, Iain Buclaw wrote:
Hi,
I'm going to be pushing gdc-4.8 package into debian this
weekend (give about a fortnight for it to land in sid)
Sorry for interrupting. Just wanted to say:
AWESOME!
Hi,
I'm going to be pushing gdc-4.8 package into debian this weekend
(give about a fortnight for it to land in sid) - is anyone
interested in porting Druntime / Phobos over to the architectures
that Debian supports? I can give anyone a quick crash course
through building a cross compiler if
On Tuesday, July 03, 2012 09:42:58 Don Clugston wrote:
> On 02/07/12 23:20, Walter Bright wrote:
> > On 7/2/2012 1:04 PM, bearophile wrote:
> >> Walter Bright:
> >>> Put "final" in front of y, and it will compile. Remember, this was
> >>> done for D1
> >>> that didn't have const.
> >>
> >> I see.
On 02/07/12 23:20, Walter Bright wrote:
On 7/2/2012 1:04 PM, bearophile wrote:
Walter Bright:
Put "final" in front of y, and it will compile. Remember, this was
done for D1
that didn't have const.
I see. So in D2 are we going to require that y to be immutable?
No. I don't agree there's a p
47 matches
Mail list logo
