August 10, 2009 Re: T[new] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | This sounds excellent. |
August 10, 2009 Re: T[new] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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-only.
Of what type will strings be? Of what type will be the result of concatenation?
|
August 10, 2009 Re: T[new] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | Kagamin wrote: > Of what type will strings be? immutable(char)[] > Of what type will be the result of concatenation? T[new] |
August 10, 2009 Re: T[new] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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
|
August 10, 2009 Re: T[new] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Lars T. Kyllingstad | 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.
|
August 10, 2009 Re: T[new] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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
|
August 10, 2009 Re: T[new] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | Sun, 09 Aug 2009 13:29:21 -0700, Walter Bright wrote:
> 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;
Good news. I'm all for it. The T[new] syntax is a bit... weird... bit I'm OK with it as well. Thanks!
|
August 10, 2009 Re: T[new] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 s is not the same as that of s1 and s2.
Andrei
|
August 10, 2009 Re: T[new] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Mon, 10 Aug 2009 10:11:52 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> 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 = " world"; > auto s = s1 ~ s2; > > Some might be surprised that the type of s is not the same as that of s1 and s2. auto c1 = 'a'; auto c2 = 'b'; auto c = c1 + c2; But s is better, because it implicitly casts back to typeof(s1). I think it's the absolutely best behavior. -Steve |
August 10, 2009 Re: T[new] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Sun, 09 Aug 2009 16:29:21 -0400, Walter Bright <newshound1@digitalmars.com> wrote:
> 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:
>
> 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 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[].
>
> Doing this change will:
>
> 1. fix many nasties at the edges of array semantics
>
> 2. make arrays implementable on .net
>
> 3. make clear in function signatures if the function can resize the array or not
Yay!
Will capacity be settable? That is, can I replace this pattern:
char[] buf = new buf[1024];
buf.length = 0;
with something like this?:
char[new] buf;
buf.capacity = 1024; // ensure capacity is *at least* 1024
----
I read elsewhere that
T[new] x;
doesn't allocate until length (or maybe capacity) is non-zero.
So T[new] is a library defined type. What does the underlying type get called with when x.length = 5 is entered? Is the underlying type:
1. an object?
2. a templated type?
----
What happens when you do:
x = null;
where x is a T[new] type?
Is it the same as setting x.length = 0, or x.capacity = 0?
What does x == null mean? What about x is null?
Will ptr be settable, or only readable?
Will the compiler continue to optimize foreach calls to arrays? How will foreach be implemented, as a range or opApply? The former implies some automated method to return a range, because you wouldn't want to modify the referenced array during iteration.
This is exciting :)
-Steve
|
Copyright © 1999-2021 by the D Language Foundation