Top 5

[Denis Koroskin]

On Fri, 10 Oct 2008 18:33:43 +0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> Sergey Gromov wrote:
>> Fri, 10 Oct 2008 08:22:10 -0500,
>> Andrei Alexandrescu wrote:
>>> Sergey Gromov wrote:
>>>> My T[] is useful when you want to recursively split a megabyte file  
>>>> into a couple thousands of tokens, and then modify some of those  
>>>> tokens.  For that, your T[] must be lightweight, it must reference a  
>>>> bigger piece of data, and it must guarantee not to write anything  
>>>> into memory outside its boundaries.
>>>>
>>>> The Array is for appending.  It must always own its memory.   
>>>> Therefore you should be able to pass it around by reference, so Array  
>>>> is a *class* and cannot be nearly as lightweight as T[].
>>>>
>>>> You see, many of their properties are orthogonal.  If you drop one,  
>>>> you lose flexibility.
>>>>
>>>>> Besides, Array!(T) is not a good name for build-in type.
>>>> Names are placeholders here, not an actual proposal.
>>> What's wrong with making Array a library type?
>>  Well, I'd like
>>   new Object[15];
>> to be immediately appendable and therefore a syntactic sugar for   new  
>> Array!(Object)(15);
>
> I have a nagging impression the syntax Array!(Object) strikes you as  
> hard on the hand and the eyes...
>

I think "auto o = new Array!(Object)(15);" is good.

> Anyhow the syntax new Object[15] is idiotic because Object[15] is a type  
> in itself. The syntax makes it next to impossible to actually generate a  
> fixed-sized array dynamically.
>

I Agree.

> In fact here's a challenge for you. Please generate a pointer to an  
> Object[15] using new.
>
>> I'd also like
>>   "foo" ~ text ~ "bar"
>> to become something like
>>   (new Array!(char)) ~= "foo" ~= text ~= "bar"
>> that is what Java does to string concatenation.  Sugar doesn't seem to  
>> couple well with a purely library type.

I doubt that. Java strings are immutable, their length can't be changed  
either (i.e. they are a direct analog of a proposed invariant(char)[]).
Concatanating Java strings don't turn them into array, and it is dead  
slow. Every sane person uses StringBuilder instead.

>>  Well, the latter is probably too complex and can cause major  
>> problems.  But new T[] should return something appendable.
>
> I'm not 100% sure about that.
>
>
> Andrei

T[] t = new T[n]; // returning fixed-sized array seams reasonable to me,  
we can't resize it through t anyway.
OTOH how often do you create fixed-sized arrays?

Other issue:

auto f = "foo"; // s is invariant(char)[], i.e. a read-only view. No  
mutating, no length change
f = f ~ "bar";  // allow this or not?

it *should* be allowed because of CTFE and templates

If this would be allowed then f ~= "bar"; should be also allowed as well  
(a short-cut), right?
If this would be allowed should it call gc.capacity() prior to allocation  
or not?
I guess not, but this way appending becomes even slower (*much* slower).