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-only.

Of what type will strings be? Of what type will be the result of concatenation?

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

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

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!

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

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

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