Walter Bright wrote:
The purpose of T[new] was to solve the problems T[] had with passing T[]
to a function and then the function resizes the T[]. What happens with
the original?
The solution we came up with was to create a third array type, T[new],
which was a reference type.
Andrei had th
Robert Jacques Wrote:
>
> DMD 2.035 didn't require any patches from DMD 2.034 for DFL. I've created
> a list with both you and dolive for future reference.
Many... thanks!!
Could somebody explain memory rules in class inheriting?
The following code illustrates my problem, look at 'main' function:
//
module window;
private import base;
private import structs;
private static import user32;
private static import kernel32;
pri
Robert Jacques дµ½:
> On Mon, 19 Oct 2009 00:53:48 -0400, dolive wrote:
>
> > Robert Jacques ôµ½:
> >
> >> On Sun, 18 Oct 2009 23:51:37 -0400, Sam Hu
> >> wrote:
> >> > Robert Jacques Wrote:
> >> >
> >> >> > Do you have a DFL for dmd2.035 ?
> >> >> > thank you very much !
> >> >> >
> >
dolive wrote:
Denis Koroskin дµ½:
On Sat, 17 Oct 2009 22:55:44 +0400, dolive wrote:
Eldar Insafutdinov �´µ½:
dolive Wrote:
bug fix is slower,should speed up the progress, fix more than 200 a
month.
Very much looking forward to, thanks all !
dolive
What have you personally don
Moritz Warning:
> > foreach(key; aa.keys)
> >if(Test(key))
> > aa.remove(key);
>
> It's undefined behavior.
> You shouldn't try to mutate the aa while iterating.
> I hope that will be fixed.
> It took me some time to find this out.
In Python:
>>> d = {1:2, 3:4}
>>> for k in d: del d[k
On 2009-10-17 22:11:56 +0200, "Nick Sabalausky" said:
Only on 64-bit systems. Which are already ridiculously fast anyway. So what
if they get some more performance? They already have gobs of performance to
spare. On a 32-bit system it changes the programs performance down to "It
don't f** work a
Don дµ½:
> dolive wrote:
> > Denis Koroskin дµ½:
> >
> >> On Sat, 17 Oct 2009 22:55:44 +0400, dolive wrote:
> >>
> >>> Eldar Insafutdinov ôµ½:
> >>>
> dolive Wrote:
>
> > bug fix is slower,should speed up the progress, fix more than 200 a
> month.
> > Very much lo
Walter Bright Wrote:
> The purpose of T[new] was to solve the problems T[] had with passing T[]
> to a function and then the function resizes the T[]. What happens with
> the original?
Why do you need such feature built into language? So many proposals to
implement this feature and that featur
dolive wrote:
Don дµ½:
dolive wrote:
Denis Koroskin дµ½:
On Sat, 17 Oct 2009 22:55:44 +0400, dolive wrote:
Eldar Insafutdinov �´µ½:
dolive Wrote:
bug fix is slower,should speed up the progress, fix more than 200 a
month.
Very much looking forward to, thanks all !
dolive
W
Andrei Alexandrescu Wrote:
> Paradoxically this seems to be conducive to subtle efficiency issues.
> For example, consider:
>
> int[new] a;
> ...
> a = [1, 2, 3];
>
> What should that do?
a = new Appender!int([1,2,3]);
What you describe is more like StringBuilder, and, yes, things like that
Can you author please be able to upgrade it to latest version of d2 ?
thank you very much !
dolive
Don дµ½:
> dolive wrote:
> > Don дµ½:
> >
> >> dolive wrote:
> >>> Denis Koroskin дµ½:
> >>>
> On Sat, 17 Oct 2009 22:55:44 +0400, dolive wrote:
>
> > Eldar Insafutdinov ôµ½:
> >
> >> dolive Wrote:
> >>
> >>> bug fix is slower,should speed up the progress, f
"BCS" wrote in message
news:a6268ffb8018cc1e47bb9fc...@news.digitalmars.com...
> Hello Nick,
>
>> "BCS" wrote in message
>>
>>> If mine did that I'd shoot him (a scorching e-mail :)
>>>
>> You should both feel lucky. The best I had was a class where we filled
>> in the bodies of a handful of sma
Walter Bright Wrote:
> The purpose of T[new] was to solve the problems T[] had with passing T[]
> to a function and then the function resizes the T[]. What happens with
> the original?
>
> The solution we came up with was to create a third array type, T[new],
> which was a reference type.
>
>
Ary Borenszweig wrote:
I remember seeing a lot of CTFE code that created a dynamic array and
then appended stuff to it, like for example to build a list of prime
numbers. Would that still work with ArrayBuilder?
Probably not. But you can rewrite:
a ~= stuff;
as:
a = a ~ stuff;
to make
Try compiling with -gc and run it under the debugger.
Ellery Newcomer wrote:
ANTLR has pretty good support for backtracking, so writing a D grammar
for it wasn't too difficult, but then the resultant performance isn't
anything near what I'd like.
My recommendation is to forget about parser generators and just build
one by hand. They're easy to wr
BCS wrote:
(BTW I'm taking (but haven't yet finished) a compilers class so I might
be missing something)
That's one of my gripes about compiler classes, they expend enormous
effort on the simplest part of a compiler - the lexer/parser.
In working on the D compiler, I easily spend less than 1
Nick Sabalausky wrote:
(Cue Walter reminiscing about how great Caltech was... ;) )
The only software course I took at Caltech was a Fortran one. I can't
remember anything about it .
Walter Bright Wrote:
> Ellery Newcomer wrote:
> > ANTLR has pretty good support for backtracking, so writing a D grammar
> > for it wasn't too difficult, but then the resultant performance isn't
> > anything near what I'd like.
>
> My recommendation is to forget about parser generators and just b
On 2009-10-18 20:01:26 +0200, language_fan said:
Sun, 18 Oct 2009 16:35:53 +0200, Fawzi Mohamed thusly wrote:
On 2009-10-18 11:32:07 +0200, language_fan said:
Sat, 17 Oct 2009 22:56:44 -0400, Just Visiting thusly wrote:
I won't deny that for certain people 32-bit systems are still
perfec
On Mon, Oct 19, 2009 at 2:48 AM, Walter Bright
wrote:
> Ary Borenszweig wrote:
>>
>> I remember seeing a lot of CTFE code that created a dynamic array and then
>> appended stuff to it, like for example to build a list of prime numbers.
>> Would that still work with ArrayBuilder?
>
> Probably not.
On Mon, 19 Oct 2009 05:16:45 +0400, Andrei Alexandrescu
wrote:
dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
article
3. A T[new] should be implicitly convertible to a slice. For
example:
auto foo = someFunctionThatReturnsTnew();
// foo is a T[new].
Zarathustra wrote:
> Could somebody explain memory rules in class inheriting?
> The following code illustrates my problem, look at 'main' function:
Posts like this belong on d.learn.
> //
> module window;
>
> private import base;
> private import str
Mon, 19 Oct 2009 13:22:34 +0200, Fawzi Mohamed thusly wrote:
> On 2009-10-18 20:01:26 +0200, language_fan said:
>> Sun, 18 Oct 2009 16:35:53 +0200, Fawzi Mohamed thusly wrote:
>>
>> Also note that cache size is heavily constrained and larger
>> binaries will fill it with less code. This alone ca
Sun, 18 Oct 2009 18:01:51 -0400, bearophile thusly wrote:
> Denis Koroskin:
>
>>Why would you want to port C code to D, if you can easily interface with
>>it?<
>
> First of all you have to consider programmer experience, they know C, so
> keeping the language backwards compatible with C helps th
This discussion originated in the T[new] thread, but I think it deserves its own
thread.
== Quote from Denis Koroskin (2kor...@gmail.com)'s article
> An Array!(T) is really just a different name to a T[new]. You'll have the
> same problem explaining difference between Array!(T) and T[].
> But you
dsimcha wrote:
This discussion originated in the T[new] thread, but I think it deserves its own
thread.
== Quote from Denis Koroskin (2kor...@gmail.com)'s article
An Array!(T) is really just a different name to a T[new]. You'll have the
same problem explaining difference between Array!(T) and T
Denis Koroskin wrote:
On Mon, 19 Oct 2009 17:13:46 +0400, dsimcha wrote:
This discussion originated in the T[new] thread, but I think it
deserves its own
thread.
== Quote from Denis Koroskin (2kor...@gmail.com)'s article
An Array!(T) is really just a different name to a T[new]. You'll have
On Mon, 19 Oct 2009 17:13:46 +0400, dsimcha wrote:
This discussion originated in the T[new] thread, but I think it deserves
its own
thread.
== Quote from Denis Koroskin (2kor...@gmail.com)'s article
An Array!(T) is really just a different name to a T[new]. You'll have
the
same problem exp
== Quote from Don (nos...@nospam.com)'s article
> Denis Koroskin wrote:
> > On Mon, 19 Oct 2009 17:13:46 +0400, dsimcha wrote:
> >
> >> This discussion originated in the T[new] thread, but I think it
> >> deserves its own
> >> thread.
> >>
> >> == Quote from Denis Koroskin (2kor...@gmail.com)'s ar
== Quote from downs (default_357-l...@yahoo.de)'s article
> Walter Bright wrote:
> > Ary Borenszweig wrote:
> >> I remember seeing a lot of CTFE code that created a dynamic array and
> >> then appended stuff to it, like for example to build a list of prime
> >> numbers. Would that still work with A
Walter Bright wrote:
> Ary Borenszweig wrote:
>> I remember seeing a lot of CTFE code that created a dynamic array and
>> then appended stuff to it, like for example to build a list of prime
>> numbers. Would that still work with ArrayBuilder?
>
> Probably not. But you can rewrite:
>
> a ~= stu
Walter Bright wrote:
> BCS wrote:
>> (BTW I'm taking (but haven't yet finished) a compilers class so I
>> might be missing something)
>
> That's one of my gripes about compiler classes, they expend enormous
> effort on the simplest part of a compiler - the lexer/parser.
>
> In working on the D co
dsimcha wrote:
== Quote from Don (nos...@nospam.com)'s article
Denis Koroskin wrote:
On Mon, 19 Oct 2009 17:13:46 +0400, dsimcha wrote:
This discussion originated in the T[new] thread, but I think it
deserves its own
thread.
== Quote from Denis Koroskin (2kor...@gmail.com)'s article
An Arr
Walter Bright írta:
The purpose of T[new] was to solve the problems T[] had with passing T[]
to a function and then the function resizes the T[]. What happens with
the original?
I've tried to follow the T[], T[new], T+slice discussion, but i'm lost,
I don't think if it's a good idea, to extend
Andrei Alexandrescu, el 18 de octubre a las 20:16 me escribiste:
> Here's what I wrote to Walter:
>
>
> I'm going to suggest something terrible - let's get rid of T[new]. I
> know it's difficult to throw away work you've already done, but
> really things with T[new] start to l
On Mon, 19 Oct 2009 18:57:45 +0400, Leandro Lucarella
wrote:
Andrei Alexandrescu, el 18 de octubre a las 20:16 me escribiste:
Here's what I wrote to Walter:
I'm going to suggest something terrible - let's get rid of T[new]. I
know it's difficult to throw away work you'v
Leandro Lucarella, el 19 de octubre a las 11:57 me escribiste:
> slice.dup should return an array.
To avoid making the language aware of the array type, slice.dup can be
removed and use an array constructor instead:
auto a = slice.dup;
should be:
auto a = array!T(slice);
This way, I think the
Leandro Lucarella wrote:
Andrei Alexandrescu, el 18 de octubre a las 20:16 me escribiste:
Here's what I wrote to Walter:
I'm going to suggest something terrible - let's get rid of T[new]. I
know it's difficult to throw away work you've already done, but
really things with T
Andrei Alexandrescu, el 19 de octubre a las 08:38 me escribiste:
> For relatively large chunks of memory, the GC keeps a control block.
> We could add a member size_t requestedSize that keeps the size that
> was requested with an allocation/reallocation call. The GC can take
> initiative in overall
Leandro Lucarella, el 19 de octubre a las 12:13 me escribiste:
> Leandro Lucarella, el 19 de octubre a las 11:57 me escribiste:
> > slice.dup should return an array.
>
> To avoid making the language aware of the array type, slice.dup can be
> removed and use an array constructor instead:
>
> auto
Leandro Lucarella wrote:
Andrei Alexandrescu, el 19 de octubre a las 08:38 me escribiste:
For relatively large chunks of memory, the GC keeps a control block.
We could add a member size_t requestedSize that keeps the size that
was requested with an allocation/reallocation call. The GC can take
i
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> Leandro Lucarella wrote:
> > Andrei Alexandrescu, el 19 de octubre a las 08:38 me escribiste:
> >> For relatively large chunks of memory, the GC keeps a control block.
> >> We could add a member size_t requestedSize that
Andrei Alexandrescu, el 19 de octubre a las 10:18 me escribiste:
> Leandro Lucarella wrote:
> >Andrei Alexandrescu, el 18 de octubre a las 20:16 me escribiste:
> >>Here's what I wrote to Walter:
> >>
> >>
> >>I'm going to suggest something terrible - let's get rid of T[new]. I
>
On 2009-10-19 15:04:23 +0200, language_fan said:
Mon, 19 Oct 2009 13:22:34 +0200, Fawzi Mohamed thusly wrote:
On 2009-10-18 20:01:26 +0200, language_fan said:
Sun, 18 Oct 2009 16:35:53 +0200, Fawzi Mohamed thusly wrote:
Also note that cache size is heavily constrained and larger
binaries wi
Andrei Alexandrescu, el 19 de octubre a las 10:33 me escribiste:
> Leandro Lucarella wrote:
> >Andrei Alexandrescu, el 19 de octubre a las 08:38 me escribiste:
> >>For relatively large chunks of memory, the GC keeps a control block.
> >>We could add a member size_t requestedSize that keeps the size
dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
Leandro Lucarella wrote:
Andrei Alexandrescu, el 19 de octubre a las 08:38 me escribiste:
For relatively large chunks of memory, the GC keeps a control block.
We could add a member size_t requestedSize t
Leandro Lucarella wrote:
Andrei Alexandrescu, el 19 de octubre a las 10:18 me escribiste:
2 types should be provided: array and slice.
array is a *real* type, storing and owning memory, it should be something
like this (conceptually):
class array(T)
{
size_t length;
size_t capa
Andrei Alexandrescu wrote:
> Leandro Lucarella wrote:
>> Andrei Alexandrescu, el 19 de octubre a las 10:18 me escribiste:
2 types should be provided: array and slice.
array is a *real* type, storing and owning memory, it should be
something like this (conceptually):
c
Hello Yigal,
I think that Arrays and AAs need to be removed from the language. I
prefer to have a collections framework as part of Phobos without
special cases in the language for specific containers.
If it can be assured that all the current array ops will get inlined is all
cases and can re
Since there has been a lot of discussion here lately about how AAs and
ArrayBuilders should be implemented, we should set up a website where people
can contribute different candidate implementations and comment on them. It's
much easier to know whether something is a good idea when you have a work
Andrei Alexandrescu, el 19 de octubre a las 11:16 me escribiste:
> >>>I'm missing something? Why this shouldn't work?
> >>It may work, but I was unable to pull it off reasonably well.
> >
> >What problems did you find?
>
> I thought I explained that above and in several other posts. I have
> the f
Denis Koroskin wrote:
On Mon, 19 Oct 2009 20:16:50 +0400, Andrei Alexandrescu
wrote:
I thought I explained that above and in several other posts. I have
the feeling this is going in circles, but let me add one more thing.
People would want to have a reasonable way of choosing between T[new]
On Mon, 19 Oct 2009 20:16:50 +0400, Andrei Alexandrescu
wrote:
I thought I explained that above and in several other posts. I have the
feeling this is going in circles, but let me add one more thing. People
would want to have a reasonable way of choosing between T[new] and T[].
The diffe
Hello Walter,
BCS wrote:
(BTW I'm taking (but haven't yet finished) a compilers class so I
might be missing something)
That's one of my gripes about compiler classes, they expend enormous
effort on the simplest part of a compiler - the lexer/parser.
In working on the D compiler, I easily sp
Johan Granberg wrote:
I think you are seeing a larger problem than their is. But consider this,
who is D a language for, is it for beginers only? advanced users only? or
everyone, if it is a language for everyone don't complicate the language
for the advanced users by rejecting nice syntax just b
dsimcha wrote:
Since there has been a lot of discussion here lately about how AAs and
ArrayBuilders should be implemented, we should set up a website where people
can contribute different candidate implementations and comment on them. It's
much easier to know whether something is a good idea whe
Leandro Lucarella wrote:
Andrei Alexandrescu, el 19 de octubre a las 11:16 me escribiste:
I'm missing something? Why this shouldn't work?
It may work, but I was unable to pull it off reasonably well.
What problems did you find?
I thought I explained that above and in several other posts. I ha
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> dsimcha wrote:
> > Since there has been a lot of discussion here lately about how AAs and
> > ArrayBuilders should be implemented, we should set up a website where people
> > can contribute different candidate implementat
I just wrote this to Sean and Walter and subsequently discussed it with
Walter. Walter thinks this should work. Does anyone have the time and
inclination to test this out? It would involve hacking into druntime's
implementation of ~= (I'm not sure what the function name is). I'd
really apprecia
Denis Koroskin wrote:
On Mon, 19 Oct 2009 18:57:45 +0400, Leandro Lucarella
wrote:
Andrei Alexandrescu, el 18 de octubre a las 20:16 me escribiste:
Here's what I wrote to Walter:
I'm going to suggest something terrible - let's get rid of T[new]. I
know it's difficult to
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> I just wrote this to Sean and Walter and subsequently discussed it with
> Walter. Walter thinks this should work. Does anyone have the time and
> inclination to test this out? It would involve hacking into druntime's
> im
dsimcha Wrote:
> If anyone can think of any more, please let me know. Also, just thought of
> this
> now: I wonder if it would make sense to use some polymorphism tricks (AA
> operations are slow enough that an extra pointer dereference or virtual
> function
> call isn't going to make or break
Andrei Alexandrescu, el 19 de octubre a las 12:40 me escribiste:
> Leandro Lucarella wrote:
> >Andrei Alexandrescu, el 19 de octubre a las 11:16 me escribiste:
> >I'm missing something? Why this shouldn't work?
> It may work, but I was unable to pull it off reasonably well.
> >>>What proble
== Quote from Jerry Quinn (jlqu...@optonline.net)'s article
> dsimcha Wrote:
> > If anyone can think of any more, please let me know. Also, just thought of
> > this
> > now: I wonder if it would make sense to use some polymorphism tricks (AA
> > operations are slow enough that an extra pointer d
dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
I just wrote this to Sean and Walter and subsequently discussed it with
Walter. Walter thinks this should work. Does anyone have the time and
inclination to test this out? It would involve hacking into dru
Walter Bright wrote:
The purpose of T[new] was to solve the problems T[] had with passing T[]
to a function and then the function resizes the T[]. What happens with
the original?
The solution we came up with was to create a third array type, T[new],
which was a reference type.
Andrei had th
Leandro Lucarella wrote:
I don't see much problem. You should always return an array (T[new]) if
you have one, because you can get an slice from it (the inverse is not
true). Because of this, implicit conversion from array to slice can be
a good idea, so people expecting a slice when an array is
Andrei Alexandrescu, el 19 de octubre a las 13:51 me escribiste:
> I just wrote this to Sean and Walter and subsequently discussed it
> with Walter. Walter thinks this should work. Does anyone have the
> time and inclination to test this out? It would involve hacking into
> druntime's implementatio
Leandro Lucarella wrote:
Andrei Alexandrescu, el 19 de octubre a las 13:51 me escribiste:
I just wrote this to Sean and Walter and subsequently discussed it
with Walter. Walter thinks this should work. Does anyone have the
time and inclination to test this out? It would involve hacking into
drun
dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
article
I just wrote this to Sean and Walter and subsequently discussed it
with Walter. Walter thinks this should work. Does anyone have the
time and inclination to test this out? It would involve hacking
into d
Andrei Alexandrescu wrote:
Leandro Lucarella wrote:
Andrei Alexandrescu, el 19 de octubre a las 11:16 me escribiste:
I'm missing something? Why this shouldn't work?
It may work, but I was unable to pull it off reasonably well.
What problems did you find?
I thought I explained that above and
dsimcha wrote:
2. I don't understand how this solves the safety problem:
// foo lives on the heap b/c we've idup'd it.
string foo = "This is only a test.".idup;
string bar = foo[0..4];
bar ~= " is _not ";
writeln(foo); // prints "This is _not a test."
Having access to the capacity in an LRU c
Don wrote:
Walter Bright wrote:
The purpose of T[new] was to solve the problems T[] had with passing
T[] to a function and then the function resizes the T[]. What happens
with the original?
The solution we came up with was to create a third array type, T[new],
which was a reference type.
A
Chris Nicholson-Sauls wrote:
People expecting a slice and using "auto" or templates are in for a
rude awakening.
Andrei
I would argue that, if they truly *needed* a slice and are relying on
"auto" then they implicitly accept responsibility for putting the [] in
place to guarantee that. In
Andrei Alexandrescu, el 19 de octubre a las 14:31 me escribiste:
> By the way: implementation of @property has been canceled.
Keep throwing the good news :(
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
-
On 19/10/2009 16:57, Leandro Lucarella wrote:
Andrei Alexandrescu, el 18 de octubre a las 20:16 me escribiste:
Here's what I wrote to Walter:
I'm going to suggest something terrible - let's get rid of T[new]. I
know it's difficult to throw away work you've already done, but
Bill Baxter pisze:
Just get rid of the the one-argument foreach over AAs altogether and force
the user to be
explicit about it.
I wouldn't do so. Would anybody do an error by thinking that foreach
(elem,table) should iterate over keys?
Bearophile. And anyone coming from python, at the least.
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> dsimcha wrote:
> > 2. I don't understand how this solves the safety problem:
> >
> > // foo lives on the heap b/c we've idup'd it.
> > string foo = "This is only a test.".idup;
> > string bar = foo[0..4];
> > bar ~= " is
On 2009-10-19 18:19:34 +0200, Andrei Alexandrescu
said:
dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
Leandro Lucarella wrote:
Andrei Alexandrescu, el 19 de octubre a las 08:38 me escribiste:
For relatively large chunks of memory, the GC keeps a
dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
dsimcha wrote:
2. I don't understand how this solves the safety problem:
// foo lives on the heap b/c we've idup'd it.
string foo = "This is only a test.".idup;
string bar = foo[0..4];
bar ~= " is _not
On Mon, 19 Oct 2009 23:31:37 +0400, Andrei Alexandrescu
wrote:
Don wrote:
Walter Bright wrote:
The purpose of T[new] was to solve the problems T[] had with passing
T[] to a function and then the function resizes the T[]. What happens
with the original?
The solution we came up with was
Don pisze:
Since noone else seems to have said it: The fact that you're both
willing to let it go, after having already invested a lot of time in it,
is a good sign for the language. Well done.
Hey Don, you speak my words. Specially that I can't see good reason for
T[new] with present array
dsimcha pisze:
3. An implementation I call StaticAA, which does not allow the addition or
removal of keys after it is constructed, but in exchange has almost zero space
overhead and is very GC-efficient. It works by maintaining sorted parallel
arrays and using binary search.
Can immutable att
== Quote from Piotrek (star...@tlen.pl)'s article
> dsimcha pisze:
> > 3. An implementation I call StaticAA, which does not allow the addition or
> > removal of keys after it is constructed, but in exchange has almost zero
> > space
> > overhead and is very GC-efficient. It works by maintaining
On 2009-10-19 19:34:04 +0200, Andrei Alexandrescu
said:
Denis Koroskin wrote:
Put it simple: T[] is a range, and T[new] is a container. They belong
to different leagues.
Define ranges and define containers.
Yes, there is a lot common between them, because T[] supports some
subset of opera
On 19/10/2009 19:10, BCS wrote:
Hello Yigal,
I think that Arrays and AAs need to be removed from the language. I
prefer to have a collections framework as part of Phobos without
special cases in the language for specific containers.
If it can be assured that all the current array ops will get
will appear d3 ? What are the tasks ? it's not backward compatible
with D2 ? What major changes ?
when to stop adding new content of d2 ?
thank you very much to all
dolive
Andrei Alexandrescu wrote:
I just wrote this to Sean and Walter and subsequently discussed it with
Walter. Walter thinks this should work. Does anyone have the time and
inclination to test this out? It would involve hacking into druntime's
implementation of ~= (I'm not sure what the function na
On 2009-10-19 21:53:53 +0200, Andrei Alexandrescu
said:
dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
dsimcha wrote:
2. I don't understand how this solves the safety problem:
// foo lives on the heap b/c we've idup'd it.
string foo = "This is o
"Fawzi Mohamed" wrote in message
news:hbhi5q$1gq...@digitalmars.com...
> On 2009-10-18 20:01:26 +0200, language_fan said:
>
>> Sun, 18 Oct 2009 16:35:53 +0200, Fawzi Mohamed thusly wrote:
>>>
>>> on x86 the 64 bit extension added registers, that makes it faster, even
>>> if as you correctly poin
On 19/10/2009 21:20, dsimcha wrote:
== Quote from Jerry Quinn (jlqu...@optonline.net)'s article
dsimcha Wrote:
If anyone can think of any more, please let me know. Also, just thought of this
now: I wonder if it would make sense to use some polymorphism tricks (AA
operations are slow enough th
Hello Yigal,
On 19/10/2009 19:10, BCS wrote:
Hello Yigal,
I think that Arrays and AAs need to be removed from the language. I
prefer to have a collections framework as part of Phobos without
special cases in the language for specific containers.
If it can be assured that all the current ar
== Quote from Yigal Chripun (yigal...@gmail.com)'s article
> On 19/10/2009 21:20, dsimcha wrote:
> > == Quote from Jerry Quinn (jlqu...@optonline.net)'s article
> >> dsimcha Wrote:
> >>> If anyone can think of any more, please let me know. Also, just thought
> >>> of this
> >>> now: I wonder if
On Oct 20, 09 03:40, Piotrek wrote:
Bill Baxter pisze:
Just get rid of the the one-argument foreach over AAs altogether and
force
the user to be
explicit about it.
I wouldn't do so. Would anybody do an error by thinking that foreach
(elem,table) should iterate over keys?
Bearophile. And anyon
On 19/10/2009 22:53, BCS wrote:
Hello Yigal,
On 19/10/2009 19:10, BCS wrote:
Hello Yigal,
I think that Arrays and AAs need to be removed from the language. I
prefer to have a collections framework as part of Phobos without
special cases in the language for specific containers.
If it can b
On Mon, Oct 19, 2009 at 1:58 PM, KennyTM~ wrote:
> On Oct 20, 09 03:40, Piotrek wrote:
>>
>> Bill Baxter pisze:
>
> Just get rid of the the one-argument foreach over AAs altogether and
> force
> the user to be
> explicit about it.
I wouldn't do so. Would anybody do an
dolive Wrote:
> will appear d3 ? What are the tasks ? it's not backward compatible
> with D2 ? What major changes ?
My understanding is that there will be a significant gap between the
finalization of D2 and the start of D3. Bartosz's ownership scheme may be part
of D3.
> when to stop addin
1 - 100 of 174 matches
Mail list logo
