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 agr
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 betw
Rainer Deyke wrote:
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 assi
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.
>
> Paradoxically this seems to be
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 shoul
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 extended to slice
Andrei Alexandrescu wrote:
> Rainer Deyke wrote:
>> To answer the rephrased question: 'int[new]' should be a value type.
>
> Well Walter and I agreed they should be pass-by-reference. That doesn't
> mean they must be references, and the fact that the simplest syntax has
> the worst efficiency remi
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't sli
== 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 a couple of extra oper
Rainer Deyke wrote:
Andrei Alexandrescu wrote:
Rainer Deyke wrote:
To answer the rephrased question: 'int[new]' should be a value type.
Well Walter and I agreed they should be pass-by-reference. That doesn't
mean they must be references, and the fact that the simplest syntax has
the worst effi
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't
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 argument
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 T
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 tha
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, there's no way to distinguish bet
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 t
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 = [1, 2, 3]; // no allocatio
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)[] a = [1, 2,
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},
unless i
On Fri, 16 Oct 2009 02:53:20 -0700, Walter Bright
wrote:
>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[n
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[new
On 2009-10-16 13:54:03 +0200, Max Samukha said:
On Fri, 16 Oct 2009 02:53:20 -0700, Walter Bright
wrote:
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
Fawzi Mohamed wrote:
On 2009-10-16 13:54:03 +0200, Max Samukha said:
On Fri, 16 Oct 2009 02:53:20 -0700, Walter Bright
wrote:
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
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:
immutable(int)[
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 example
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 allocated
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
immutable an
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
disagreement.
>>>
>>> I'd prefer Walter's way
On Fri, 16 Oct 2009 18:30:24 +0400, Andrei Alexandrescu
wrote:
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.
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 be the same as if it was a ref
Thu, 15 Oct 2009 21:55:07 -0500, Andrei Alexandrescu wrote:
> int[new] a;
> ...
> a = [1, 2, 3];
>
> What should that do?
To me a is an array, a reference type. Therefore assignment here means
rebinding a to a new array created from a literal.
> A: Ok, then how do I say the common operation "I
Thu, 15 Oct 2009 23:18:22 -0500, Andrei Alexandrescu wrote:
> 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 th
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
On Fri, 16 Oct 2009 05:49:12 -0400, 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.
Andre
Steven Schveighoffer wrote:
On Fri, 16 Oct 2009 05:49:12 -0400, 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
On Tue, 20 Oct 2009 09:09:46 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Fri, 16 Oct 2009 05:49:12 -0400, 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
50 matches
Mail list logo