On 2012-07-09 23:00, Timon Gehr wrote:
Actually you need a random-access range with assignable elements. Map
would need to be provided with an inverse mapping to support that.
zip has assignable elements when the source ranges do.
Are you saying I can't sort a range that comes from "map"? To
On 2012-07-09 22:23, Ali Çehreli wrote:
And a quick fix is to make an array first:
auto str = ["foo", "bar"].map!(x => x)().array();
Also note the added () for map, which is needed when compiled with
-property.
If I first have to convert it to an array, then sort and then convert it
to an a
On 2012-07-09 22:16, Andrei Alexandrescu wrote:
So foo is a range of strings, because each element of it is a string.
Then you want to chain a range of strings with a string, which is a
range of dchar. That doesn't work, and I agree the error message should
be more informative.
Is that by desi
On 2012-07-09 22:43, Simen Kjaeraas wrote:
You mean there are actually people out there who believe documentation
can be correct, not to mention understandable, comprehensive and giving
the information you need?
You do know there are closed source libraries where you don't have an
option.
-
Caligo wrote:
> On Mon, Jul 9, 2012 at 4:24 PM, Stefan Scholl wrote:
>> "bearophile" wrote:
>>> I think Go is meant to be used mostly on 64 bit servers.
>>
>> There aren't many people using Go on 32 bit systems. That's why there is
>> (was?) a big memory leak on these systems which wasn't caugh
On Tuesday, July 10, 2012 06:53:29 Benjamin Thaut wrote:
> Am 10.07.2012 00:53, schrieb Jonathan M Davis:
> > On Monday, July 09, 2012 22:41:57 Benjamin Thaut wrote:
> >> Clear uses the TypeInfo. The proposed functions should not be library
> >> functions but directly aviable from the compiler. Som
Am 10.07.2012 00:53, schrieb Jonathan M Davis:
On Monday, July 09, 2012 22:41:57 Benjamin Thaut wrote:
Clear uses the TypeInfo. The proposed functions should not be library
functions but directly aviable from the compiler. Something like
__postblit and __dtor but properly implemented.
Well, si
On Sunday, June 24, 2012 18:02:30 Benjamin Thaut wrote:
> The strange here is, I just want to return a reference at that point,
> why does it even want to initialize anything? After a hour of searching
> I managed to produce the above reduced sample, it all comes down to the
> @disable this() in ba
On Tuesday, 10 July 2012 at 01:41:29 UTC, bearophile wrote:
David Piepgrass:
This use case is pretty complex, so if I port this to D, I'd
probably just cast away const/immutable where necessary.
You are not the first person that says similar things. So D
docs need to stress more than casting
David Piepgrass:
This use case is pretty complex, so if I port this to D, I'd
probably just cast away const/immutable where necessary.
You are not the first person that says similar things. So D docs
need to stress more than casting away const/immutable in D is
rather more dangerous than doi
On 07/10/2012 01:57 AM, Geoffrey Biggs wrote:
On 10 July 2012 01:02, Timon Gehr wrote:
...
2.
- hash table
- opApply compacts the table if it is occupied too sparsely, in order
to speed up further iteration.
- toString iterates over all key/value pairs by the means of opApply.
Clearly, toS
On 10 July 2012 01:02, Timon Gehr wrote:
> 1.
>
> Most code that gives amortized complexity guarantees, eg:
>
> interface Map(K, V){
> V opIndex(K k) const;
> // ...
> }
>
> class SplayTree(K, V) : Map!(K, V) {
> // ???
> }
>
> 2.
>
> - hash table
> - opApply compacts the table if it i
On 07/10/2012 01:34 AM, Jonathan M Davis wrote:
On Tuesday, July 10, 2012 01:20:21 Timon Gehr wrote:
Now, with the current version of github, it unfortunately
seems to spit out a bunch of duplicate messages for the same error/warning
with templates in a number of cases, and _that_ should be fixe
On 07/10/2012 01:41 AM, Ali Çehreli wrote:
On 07/09/2012 04:20 PM, Timon Gehr wrote:
> On 07/10/2012 12:53 AM, Jonathan M Davis wrote:
>> dmd is generally good about not having
>> useless warnings.
>
> case 0,1: // warning: switch fallthrough (nonsense)
> case 2,3:
>
> This is the only k
On 07/09/2012 04:20 PM, Timon Gehr wrote:
> On 07/10/2012 12:53 AM, Jonathan M Davis wrote:
>> dmd is generally good about not having
>> useless warnings.
>
> case 0,1: // warning: switch fallthrough (nonsense)
> case 2,3:
>
> This is the only kind of warning I get (clearly a bug, and it is
> rep
On Tuesday, July 10, 2012 01:20:21 Timon Gehr wrote:
> > Now, with the current version of github, it unfortunately
> > seems to spit out a bunch of duplicate messages for the same error/warning
> > with templates in a number of cases, and _that_ should be fixed, but the
> > warnings themselves are
On 07/10/2012 12:53 AM, Jonathan M Davis wrote:
On Monday, July 09, 2012 23:00:39 Timon Gehr wrote:
On 07/09/2012 10:46 PM, bearophile wrote:
Jacob Carlborg:
import std.algorithm;
import std.range;
struct Foo {}
auto f = Foo();
auto foos = [f];
auto foo = foos.map!(x => "foo");
auto bar = f
On Monday, July 09, 2012 23:00:39 Timon Gehr wrote:
> On 07/09/2012 10:46 PM, bearophile wrote:
> > Jacob Carlborg:
> >> import std.algorithm;
> >> import std.range;
> >>
> >> struct Foo {}
> >>
> >> auto f = Foo();
> >> auto foos = [f];
> >> auto foo = foos.map!(x => "foo");
> >> auto bar = foo.
On Monday, July 09, 2012 22:41:57 Benjamin Thaut wrote:
> Clear uses the TypeInfo. The proposed functions should not be library
> functions but directly aviable from the compiler. Something like
> __postblit and __dtor but properly implemented.
Well, since all of the necessary information is in th
On Monday, July 09, 2012 22:43:19 Simen Kjaeraas wrote:
> On Sun, 08 Jul 2012 13:26:53 +0200, Jacob Carlborg wrote:
> > On 2012-07-07 20:49, Walter Bright wrote:
> >> On 7/7/2012 3:46 AM, Jacob Carlborg wrote:
> >>> Theoretically you should be able to just look at the documentation
> >>
> >> HAHA
On Monday, 9 July 2012 at 14:59:31 UTC, H. S. Teoh wrote:
On Mon, Jul 09, 2012 at 01:44:24PM +0200, Timon Gehr wrote:
On 07/09/2012 08:37 AM, Adam Wilson wrote:
>Object is now const-correct throughout D. This has been a
>dream for
>many of you. Today it is a reality.
PITA. Forced const can se
Andrei Alexandrescu wrote:
>> auto str = ["foo", "bar"].map!(x => x);
>> auto f = str.sort();
[...]
> The first error message is at clear as it goes:
> Error: r[i2] is not an lvalue
... and I panic on reading your answer, because I do not find a `r' nor
an `i2' in the source. Therefore "is not an
On Mon, Jul 9, 2012 at 4:24 PM, Stefan Scholl wrote:
> "bearophile" wrote:
>> I think Go is meant to be used mostly on 64 bit servers.
>
> There aren't many people using Go on 32 bit systems. That's why there is
> (was?) a big memory leak on these systems which wasn't caught early on.
There aren
"bearophile" wrote:
> I think Go is meant to be used mostly on 64 bit servers.
There aren't many people using Go on 32 bit systems. That's why there is
(was?) a big memory leak on these systems which wasn't caught early on.
On Monday, 9 July 2012 at 21:00:40 UTC, Timon Gehr wrote:
On 07/09/2012 10:46 PM, bearophile wrote:
Jacob Carlborg:
import std.algorithm;
import std.range;
struct Foo {}
auto f = Foo();
auto foos = [f];
auto foo = foos.map!(x => "foo");
auto bar = foo.chain("bar");
I suggest to always comp
On Monday, 9 July 2012 at 21:04:31 UTC, Andrei Alexandrescu wrote:
Instead of what? There is not transform() function in
std.algorithm.
Andrei
I was talking about this:
http://forum.dlang.org/thread/i1gnlo$18g0$1...@digitalmars.com?page=5#post-tdgxpwegpwaczardhvpx:40forum.dlang.org
If you
On 07/09/2012 11:04 PM, Andrei Alexandrescu wrote:
On 7/9/12 4:47 PM, Mehrdad wrote:
I mean like, why isn't it defined this way instead?
void transform(alias f, RI, RO)(RI r, RO output)
if(isInputRange!RI && isOutputRange!RO)
{
for(; !r.empty; r.popFront())
output.put(unaryFun!f(r.f
On 7/9/12 4:47 PM, Mehrdad wrote:
I mean like, why isn't it defined this way instead?
void transform(alias f, RI, RO)(RI r, RO output)
if(isInputRange!RI && isOutputRange!RO)
{
for(; !r.empty; r.popFront())
output.put(unaryFun!f(r.front));
}
Instead of what? There is not transform() function i
On 07/09/2012 10:46 PM, bearophile wrote:
Jacob Carlborg:
import std.algorithm;
import std.range;
struct Foo {}
auto f = Foo();
auto foos = [f];
auto foo = foos.map!(x => "foo");
auto bar = foo.chain("bar");
I suggest to always compile with "-wi -property".
Both -property and -w/-wi are
By the way, this thread is quite old.
getNext looks similar to what I wanted when first dealt with
ranges, but now it looks too heavyweight.
What happened to this proposal anyway? Was it deferred,
discarded, or what?
On 07/09/2012 10:23 PM, Ali Çehreli wrote:
On 07/09/2012 01:16 PM, Andrei Alexandrescu wrote:
> On 7/9/12 4:09 PM, Jacob Carlborg wrote:
>> auto str = ["foo", "bar"].map!(x => x);
>> auto f = str.sort();
>>
>> Results in:
>>
>> http://pastebin.com/BeePWQk9
>
> The first error message is
On Monday, 9 July 2012 at 20:25:58 UTC, Roman D. Boiko wrote:
On Monday, 9 July 2012 at 20:21:18 UTC, Mehrdad wrote:
Why isn't transform taking in both an input and an output
range in the first place? Of course they might be the same,
but they don't have to be.
Could you make a detailed propo
Jacob Carlborg:
import std.algorithm;
import std.range;
struct Foo {}
auto f = Foo();
auto foos = [f];
auto foo = foos.map!(x => "foo");
auto bar = foo.chain("bar");
I suggest to always compile with "-wi -property".
chain() takes two iterables. This means both arguments need to
yield the sa
On Sun, 08 Jul 2012 13:26:53 +0200, Jacob Carlborg wrote:
On 2012-07-07 20:49, Walter Bright wrote:
On 7/7/2012 3:46 AM, Jacob Carlborg wrote:
Theoretically you should be able to just look at the documentation
HAHAHAHAHAHAHAHAHAHAHA!!!
Yeah, I know how you feel about documentation.
Am 09.07.2012 19:36, schrieb Jonathan M Davis:
On Sunday, July 08, 2012 15:23:41 Benjamin Thaut wrote:
While writing certain parts of my own little standard library
(containers etc) I had to notice that D has a overcomplicated way of
especially postblitting and destructing structs. By overcompli
On Monday, July 09, 2012 22:25:57 Roman D. Boiko wrote:
> On Monday, 9 July 2012 at 20:21:18 UTC, Mehrdad wrote:
> > that's not what I meant, but I think another solution is better
> > anyway:
> >
> > Why isn't transform taking in both an input and an output range
> > in the first place? Of course
On Monday, 9 July 2012 at 20:21:18 UTC, Mehrdad wrote:
that's not what I meant, but I think another solution is better
anyway:
Why isn't transform taking in both an input and an output range
in the first place? Of course they might be the same, but they
don't have to be.
Could you make a de
On 07/09/2012 01:16 PM, Andrei Alexandrescu wrote:
> On 7/9/12 4:09 PM, Jacob Carlborg wrote:
>> auto str = ["foo", "bar"].map!(x => x);
>> auto f = str.sort();
>>
>> Results in:
>>
>> http://pastebin.com/BeePWQk9
>
> The first error message is at clear as it goes:
>
> Error: r[i2] is not an lval
On Monday, 9 July 2012 at 19:52:04 UTC, Andrei Alexandrescu wrote:
On 7/9/12 3:30 PM, Mehrdad wrote:
I agree. My alternative would be to abandon similar 'hasXYZ'
stuff
(which doesn't convey the picture and looks hacky), and
instead formally
define what those are, like I/O range. Sounds good/ba
On Monday, July 09, 2012 22:09:54 Jacob Carlborg wrote:
> Almost every time I'm trying to use std.algorithm I run into some kind
> of error, for what seems to be fairly trivial and what one would expect
> to work. It feels like I'm constantly fighting with std.algorithm. For
> example:
>
> import
On 7/9/12 4:09 PM, Jacob Carlborg wrote:
Almost every time I'm trying to use std.algorithm I run into some kind
of error, for what seems to be fairly trivial and what one would expect
to work. It feels like I'm constantly fighting with std.algorithm. For
example:
import std.algorithm;
import std
Almost every time I'm trying to use std.algorithm I run into some kind
of error, for what seems to be fairly trivial and what one would expect
to work. It feels like I'm constantly fighting with std.algorithm. For
example:
import std.algorithm;
import std.range;
struct Foo {}
auto f = Foo();
On 07/09/2012 09:46 PM, Mehrdad wrote:
On Monday, 9 July 2012 at 19:30:25 UTC, Jonathan M Davis wrote:
Except that how output ranges are written to and an input range with
assignable elements are fundamentally different. Output ranges use
put, which _might_ write to each individual element, or i
On 07/09/2012 09:52 PM, Timon Gehr wrote:
On 07/09/2012 09:46 PM, Mehrdad wrote:
On Monday, 9 July 2012 at 19:30:25 UTC, Jonathan M Davis wrote:
Except that how output ranges are written to and an input range with
assignable elements are fundamentally different. Output ranges use
put, which _mi
On 7/9/12 3:30 PM, Mehrdad wrote:
I agree. My alternative would be to abandon similar 'hasXYZ' stuff
(which doesn't convey the picture and looks hacky), and instead formally
define what those are, like I/O range. Sounds good/bad?
You may want to just spell it clearly.
So right now we have the
On Monday, 9 July 2012 at 07:53:41 UTC, David Piepgrass wrote:
I don't know if this proposal went anywhere since 2010, but it
occurs to me that there is a hidden danger here. alloca will
allocate a sequence of separate temporaries. If the collection
is large, the stack will overflow, and the cl
On Monday, 9 July 2012 at 19:30:25 UTC, Jonathan M Davis wrote:
Except that how output ranges are written to and an input range
with assignable elements are fundamentally different. Output
ranges use put, which _might_ write to each individual element,
or it may just append to the output range
On Monday, 9 July 2012 at 19:22:39 UTC, Andrei Alexandrescu wrote:
But that works against your goal of simplifying things.
If by "simplification" you mean "fewer methods to call", then yes.
If by "simplification" you mean "easier to understand", then no
-- not here.
Having a different (but st
On Monday, July 09, 2012 12:28:32 Adam Wilson wrote:
> When I mentioned this post on IRC he specifically requested to be left out
> of it. So I did. However, I personally feel that his willingness to get in
> there and swing his +50 Hammer of Merging did in fact have a big impact on
> the successes
On Monday, July 09, 2012 21:19:46 Mehrdad wrote:
> On Monday, 9 July 2012 at 18:33:26 UTC, jerro wrote:
> > On Monday, 9 July 2012 at 16:22:05 UTC, Mehrdad wrote:
> >> Perhaps if you could show an actual example of what you expect
> >> to be able to do, that would make things clearer?
> >
> > It i
On Mon, 09 Jul 2012 12:24:12 -0700, Jonathan M Davis
wrote:
On Monday, July 09, 2012 10:01:25 Andrei Alexandrescu wrote:
On 7/9/12 3:52 AM, Jonathan M Davis wrote:
> On Sunday, July 08, 2012 23:37:29 Adam Wilson wrote:
>> First I want to mention two people who really helped make this day
>>
On 7/9/12 3:03 PM, Mehrdad wrote:
Sure, we all agree that a multi-pass range is also a one-pass range. I
don't have a problem with that. But if you only use the one-pass range
aspect, that doesn't mean it has to use the same syntax as the
multi-pass range aspect.
But that works against your goa
On Monday, July 09, 2012 10:01:25 Andrei Alexandrescu wrote:
> On 7/9/12 3:52 AM, Jonathan M Davis wrote:
> > On Sunday, July 08, 2012 23:37:29 Adam Wilson wrote:
> >> First I want to mention two people who really helped make this day
> >> happen.
> >
> > Andrei is the one who was doing most of th
On Monday, 9 July 2012 at 18:33:26 UTC, jerro wrote:
On Monday, 9 July 2012 at 16:22:05 UTC, Mehrdad wrote:
Perhaps if you could show an actual example of what you expect
to be able to do, that would make things clearer?
It is useful to be able to write an algorithm that both reads
and writes
On Monday, 9 July 2012 at 18:51:40 UTC, Andrei Alexandrescu wrote:
If that's the case, I'd hate to tell you this, but _unless_
you're planning on removing the notion of input/output ranges
(and perhaps adding single-pass/multi-pass), you're doing it
wrong. :-)
Given the smart-aleck nature of
On 7/9/12 12:04 PM, Mehrdad wrote:
On Monday, 9 July 2012 at 15:48:35 UTC, Andrei Alexandrescu wrote:
On 7/9/12 11:35 AM, Mehrdad wrote:
If something is both an input range and an output range, then sure, it
can have that capability. But being able to write to something is
_orthogonal_ to wheth
On Monday, July 09, 2012 11:53:05 H. S. Teoh wrote:
> I'm wondering if it makes any sense to have _also_ have non-const
> versions of things like toString, for objects that want to implement
> caching. So in contexts where const is not important, you can have
> caching, network access, whatever you
On Mon, Jul 09, 2012 at 08:07:22PM +0200, Timon Gehr wrote:
> On 07/09/2012 07:49 PM, Andrei Alexandrescu wrote:
> >On 7/9/12 12:34 PM, David Piepgrass wrote:
> >>I guess D does not have 'mutable' (like C++) to override const on
> >>methods?
> >
> >It doesn't, which makes life difficult for certain
On Monday, 9 July 2012 at 16:22:05 UTC, Mehrdad wrote:
Perhaps if you could show an actual example of what you expect
to be able to do, that would make things clearer?
It is useful to be able to write an algorithm that both reads
and writes range elements. There are plenty of use cases for
that
On Monday, 9 July 2012 at 17:50:08 UTC, Gor Gyolchanyan wrote:
I mean compile-time and run-time information like:
* What are the types this one can implicitly/explicitly
convert to/from?
* What are the instances of this template?
* What modules are being compiled and what modules do they
im
On 07/09/2012 07:49 PM, Andrei Alexandrescu wrote:
On 7/9/12 12:34 PM, David Piepgrass wrote:
I guess D does not have 'mutable' (like C++) to override const on
methods?
It doesn't, which makes life difficult for certain idioms. On the
upside, you can assume more than C++ does about immutable d
On 07/09/2012 07:58 PM, Mehrdad wrote:
On Monday, 9 July 2012 at 17:50:08 UTC, Gor Gyolchanyan wrote:
making D the first ever hybrid static-dynamic typed language
s/D/C#/g
s/C#/presumably some lisp dialect/g
On Monday, July 09, 2012 21:49:57 Gor Gyolchanyan wrote:
> On Mon, Jul 9, 2012 at 9:37 PM, Jonathan M Davis wrote:
> > On Monday, July 09, 2012 20:42:47 Gor Gyolchanyan wrote:
> > > Currently, code introspection in D is way worse, then it should be. And
> > > this is true for both compile-time and
On Monday, 9 July 2012 at 17:50:08 UTC, Gor Gyolchanyan wrote:
making D the first ever hybrid static-dynamic typed language
s/D/C#/g
On 7/9/12 12:34 PM, David Piepgrass wrote:
I guess D does not have 'mutable' (like C++) to override const on
methods?
It doesn't, which makes life difficult for certain idioms. On the
upside, you can assume more than C++ does about immutable data.
Caching anything slow-to-compute is my typi
On Mon, Jul 9, 2012 at 9:37 PM, Jonathan M Davis wrote:
> On Monday, July 09, 2012 20:42:47 Gor Gyolchanyan wrote:
> > Currently, code introspection in D is way worse, then it should be. And
> > this is true for both compile-time and run-time introspection.
> > Moreover, the available stuff is bug
On Monday, July 09, 2012 20:42:47 Gor Gyolchanyan wrote:
> Currently, code introspection in D is way worse, then it should be. And
> this is true for both compile-time and run-time introspection.
> Moreover, the available stuff is bugged out in the most critical places.
> I'd like to hear what peop
On Sunday, July 08, 2012 15:23:41 Benjamin Thaut wrote:
> While writing certain parts of my own little standard library
> (containers etc) I had to notice that D has a overcomplicated way of
> especially postblitting and destructing structs. By overcomplicated I
> mean that you don't have any other
On Monday, July 09, 2012 18:34:14 David Piepgrass wrote:
> I guess D does not have 'mutable' (like C++) to override const on
> methods?
No, const is actually const. You can't modify anything which is const through
that reference (or pointer) to that data. Casting away const and mutating
somethin
On Monday, 9 July 2012 at 17:06:44 UTC, H. S. Teoh wrote:
In this case, it doesn't really make a difference in practice
In my case, the extra lookahead only happens when the lexer
sees string prefixes like "4..", which doesn't usually happen
at the end of a line. In all other cases, no lookahea
On Monday, 9 July 2012 at 16:58:26 UTC, nazriel wrote:
David (klickverbot), are examples working for you now? (Back -
Forward transition)?
Yes, they are indeed.
Keep up the good work,
David
On Sun, Jul 08, 2012 at 09:59:38AM +0200, Mehrdad wrote:
[...]
> Right, it's trivial to fix with an extra state variable like
> 'consumedtrailingdot'.
This is eventually what I did in my own D lexer.
Well, actually, I kinda blasted an ant with an M16... I had a queue of
backlogged tokens which ge
(or it didn't happen :P)
On Monday, 9 July 2012 at 11:35:59 UTC, Paulo Pinto wrote:
On Thursday, 5 July 2012 at 16:26:02 UTC, Andrei Alexandrescu
wrote:
Check this out: on http://dlang.org you can actually click in
the code example and edit it, then click "Run" and pronto, you
see the output!
Damian is actively worki
On 07/09/2012 06:15 PM, Benjamin Thaut wrote:
No one has a opinion on this?
The features should obviously be exposed. I was astonished that
__postblit does not work if there is no explicit postblit defined.
On 07/09/2012 06:47 PM, Mehrdad wrote:
On Monday, 9 July 2012 at 16:42:52 UTC, Timon Gehr wrote:
On 07/09/2012 06:04 PM, Mehrdad wrote:
With your design you need to add something extra to allow writing to
elements of a single-pass range.
...
That capability is simply /not needed/ when your /
On Monday, 9 July 2012 at 16:50:44 UTC, Timon Gehr wrote:
On 07/09/2012 11:14 AM, Mehrdad wrote:
element
Link to exact post please?
On Monday, 9 July 2012 at 16:42:52 UTC, Timon Gehr wrote:
On 07/09/2012 06:04 PM, Mehrdad wrote:
With your design you need to add something extra to allow
writing to elements of a single-pass range.
...
That capability is simply /not needed/ when your /only/
contract is that something is an
On 07/09/2012 06:27 PM, Mehrdad wrote:
On Monday, 9 July 2012 at 16:25:06 UTC, Timon Gehr wrote:
I do not see why the notion of 'input range' should restrict the kinds
of elements that are accessed by iterating the range. It would be
downright silly.
Yes... but when did I ever impose anything
Currently, code introspection in D is way worse, then it should be. And
this is true for both compile-time and run-time introspection.
Moreover, the available stuff is bugged out in the most critical places.
I'd like to hear what people think would be a better way to handle
code introspection.
--
On Monday, 9 July 2012 at 16:02:38 UTC, Timon Gehr wrote:
On 07/09/2012 05:00 PM, H. S. Teoh wrote:
On Mon, Jul 09, 2012 at 01:44:24PM +0200, Timon Gehr wrote:
On 07/09/2012 08:37 AM, Adam Wilson wrote:
Object is now const-correct throughout D. This has been a
dream for many of you. Today it i
On 07/09/2012 06:17 PM, Mehrdad wrote:
On Monday, 9 July 2012 at 16:06:57 UTC, Timon Gehr wrote:
Consider the possibility that this electrical engineer might be a
plumber as well.
Yes, so if you expect him to be, then you should ask him "are you a
plumber?" (i.e. output range?)
But what you
On Monday, 9 July 2012 at 16:25:06 UTC, Timon Gehr wrote:
I do not see why the notion of 'input range' should restrict
the kinds of elements that are accessed by iterating the range.
It would be downright silly.
Yes... but when did I ever impose anything on the /elements/? I
never even used t
Perhaps if you could show an actual example of what you expect to
be able to do, that would make things clearer?
No one has a opinion on this?
On Monday, 9 July 2012 at 16:06:57 UTC, Timon Gehr wrote:
Consider the possibility that this electrical engineer might be
a plumber as well.
Yes, so if you expect him to be, then you should ask him "are you
a plumber?" (i.e. output range?)
But what you're asking him right now is, "hey, ca
On 07/09/2012 06:05 PM, Mehrdad wrote:
With your design you need to add something extra to allow writing to
elements of a single-pass range.
If that's the case, I'd hate to tell you this, but _unless_
you're planning on removing the notion of input/output ranges
(and perhaps adding single-pass/
With your design you need to add something extra to allow
writing to elements of a single-pass range.
If that's the case, I'd hate to tell you this, but _unless_
you're planning on removing the notion of input/output ranges
(and perhaps adding single-pass/multi-pass), you're doing it
wrong. :-)
On 07/09/2012 05:00 PM, H. S. Teoh wrote:
On Mon, Jul 09, 2012 at 01:44:24PM +0200, Timon Gehr wrote:
On 07/09/2012 08:37 AM, Adam Wilson wrote:
Object is now const-correct throughout D. This has been a dream for
many of you. Today it is a reality.
PITA. Forced const can severely harm a code
On Monday, 9 July 2012 at 15:48:35 UTC, Andrei Alexandrescu wrote:
On 7/9/12 11:35 AM, Mehrdad wrote:
If something is both an input range and an output range, then
sure, it
can have that capability. But being able to write to something
is
_orthogonal_ to whether you can read from it.
That is
On Monday, 9 July 2012 at 15:34:35 UTC, Mehrdad wrote:
On Monday, 9 July 2012 at 15:16:52 UTC, Andrei Alexandrescu
wrote:
the only primitive of output ranges is "put".
Andrei
Sorry? I don't know what you mean
template isOutputRange(R,E)
Returns true if R is an output range for elements of
On 7/9/12 11:35 AM, Mehrdad wrote:
If something is both an input range and an output range, then sure, it
can have that capability. But being able to write to something is
_orthogonal_ to whether you can read from it.
That is the case right now. The point is, with your design you need to
add s
On Monday, 9 July 2012 at 15:34:35 UTC, Mehrdad wrote:
The latter point is moot here, and the former is _clearly_ not
something an "input range" should have, because it's a notion
of output...
Er, let me rephrase that:
The former is _clearly_ not a property of "input ranges".
If something is
On Monday, 9 July 2012 at 15:34:35 UTC, Mehrdad wrote:
Think: CD burning.
A good comparison:
Single-pass output ranges: an output range that writes to a CD,
DVD, etc.
Multi-pass output ranges: an output range that writes to a tape,
hard disk, etc.
On Monday, 9 July 2012 at 15:16:52 UTC, Andrei Alexandrescu wrote:
On 7/9/12 10:52 AM, Mehrdad wrote:
On Monday, 9 July 2012 at 14:48:05 UTC, Andrei Alexandrescu
wrote:
I think it's about the notion of "input range" that is
confusing, a
better name would be "single-pass range". One should be
p
On 7/9/12 10:52 AM, Mehrdad wrote:
On Monday, 9 July 2012 at 14:48:05 UTC, Andrei Alexandrescu wrote:
I think it's about the notion of "input range" that is confusing, a
better name would be "single-pass range". One should be perfectly
capable of assigning to elements of an input range. A built-
On 7/9/12 11:13 AM, David Piepgrass wrote:
Thanks for doing this! I haven't contributed yet, but it was worrisome
hearing about various pull requests languishing for long periods. Now
maybe I should go learn how to use git...
You definitely should get to the point where you can contribute to D
Thanks for doing this! I haven't contributed yet, but it was
worrisome hearing about various pull requests languishing for
long periods. Now maybe I should go learn how to use git...
On Monday, 9 July 2012 at 07:56:40 UTC, Jonathan M Davis wrote:
As far as I'm concerned, 3.minutes() is a prime
On Mon, Jul 09, 2012 at 01:44:24PM +0200, Timon Gehr wrote:
> On 07/09/2012 08:37 AM, Adam Wilson wrote:
> >Object is now const-correct throughout D. This has been a dream for
> >many of you. Today it is a reality.
>
> PITA. Forced const can severely harm a code base that wants to be
> flexible --
On Monday, 9 July 2012 at 14:48:05 UTC, Andrei Alexandrescu wrote:
I think it's about the notion of "input range" that is
confusing, a better name would be "single-pass range". One
should be perfectly capable of assigning to elements of an
input range. A built-in slice is an input range.
Andr
1 - 100 of 139 matches
Mail list logo
