Fixing const arrays

[Timon Gehr]

On 12/14/2011 12:35 AM, Peter Alexander wrote:
> On 13/12/11 11:11 PM, Timon Gehr wrote:
>> On 12/14/2011 12:14 AM, Peter Alexander wrote:
>>> On 13/12/11 10:17 PM, Vladimir Panteleev wrote:
>>>> On Tuesday, 13 December 2011 at 21:10:22 UTC, Andrei Alexandrescu
>>>> wrote:
>>>>> There's a phrase in Romanian that quite applies: "From the lake into
>>>>> the well".
>>>>
>>>> I believe the English version is "Out of the frying pan, into the
>>>> fire" :)
>>>>
>>>> Inconsequential space-filler opinion: I am OK with @property, mainly
>>>> because it's a common feature among PLs, it's better than nothing, and
>>>> don't know better solutions.
>>>
>>> In my opinion, it's not better than nothing.
>>>
>>> What it gives you:
>>>
>>> 1. A bit of syntactic sugar.
>>> 2. The ability to refactor member look up easily.
>>>
>>> What it costs:
>>>
>>> 1. Overloads syntax.
>>> a. obj.field can now be an arbitrary function call.
>>> b. May have arbitrary cost (e.g. T[].length)
>>
>> ??? T[].length is a field access, not a property function. It takes a
>> small constant amount of time.
>
> Assigning to the length of an array may reallocate it, which is not a
> small, nor constant amount of time.
>
> int[] a;
> ...
> a.length = n; // may invoke a GC allocation + O(n) memcpy

OK, I see, thanks. I don't think it is problematic in this particular 
case though.