D has a number of subtle problems (performance and semantic) that arise
when arrays are resized. The solution is to separate resizeable array
types from slices. Slices will retain the old:
T[] slice;
syntax. Resizeable arrays will be declared as:
T[new] array;
The new expression
Yay. What will happen with slices over a T[new] when the underlying T[new] must
be moved due to resizing? The behavior needs to be at least well specified, if
not well defined.
Walter Bright wrote:
> D has a number of subtle problems (performance and semantic) that arise
> when arra
Brad Roberts wrote:
Yay. What will happen with slices over a T[new] when the underlying T[new] must
be moved due to resizing? The behavior needs to be at least well specified, if
not well defined.
Great question! It's no different from what happens with any container
when its con
That's great. I think this would finally fix some of the more pressing
issues of D.
I have a question:
will
T[new] a;
allocate something? Or will the allocation of the hidden library array
object delayed until the length is set to non null? If the library array
object is not allo
By the way, T[new] is Andrei's idea, as well as it being his idea to
make it a reference type.
grauzone wrote:
will
T[new] a;
allocate something?
Nope.
Or will the allocation of the hidden library array
object delayed until the length is set to non null?
Yes.
If the library array
object is not allocated, will a.ptr, a.capacity and a.length simply
return null?
Yes. Clearly
declared as:
> T[new] array;
Such syntaxes have to be chosen wisely. I don't fully understand that syntax.
And maybe I don't fully like it.
I think the default (simpler) syntax has to be the most flexible and safer
construct, that is resizable arrays. Slices can be seen as an
Walter Bright:
> Under the hood, a T[new] will be a single pointer to a library defined
> type. This library defined type will likely contain three properties:
I have another question: are there some performance penalities in using such
arrays for normal random access operations
Walter Bright wrote:
> Brad Roberts wrote:
>> Yay. What will happen with slices over a T[new] when the underlying
>> T[new] must
>> be moved due to resizing? The behavior needs to be at least well
>> specified, if
>> not well defined.
>
> Great question! I
bearophile wrote:
Walter Bright:
Under the hood, a T[new] will be a single pointer to a library defined
type. This library defined type will likely contain three properties:
I have another question: are there some performance penalities in using such
arrays for normal random access
Brad Roberts wrote:
Walter Bright wrote:
Brad Roberts wrote:
Yay. What will happen with slices over a T[new] when the underlying
T[new] must
be moved due to resizing? The behavior needs to be at least well
specified, if
not well defined.
Great question! It's no different from what ha
will be declared as:
T[new] array;
Such syntaxes have to be chosen wisely. I don't fully understand that syntax.
And maybe I don't fully like it.
Why am I not surprised :o).
I think the default (simpler) syntax has to be the most flexible and safer
construct, that is resiza
Reply to bearophile,
Walter Bright:
2. make arrays implementable on .net
I don't care of such thing. dotnet already has C# and C# is probably
better than D,
I beg to differ. D is much better than c# in many ways (D's abstraction tools
are WAY better; C#'s end at reflection and generics, b
as to be the default syntax
to keep the compatibility with C :-)
Walter Bright:
> Yes. Clearly, those properties will have to be functions under the hood.
> So T[new] operations will be a bit slower than for slices. For faster
> indexing, you'd probably want to do:
> auto slice =
bearophile wrote:
2. make arrays implementable on .net
I don't care of such thing. dotnet already has C# and C# is probably better
than D, and it's similar anyway. So I don't think people will use D on dotnet.
So even if creating a D for dotnet can be positive, I don't want D2 to change
its
bearophile wrote:
2. make arrays implementable on .net
I don't care of such thing. dotnet already has C# and C# is probably
better than D, and it's similar anyway. So I don't think people will
use D on dotnet. So even if creating a D for dotnet can be positive,
I don't want D2 to change its des
grauzone:
> I see two things a dotnet implementation of D could have over native D:
> - better garbage collector (the D one barely does its job...)
The dotnet GC is probably better than the current D GC, but I think it's
designed for mostly movable objects. Currently most (or all) D objects are
Walter Bright wrote:
Under the hood, a T[new] will be a single pointer to a library defined
type. This library defined type will likely contain three properties:
size_t length;
T* ptr;
size_t capacity;
The usual array operations will work on T[new] as well as T[].
Would new T
Stewart Gordon wrote:
Walter Bright wrote:
Under the hood, a T[new] will be a single pointer to a library defined
type. This library defined type will likely contain three properties:
size_t length;
T* ptr;
size_t capacity;
The usual array operations will work on T[new] as well
Stewart Gordon wrote:
Moreover, would whatever happens solve such const/invariant holes as bug
2093?
Just what happens to the ~= operator anyway? Right now, it appends data
inline.
My vote would be to make "a~=b" do the same as "a=a~b" (with types "T[]
a" a
t; syntax. Resizeable arrays will be declared as:
>
>T[new] array;
>
> The new expression:
>
>new T[10]
>
> will return a T[new].
>
> T[new] will implicitly convert to T[], but not the other way.
>
> slice.length will become read-only.
>
>
declared as:
T[new] array;
The new expression:
new T[10]
will return a T[new].
I have nothing against the concept of container, but I dislike like the
syntax. Is this really better than Array!T ?
T[new] will implicitly convert to T[], but not the other way.
slice.length will become
Michel Fortin wrote:
But I know, unique isn't easy to implement to fit all the use cases we'd
like to solve. I'm just sharing a dream.
We explored unique at length, and trying to make it work would render
the rest of the language nearly unusably complex.
Walter Bright wrote:
>> But I know, unique isn't easy to implement to fit all the use cases we'd
>> like to solve. I'm just sharing a dream.
>
> We explored unique at length, and trying to make it work would render
> the rest of the language nearly unusably complex.
I've heard 'unique' mentioned
On Sun, 09 Aug 2009 14:21:31 -0700, Walter Bright
wrote:
bearophile wrote:
2. make arrays implementable on .net
I don't care of such thing. dotnet already has C# and C# is probably
better than D, and it's similar anyway. So I don't think people will
use D on dotnet. So even if creating a D
Mon, 10 Aug 2009 01:56:35 +0200, Michiel Helvensteijn wrote:
> Walter Bright wrote:
>
>>> But I know, unique isn't easy to implement to fit all the use cases we'd
>>> like to solve. I'm just sharing a dream.
>>
>> We explored unique at length, and trying to make it work would render
>> the rest
"Andrei Alexandrescu" wrote in message
news:h5ndt0$1bl...@digitalmars.com...
bearophile wrote:
Walter Bright:
Under the hood, a T[new] will be a single pointer to a library defined
type. This library defined type will likely contain three properties:
I have another question:
== Quote from bearophile (bearophileh...@lycos.com)'s article
> Walter Bright:
> > Under the hood, a T[new] will be a single pointer to a library defined
> > type. This library defined type will likely contain three properties:
> I have another question: are there some pe
Lionello Lunesu wrote:
"Andrei Alexandrescu" wrote in message
news:h5ndt0$1bl...@digitalmars.com...
bearophile wrote:
Walter Bright:
Under the hood, a T[new] will be a single pointer to a library
defined type. This library defined type will likely contain three
properties
bearophile Wrote:
> grauzone:
>
> > I see two things a dotnet implementation of D could have over native D:
> > - better garbage collector (the D one barely does its job...)
>
> The dotnet GC is probably better than the current D GC, but I think it's
> designed for mostly movable objects. Curre
This sounds excellent.
Walter Bright Wrote:
> Resizeable arrays will be declared as:
>
> T[new] array;
>
> The new expression:
>
> new T[10]
>
> will return a T[new].
>
> T[new] will implicitly convert to T[], but not the other way.
>
> slice.length will become read-
Kagamin wrote:
Of what type will strings be?
immutable(char)[]
Of what type will be the result of concatenation?
T[new]
Walter Bright wrote:
Kagamin wrote:
Of what type will strings be?
immutable(char)[]
I've always wondered: Why are strings of type immutable(char)[], and not
immutable(char[])?
I mean, there is no point in allowing resizing of strings, when
assigning to the new elements is impossible.
-
Lars T. Kyllingstad wrote:
I've always wondered: Why are strings of type immutable(char)[], and not
immutable(char[])?
So:
string a = "hello";
a = "foo";
works.
Walter Bright wrote:
Lars T. Kyllingstad wrote:
I've always wondered: Why are strings of type immutable(char)[], and
not immutable(char[])?
So:
string a = "hello";
a = "foo";
works.
Ah, of course. :) Thanks.
-Lars
t; syntax. Resizeable arrays will be declared as:
>
> T[new] array;
Good news. I'm all for it. The T[new] syntax is a bit... weird... bit
I'm OK with it as well. Thanks!
Walter Bright wrote:
Kagamin wrote:
Of what type will strings be?
immutable(char)[]
Of what type will be the result of concatenation?
T[new]
Hmmm, I see a problem.
auto s1 = "Hello";
auto s2 = " world";
auto s = s1 ~ s2;
Some might be surprised that the type of
On Mon, 10 Aug 2009 10:11:52 -0400, Andrei Alexandrescu
wrote:
Walter Bright wrote:
Kagamin wrote:
Of what type will strings be?
immutable(char)[]
Of what type will be the result of concatenation?
T[new]
Hmmm, I see a problem.
auto s1 = "Hello";
auto s2 = " worl
will be declared as:
T[new] array;
The new expression:
new T[10]
will return a T[new].
T[new] will implicitly convert to T[], but not the other way.
slice.length will become read-only.
Under the hood, a T[new] will be a single pointer to a library defined
type. This library defined
ax. Resizeable arrays will be declared as:
>
> T[new] array;
>
> The new expression:
>
> new T[10]
>
> will return a T[new].
>
> T[new] will implicitly convert to T[], but not the other way.
>
> slice.length will become read-only.
>
> Under the hood, a T[
Lars T. Kyllingstad Wrote:
> Walter Bright wrote:
> > Lars T. Kyllingstad wrote:
> >> I've always wondered: Why are strings of type immutable(char)[], and
> >> not immutable(char[])?
> >
> > So:
> >
> >string a = "hello";
> >a = "foo";
> >
> > works.
>
>
> Ah, of course. :) Thanks.
>
immutable(char)[] was that any string can be resized, even
> slices.
>
> Walter: what will the string types be aliased to now: still immutable(char)[]
> or immutable(char)[new]?
From: Walter Bright
Date: Mon, 10 Aug 2009 01:01:56 -0700
Subject: Re: T[new]
User-Agent: Thunderbird 2
Since nobody's yet asked
What type would .dup and .idup return?
The best choice I can see is to make .dup return T[new] and .idup return
invariant(T)[].
Stewart.
Jeremie Pelletier wrote:
Walter: what will the string types be aliased to now: still immutable(char)[]
or immutable(char)[new]?
I think it would be best to have them use the array [new] type.
It would be more efficient to cut out this middleman for things that
aren't going to change the len
On Mon, 10 Aug 2009 14:38:24 -0400, Stewart Gordon
wrote:
Since nobody's yet asked
What type would .dup and .idup return?
The best choice I can see is to make .dup return T[new] and .idup return
invariant(T)[].
This brings up another question. Should something like immuta
Steven Schveighoffer wrote:
On Mon, 10 Aug 2009 14:38:24 -0400, Stewart Gordon
wrote:
Since nobody's yet asked
What type would .dup and .idup return?
The best choice I can see is to make .dup return T[new] and .idup
return invariant(T)[].
This brings up another question. S
-)
>
>> Slices will retain the old:
>> T[] slice;
>> syntax. Resizeable arrays will be declared as:
>> T[new] array;
>
> Such syntaxes have to be chosen wisely. I don't fully understand that syntax.
> And maybe I don't fully like it.
> I th
On Mon, 10 Aug 2009 15:21:48 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Mon, 10 Aug 2009 14:38:24 -0400, Stewart Gordon
wrote:
Since nobody's yet asked
What type would .dup and .idup return?
The best choice I can see is to make .dup return T[new] and
Jeremie Pelletier wrote:
Walter: what will the string types be aliased to now: still
immutable(char)[] or immutable(char)[new]?
immutable(char)[]
I think it would be best to have them use the array [new] type.
The vast majority of uses will not need to be resizeable.
Functions which do no
dsimcha:
> import std.stdio, std.perf;
[...]
> Results:
> Direct: 226
> Indirect: 229
Thank you. Following your example I have tried to do a bit more realistic tests.
// test1.d, for D2, Phobos
import std.stdio: writeln;
import std.perf: PerformanceCounter;
final class TNew(T) {
T* ptr;
On Mon, Aug 10, 2009 at 6:53 PM, bearophile wrote:
> If such tests are correct, then the new resizable arrays of D2 will indeed
> have some performance penality (something like 13%-17% in this test, but
> results may change with other array sizes).
I don't see why that's a big problem. If you'
Jarrett Billingsley:
>I don't see why that's a big problem.<
Like St Thomas I touch first and believe (maybe) later :-)
Bye,
bearophile
I talked to Walter about T[new] today and it seems we are having a
disagreement.
The problem is that I believe T[new] is a container, whereas Walter
believes T[new] is nothing but a slice with a couple of extra operations.
Paradoxically this seems to be conducive to subtle efficiency issues
Andrei Alexandrescu wrote:
> int[new] a;
>
> a = [1, 2, 3];
>
> What should that do?
This question can be rephrased as, "should 'int[new]' be a reference
type or a value type (or something else)?"
If 'int[new]' is a reference type, then it must rebind, because that's
what assignment does fo
Andrei Alexandrescu wrote:
This goes into something more interesting that I thought of after the
conversation. Consider:
T[new] a;
T[] b;
...
a = b;
What should that do?
Error. T[] cannot be implicitly converted to T[new]
On Thu, 15 Oct 2009 23:16:56 -0400, Walter Bright
wrote:
Andrei Alexandrescu wrote:
This goes into something more interesting that I thought of after the
conversation. Consider:
T[new] a;
T[] b;
...
a = b;
What should that do?
Error. T[] cannot be implicitly converted to T[new]
I
Walter Bright wrote:
Andrei Alexandrescu wrote:
This goes into something more interesting that I thought of after the
conversation. Consider:
T[new] a;
T[] b;
...
a = b;
What should that do?
Error. T[] cannot be implicitly converted to T[new]
Then your argument building on similarity
s.
W: Nobody complained about it with slices.
FWIW, I found arrays in D1 so completely broken that I didn't it worth
the effort to complain about every little detail. Everything about them
was wrong. I consider them a textbook example of what not to do.
My perception is that you're in a minority. Anyway, if there's something
that T[new] can help with, let us know.
Andrei
On Thu, 15 Oct 2009 22:55:07 -0400, Andrei Alexandrescu
wrote:
I talked to Walter about T[new] today and it seems we are having a
disagreement.
The problem is that I believe T[new] is a container, whereas Walter
believes T[new] is nothing but a slice with a couple of extra operations
Andrei Alexandrescu Wrote:
> I talked to Walter about T[new] today and it seems we are having a
> disagreement.
>
> The problem is that I believe T[new] is a container, whereas Walter
> believes T[new] is nothing but a slice with a couple of extra operations.
>
> Parado
Andrei Alexandrescu wrote:
I talked to Walter about T[new] today and it seems we are having a
disagreement.
The problem is that I believe T[new] is a container, whereas Walter
believes T[new] is nothing but a slice with a couple of extra operations.
I agree with the container model, it
Robert Jacques wrote:
I like (and have used) the opSliceAssign syntax to represent by
value/copy assignment as opposed to opAssign's by reference syntax. You
could always define T[new] auto-resize in the case of a[] = b, but then
you'd have to decide if that behavior should be e
found arrays in D1 so completely broken that I didn't it worth
>> the effort to complain about every little detail. Everything about them
>> was wrong. I consider them a textbook example of what not to do.
>
> My perception is that you're in a minority. Anyway, if t
Andrei Alexandrescu wrote:
> Then your argument building on similarity between the two is weakened.
>
> T[new] a;
> T[] b;
>
> a = [1, 2, 3];
> b = [1, 2, 3];
>
> Central to your argument was that the two must do the same thing. Since
> now literals are in a
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> I talked to Walter about T[new] today and it seems we are having a
> disagreement.
> The problem is that I believe T[new] is a container, whereas Walter
> believes T[new] is nothing but a slice with
. Structs have another. If the
language absolutely needs to support both sets of attributes, I should
at least be able to mix and match between them.
So, what's the syntax for user-defined value types that are passed by
reference going to be? ref struct? opPass?
No need for new syntax. T[n
Rainer Deyke wrote:
Andrei Alexandrescu wrote:
Then your argument building on similarity between the two is weakened.
T[new] a;
T[] b;
a = [1, 2, 3];
b = [1, 2, 3];
Central to your argument was that the two must do the same thing. Since
now literals are in a whole new league (they aren&#
Andrei Alexandrescu wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
This goes into something more interesting that I thought of after the
conversation. Consider:
T[new] a;
T[] b;
...
a = b;
What should that do?
Error. T[] cannot be implicitly converted to T[new]
Then your
Jeremie Pelletier wrote:
Andrei Alexandrescu wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
This goes into something more interesting that I thought of after
the conversation. Consider:
T[new] a;
T[] b;
...
a = b;
What should that do?
Error. T[] cannot be implicitly converted to
Andrei Alexandrescu wrote:
Jeremie Pelletier wrote:
Andrei Alexandrescu wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
This goes into something more interesting that I thought of after
the conversation. Consider:
T[new] a;
T[] b;
...
a = b;
What should that do?
Error. T[] cannot
Jeremie Pelletier wrote:
Andrei Alexandrescu wrote:
Jeremie Pelletier wrote:
Andrei Alexandrescu wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
This goes into something more interesting that I thought of after
the conversation. Consider:
T[new] a;
T[] b;
...
a = b;
What should
Andrei Alexandrescu wrote:
> Rainer Deyke wrote:
>> So, what's the syntax for user-defined value types that are passed by
>> reference going to be? ref struct? opPass?
>
> No need for new syntax. T[new] is a struct that has a pointer inside.
Without new syntax, the
Just to understand it:
int[new] a;
int[new] b;
a = [1,2,3];
b = a;
In your book, the last statement would copy contents of a into b and b.ptr
!= a.ptr while according to walter, b would rebind to a?
Andrei Alexandrescu wrote:
I talked to Walter about T[new] today and it seems we are having a
disagreement.
The problem is that I believe T[new] is a container, whereas Walter
believes T[new] is nothing but a slice with a couple of extra operations.
Paradoxically this seems to be conducive
On Thu, 15 Oct 2009 21:55:07 -0500, Andrei Alexandrescu
wrote:
>I talked to Walter about T[new] today and it seems we are having a
>disagreement.
I'd prefer Walter's way with a provision that array literals are
immutable and allocated statically:
immutable(int)[] a =
Max Samukha wrote:
On Thu, 15 Oct 2009 21:55:07 -0500, Andrei Alexandrescu
wrote:
I talked to Walter about T[new] today and it seems we are having a
disagreement.
I'd prefer Walter's way with a provision that array literals are
immutable and allocated statically:
immutable(int)[]
Don wrote:
There are two sensible options:
I see the question as, is T[new] a value type or a reference type? I see
it as a reference type, and so assignment should act like a reference
assignment, not a value assignment.
Don wrote:
Max Samukha wrote:
// arrays are true reference types
int[new] a = [1, 2, 3];
b = a;
a.length = 22;
assert (a.length == b.length);
This makes perfect sense to me. The rule would be:
If 'x' is T[new], then:
x = y; _always_ copies y into a {length, capacity-specified block
This makes perfect sense to me. The rule would be:
>> If 'x' is T[new], then:
>> x = y; _always_ copies y into a {length, capacity-specified block},
>> unless it already is one. x is given a pointer to the start of that block.
>> x[] = y[]; does a memcpy, rega
On 2009-10-16 11:49:12 +0200, Walter Bright said:
Don wrote:
There are two sensible options:
I see the question as, is T[new] a value type or a reference type? I
see it as a reference type, and so assignment should act like a
reference assignment, not a value assignment.
I also see T
would be:
If 'x' is T[new], then:
x = y; _always_ copies y into a {length, capacity-specified block},
unless it already is one. x is given a pointer to the start of that block.
x[] = y[]; does a memcpy, regardless of whether y is a T[new] or a T[].
Right. Assignment of a reference typ
sense to me. The rule would be:
If 'x' is T[new], then:
x = y; _always_ copies y into a {length, capacity-specified block},
unless it already is one. x is given a pointer to the start of that
block.
x[] = y[]; does a memcpy, regardless of whether y is a T[new] or a T[].
Right. Assig
On Fri, 16 Oct 2009 14:25:44 +0200, Don wrote:
>Yes, but you could allocate the data immediately after the Array
>structure, so you only have one allocation. And in the common case,
>where it never exceeds the original capacity, they stay together and
>preserve cache locality.
>
> void *data;
Don wrote:
Max Samukha wrote:
On Thu, 15 Oct 2009 21:55:07 -0500, Andrei Alexandrescu
wrote:
I talked to Walter about T[new] today and it seems we are having a
disagreement.
I'd prefer Walter's way with a provision that array literals are
immutable and allocated statically:
imm
Walter Bright wrote:
Don wrote:
There are two sensible options:
I see the question as, is T[new] a value type or a reference type? I see
it as a reference type, and so assignment should act like a reference
assignment, not a value assignment.
I understand that, but to me that's an ex
Walter Bright wrote:
I think it would be very strange to have T[] behave like a reference
type (which it does now) and T[new] to behave like a value type.
T[] is not a reference type.
Andrei
Max Samukha wrote:
On Fri, 16 Oct 2009 14:25:44 +0200, Don wrote:
Yes, but you could allocate the data immediately after the Array
structure, so you only have one allocation. And in the common case,
where it never exceeds the original capacity, they stay together and
preserve cache locality.
Andrei Alexandrescu wrote:
Don wrote:
Max Samukha wrote:
On Thu, 15 Oct 2009 21:55:07 -0500, Andrei Alexandrescu
wrote:
I talked to Walter about T[new] today and it seems we are having a
disagreement.
I'd prefer Walter's way with a provision that array literals are
immutable and
Don wrote:
Andrei Alexandrescu wrote:
Don wrote:
Max Samukha wrote:
On Thu, 15 Oct 2009 21:55:07 -0500, Andrei Alexandrescu
wrote:
I talked to Walter about T[new] today and it seems we are having a
disagreement.
I'd prefer Walter's way with a provision that array literals are
Don wrote:
In case this isn't clear:
real [] sinsTable = [ sin(1.0), sin(2.0), sin(3.0), sin(4.0) ];
How do you do this so that the entries in the table are calculated at
compile time?
static?
Andrei
Lutger wrote:
Just to understand it:
int[new] a;
int[new] b;
a = [1,2,3];
b = a;
In your book, the last statement would copy contents of a into b and b.ptr
!= a.ptr while according to walter, b would rebind to a?
Well no.
In the case above b would rebind to a, which is consistent with:
in
Andrei Alexandrescu wrote:
Don wrote:
In case this isn't clear:
real [] sinsTable = [ sin(1.0), sin(2.0), sin(3.0), sin(4.0) ];
How do you do this so that the entries in the table are calculated at
compile time?
static?
Andrei
That's still not compile time. They're initialized in the mod
On Fri, 16 Oct 2009 09:00:27 -0500, Andrei Alexandrescu
wrote:
>Don wrote:
>> Max Samukha wrote:
>>> On Thu, 15 Oct 2009 21:55:07 -0500, Andrei Alexandrescu
>>> wrote:
>>>
>>>> I talked to Walter about T[new] today and it seems we are having a
&g
real question is, what's the type of an array literal?
If it's T[new] then you must reassign a reference to be consistent:
int[new] a = arrayLiteral;
int[new] b = a; // reassign reference
foo(arrayLiteral); // a reference passed
Else, invoke opAssign. And its semantics is not clear.
Andrei Alexandrescu, el 16 de octubre a las 09:12 me escribiste:
> Max Samukha wrote:
> >On Fri, 16 Oct 2009 14:25:44 +0200, Don wrote:
> >
> >>Yes, but you could allocate the data immediately after the Array
> >>structure, so you only have one allocation. And in the common
> >>case, where it neve
Andrei Alexandrescu Wrote:
> Walter Bright wrote:
> > I think it would be very strange to have T[] behave like a reference
> > type (which it does now) and T[new] to behave like a value type.
>
> T[] is not a reference type.
>
> Andrei
While true, normal use will
e common operation "I want to overwrite
> whatever the array had with 1, 2, 3"? I can only presume there must be
> an obvious and simple way to do so, and I thought a = [1, 2, 3] was the
> obvious syntax to achieve that.
I'd say
a.replace([1, 2, 3]);
> T[new] a;
>
wrote:
>>>>>>> This goes into something more interesting that I thought of after
>>>>>>> the conversation. Consider:
>>>>>>>
>>>>>>> T[new] a;
>>>>>>> T[] b;
>>>>>>> ...
&
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
1 - 100 of 234 matches
Mail list logo
