I've just caught up on this thread. Built-in dynamic arrays have been
one of D's major features since the early days. Now you're planning to
remove this feature?
http://www.digitalmars.com/d/1.0/builtin.html
states that the C++ STL has many types that have been created to
compensate for the
On Tue, 20 Oct 2009 14:43:16 -0400, Bill Baxter wrote:
On Tue, Oct 20, 2009 at 11:30 AM, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
If your goal is to affect the original array, then you should accept a
ref
argument or not append to it.
I think that's an entirely reasonable
On Tue, Oct 20, 2009 at 11:30 AM, Andrei Alexandrescu
wrote:
> Steven Schveighoffer wrote:
>>
>> If your goal is to affect the original array, then you should accept a ref
>> argument or not append to it.
>
> I think that's an entirely reasonable (and easy to explain) stance.
I've definitely spen
Steven Schveighoffer wrote:
If your goal is to affect the
original array, then you should accept a ref argument or not append to it.
I think that's an entirely reasonable (and easy to explain) stance.
Andrei
Andrei Alexandrescu wrote:
grauzone wrote:
Steven Schveighoffer wrote:
I still think having an Appender object or struct is a worthwhile
thing, the "pre-allocate array then set length to zero" model is a
hack at best.
Would that work with Andrei's append cache at all? Setting the length
to
On Tue, 20 Oct 2009 12:30:57 -0400, Bill Baxter wrote:
On Tue, Oct 20, 2009 at 8:50 AM, Steven Schveighoffer
wrote:
On Tue, 20 Oct 2009 11:10:20 -0400, Bill Baxter
wrote:
On Tue, Oct 20, 2009 at 6:25 AM, Steven Schveighoffer
wrote:
On Sun, 18 Oct 2009 17:05:39 -0400, Walter Bright
wr
On Tue, Oct 20, 2009 at 10:05 AM, Andrei Alexandrescu
wrote:
> Bill Baxter wrote:
>>
>> To Andrei, do you really feel comfortable trying to explain this in
>> your book? It seems like it will be difficult to explain that ~= is
>> sometimes efficient for appending but not necessarily if you're
>>
On Tue, 20 Oct 2009 21:01:17 +0400, Andrei Alexandrescu
wrote:
grauzone wrote:
Steven Schveighoffer wrote:
I still think having an Appender object or struct is a worthwhile
thing, the "pre-allocate array then set length to zero" model is a
hack at best.
Would that work with Andrei's app
Bill Baxter wrote:
To Andrei, do you really feel comfortable trying to explain this in
your book? It seems like it will be difficult to explain that ~= is
sometimes efficient for appending but not necessarily if you're
working with a lot of arrays because it actually keeps this cache
under the h
grauzone wrote:
Steven Schveighoffer wrote:
I still think having an Appender object or struct is a worthwhile
thing, the "pre-allocate array then set length to zero" model is a
hack at best.
Would that work with Andrei's append cache at all? Setting the length to
zero and then appending is l
On Tue, Oct 20, 2009 at 8:50 AM, Steven Schveighoffer
wrote:
> On Tue, 20 Oct 2009 11:10:20 -0400, Bill Baxter wrote:
>
>> On Tue, Oct 20, 2009 at 6:25 AM, Steven Schveighoffer
>> wrote:
>>>
>>> On Sun, 18 Oct 2009 17:05:39 -0400, Walter Bright
>>> wrote:
>>>
The purpose of T[new] was to s
Steven Schveighoffer wrote:
I still think having an Appender object or struct is a worthwhile thing,
the "pre-allocate array then set length to zero" model is a hack at best.
Would that work with Andrei's append cache at all? Setting the length to
zero and then appending is like taking a slice
On Tue, 20 Oct 2009 11:10:20 -0400, Bill Baxter wrote:
On Tue, Oct 20, 2009 at 6:25 AM, Steven Schveighoffer
wrote:
On Sun, 18 Oct 2009 17:05:39 -0400, 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
On Tue, Oct 20, 2009 at 6:25 AM, Steven Schveighoffer
wrote:
> On Sun, 18 Oct 2009 17:05:39 -0400, 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?
>>
>>
On Sun, 18 Oct 2009 17:05:39 -0400, 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],
Andrei Alexandrescu wrote:
grauzone wrote:
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 w
On 2009-10-19 10:14:02 -0400, dsimcha said:
== Quote from downs (default_357-l...@yahoo.de)'s article
Walter Bright wrote:
Probably not. But you can rewrite:
a ~= stuff;
as:
a = a ~ stuff;
to make it work.
Is there any reason the first can't be a short-hand for the second?
Devil's adv
On 2009-10-18 17:05:39 -0400, Walter Bright said:
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
grauzone wrote:
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 to create a third array t
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 to create a third array type,
T[new], whi
Denis Koroskin wrote:
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
Hello Yigal,
On 19/10/2009 22:53, BCS wrote:
int b;
if(a.length > 5) b = a[5];
else b = a[$/2];
No runtime in that at all now.
I don't see a reason why this can't be inlined by the compiler if
Array is a lib type.
Yes, it should inline. What I'm saying is that unless it is /guaranteed/
t
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
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
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
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
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
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
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
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/
-
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
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
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
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
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
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
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
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
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
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]
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
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 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
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
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, 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
>
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 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
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
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
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
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
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
== 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
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
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
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].
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.
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
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.
>
>
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
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
dsimcha wrote:
The bugs in the current arrays are pretty nasty from a
theoretical safety/purity point of view (esp. the one that's a hole in
immutability), but are seldom run into in practice.
We'd like to get D to the point where guarantees can be offered. This
really sets it apart from C++,
dsimcha wrote:
> == Quote from downs (default_357-l...@yahoo.de)'s article
>> 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 u
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> dsimcha wrote:
> > == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> >> Jason House wrote:
> >>> Andrei Alexandrescu Wrote:
> >>>
> grauzone wrote:
> > Walter Bright wrote:
> >> We
Andrei Alexandrescu Wrote:
> dsimcha wrote:
> > == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> >> Jason House wrote:
> >>> Andrei Alexandrescu Wrote:
> >>>
> grauzone wrote:
> > Walter Bright wrote:
> >> We both feel that this would simplify D, make it m
dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
Jason House wrote:
Andrei Alexandrescu Wrote:
grauzone wrote:
Walter Bright wrote:
We both feel that this would simplify D, make it more flexible,
and remove some awkward corner cases like the inabili
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> Jason House wrote:
> > Andrei Alexandrescu Wrote:
> >
> >> grauzone wrote:
> >>> Walter Bright wrote:
> We both feel that this would simplify D, make it more flexible,
> and remove some awkward corner cases like
Jason House wrote:
Andrei Alexandrescu Wrote:
grauzone wrote:
Walter Bright wrote:
We both feel that this would simplify D, make it more flexible,
and remove some awkward corner cases like the inability to say
a.length++.
How would this remove this corner case?
Can't increment length if it'
Andrei Alexandrescu Wrote:
> grauzone wrote:
> > Walter Bright wrote:
> >> We both feel that this would simplify D, make it more flexible, and
> >> remove some awkward corner cases like the inability to say a.length++.
> >
> > How would this remove this corner case?
>
> Can't increment length i
== Quote from downs (default_357-l...@yahoo.de)'s article
> 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 crea
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.
>
> And
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> 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 = someFunctionThatReturnsTn
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].
T[] bar = someFunctionThatReturnsTnew();
// Works. bar is a T[]. The
== 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].
> > T[] bar = someFunctionThatReturnsTnew();
> > // Works. bar is a T[].
dsimcha wrote:
Here's my proposal for how T[new] should work:
1. It should be a reference type to be consistent with slices. Yes, slices are
kind of a hybrid, but they're more semantically similar to reference types than
value types. If you can't modify the length of a slice anymore, then for
== Quote from dsimcha (dsim...@yahoo.com)'s article
> 8. The first call to opSlice on a T[new] should set a flag that indicates
> that
> there may be multiple pointers to the underlying memory block. Before that
> flag
> is set, appends to a T[new] should result in calls to GC.free() to free th
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
> 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[n
On Mon, 19 Oct 2009 01:55:28 +0400, Andrei Alexandrescu
wrote:
Denis Koroskin wrote:
On Mon, 19 Oct 2009 01:05:39 +0400, 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
wit
grauzone wrote:
Walter Bright wrote:
We both feel that this would simplify D, make it more flexible, and
remove some awkward corner cases like the inability to say a.length++.
How would this remove this corner case?
Can't increment length if it's read-only.
Andrei
Denis Koroskin wrote:
On Mon, 19 Oct 2009 01:05:39 +0400, 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 ar
Walter Bright wrote:
We both feel that this would simplify D, make it more flexible, and
remove some awkward corner cases like the inability to say a.length++.
How would this remove this corner case?
What do you think?
Whether T[new] is bultin (mostly implemented in the runtime), or a
libr
On Mon, 19 Oct 2009 01:05:39 +0400, 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],
Walter Bright:
> Andrei had the idea that T[new] could be dispensed with by making a
> "builder" library type to handle creating arrays by doing things like
> appending, and then delivering a finished T[] type. This is similar to
> what std.outbuffer and std.array.Appender do, they just need a
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 the idea that T[new] cou
85 matches
Mail list logo
