Steven Schveighoffer Wrote:

>   * shrinkToFit(T[] arr): This one is a bit tricky and technically unsafe.
> It reduces the size of the "allocated" length to fit the length of the
> array.  The allocated length is the length that the runtime assumes is
> being used of the memory block.  This is what aids in preventing stomping,
> so use with care.  You can achieve stomping if you use shrinkToFit on a
> slice, but still have references to the trimmed data.  Example:
> 
> string s = "12345".idup;
> string slice = s[0..2];
> slice.shrinkToFit(); // tells the runtime that you will no longer use any data beyond the slice
> slice ~= "00"; // appends in place, overwriting immutable data referenced

Actually, slice.capacity *increases* from 0 to s.capacity when calling shrinkToFit, doesn't it? So "stomp" or "prepare_for_stomping" could be a better name.

On Tue, 09 Mar 2010 10:10:10 -0500, biozic <biozic@free.fr> wrote:

> Steven Schveighoffer Wrote:
>
>>   * shrinkToFit(T[] arr): This one is a bit tricky and technically unsafe.
>> It reduces the size of the "allocated" length to fit the length of the
>> array.  The allocated length is the length that the runtime assumes is
>> being used of the memory block.  This is what aids in preventing stomping,
>> so use with care.  You can achieve stomping if you use shrinkToFit on a
>> slice, but still have references to the trimmed data.  Example:
>>
>> string s = "12345".idup;
>> string slice = s[0..2];
>> slice.shrinkToFit(); // tells the runtime that you will no longer use any data beyond the slice
>> slice ~= "00"; // appends in place, overwriting immutable data referenced
>
> Actually, slice.capacity *increases* from 0 to s.capacity when calling shrinkToFit, doesn't it? So "stomp" or "prepare_for_stomping" could be a better name.

Yes, it is technically like that.  shrinkToFit really looks weird as a property of the slice you are shrinking to because it really is operating on the array data itself (which has no concrete type or reference).

I don't like anything that talks about stomping, because we are not trying to say this is a stomping operation.  I want to focus more on the fact that you are declaring the data after the slice as being no longer used.

It's definitely a harder function to name...

-Steve

On Tue, 09 Mar 2010 10:23:07 -0500, Steven Schveighoffer wrote:

> I want to focus more on the fact that you are declaring the data after the slice as being no longer used.

kind of assumeUnique ...

assumeNoArrayReference ?

Michal Minich wrote:

> On Tue, 09 Mar 2010 10:23:07 -0500, Steven Schveighoffer wrote:
> 
>> I want to focus more on the fact that you are declaring the data after the slice as being no longer used.
> 
> kind of assumeUnique ...
> 
> assumeNoArrayReference ?

I like that. Or assumeNoMemoryAliasing. It should be clear that it is a potentially very unsafe function.

Lutger:
> Or assumeNoMemoryAliasing. It should be clear that it is a potentially very unsafe function.

This is getting there :-)

Bye,
bearophile

On Tue, 09 Mar 2010 12:54:16 -0500, Lutger <lutger.blijdestijn@gmail.com> wrote:

> Michal Minich wrote:
>
>> On Tue, 09 Mar 2010 10:23:07 -0500, Steven Schveighoffer wrote:
>>
>>> I want to focus more on the fact that you are declaring the data after
>>> the slice as being no longer used.
>>
>> kind of assumeUnique ...
>>
>> assumeNoArrayReference ?
>
> I like that. Or assumeNoMemoryAliasing. It should be clear that it is a
> potentially very unsafe function.

I like this train of thought, assume is a good term for what you are doing, and it is consistent with assumeUnique.

The only thing I don't like about it is you aren't really assuming anything about the slice, you are assuming the data after the slice is no longer used.  It looks weird that you are assuming something about the slice.

assumeEndOfData ?
assumeAllocation ?

I don't 100% like those either.

-Steve

On Tue, 09 Mar 2010 14:07:10 -0500, Steven Schveighoffer wrote:

> On Tue, 09 Mar 2010 12:54:16 -0500, Lutger <lutger.blijdestijn@gmail.com> wrote:
> 
>> Michal Minich wrote:
>>
>>> On Tue, 09 Mar 2010 10:23:07 -0500, Steven Schveighoffer wrote:
>>>
>>>> I want to focus more on the fact that you are declaring the data after the slice as being no longer used.
>>>
>>> kind of assumeUnique ...
>>>
>>> assumeNoArrayReference ?
>>
>> I like that. Or assumeNoMemoryAliasing. It should be clear that it is a potentially very unsafe function.
> 
> I like this train of thought, assume is a good term for what you are doing, and it is consistent with assumeUnique.
> 
> The only thing I don't like about it is you aren't really assuming anything about the slice, you are assuming the data after the slice is no longer used.  It looks weird that you are assuming something about the slice.
> 
> assumeEndOfData ?
> assumeAllocation ?
> 
> I don't 100% like those either.
> 
> -Steve

assumeNoArrayReference does not express that there can be references to the original array before slice start. probably better expressing, if rather long name could be

assumeNoOriginArrayReferencesPastSliceEnd assumeNoOriginArrayReferencesAfter

or probably somthing like this:
unsafeDeletePastSlice

On Tue, 09 Mar 2010 14:36:41 -0500, Michal Minich <michal.minich@gmail.com> wrote:

> assumeNoArrayReference does not express that there can be references to
> the original array before slice start. probably better expressing, if
> rather long name could be

Actually, you can have valid references up until the slice end.

> assumeNoOriginArrayReferencesPastSliceEnd
> assumeNoOriginArrayReferencesAfter

These are too long.  As much as this is an unsafe to-be-used-with-care function, we don't want to torture those who need it :)  I prefer a name with 1-3 terms in it.

> or probably somthing like this:
> unsafeDeletePastSlice

also a little long, and I don't like the term delete, it's not actually deleting the memory.

-Steve

On 3/9/2010 12:44 PM, Steven Schveighoffer wrote:
> On Tue, 09 Mar 2010 14:36:41 -0500, Michal Minich
> <michal.minich@gmail.com> wrote:
>
>> assumeNoArrayReference does not express that there can be references to
>> the original array before slice start. probably better expressing, if
>> rather long name could be
>
> Actually, you can have valid references up until the slice end.
>
>> assumeNoOriginArrayReferencesPastSliceEnd
>> assumeNoOriginArrayReferencesAfter
>
> These are too long. As much as this is an unsafe to-be-used-with-care
> function, we don't want to torture those who need it :) I prefer a name
> with 1-3 terms in it.
>
>> or probably somthing like this:
>> unsafeDeletePastSlice
>
> also a little long, and I don't like the term delete, it's not actually
> deleting the memory.
>
> -Steve

As long as we're bikeshedding, maybe assumeUnreferencedAfter?

On Tue, 09 Mar 2010 14:54:11 -0500, David Gileadi <foo@bar.com> wrote:

> On 3/9/2010 12:44 PM, Steven Schveighoffer wrote:
>> On Tue, 09 Mar 2010 14:36:41 -0500, Michal Minich
>> <michal.minich@gmail.com> wrote:
>>
>>> assumeNoArrayReference does not express that there can be references to
>>> the original array before slice start. probably better expressing, if
>>> rather long name could be
>>
>> Actually, you can have valid references up until the slice end.
>>
>>> assumeNoOriginArrayReferencesPastSliceEnd
>>> assumeNoOriginArrayReferencesAfter
>>
>> These are too long. As much as this is an unsafe to-be-used-with-care
>> function, we don't want to torture those who need it :) I prefer a name
>> with 1-3 terms in it.
>>
>>> or probably somthing like this:
>>> unsafeDeletePastSlice
>>
>> also a little long, and I don't like the term delete, it's not actually
>> deleting the memory.
>
> As long as we're bikeshedding, maybe assumeUnreferencedAfter?

This is exactly the semantic meaning we are going for.  I'd like it to be shorter...

synonyms for unreferenced?

assumeUnusedAfter

Any others ideas?

-Steve