delete hash[key] deprecated???

[Max Samukha]

On Sat, 19 Jul 2008 13:39:18 +0100, "Stewart Gordon"
<smjg_1998 at yahoo.com> wrote:

>
>"Max Samukha" <samukha at voliacable.com.removethis> wrote in message 
>news:d85384p9e1heua1f8f6vn2cesd9cosjlrc at 4ax.com...
>> On Fri, 18 Jul 2008 22:27:16 +0100, "Stewart Gordon"
>> <smjg_1998 at yahoo.com> wrote:
>>
>>>"Max Samukha" <samukha at voliacable.com.removethis> wrote in message
>>>news:9d2r74tuopl0dt05sgnkagss4gu4824k9m at 4ax.com...
>>><snip>
>>>> If 'remove' was modified to return the removed value, more compact
>>>> syntax would be possible:
>>>>
>>>> delete hash.remove("x");
>>><snip>
>>>
>>>And what would remove do if the key is already not in the AA?  Return
>>>ValueType.init?  Throw an exception?
>>>
>>>Stewart.
>>
>> Three options:
>>
>> 1. Throw an assert exception if the program was built with a debug
>> switch
>
>And do what if the program wasn't built with a "debug switch"?

I agree, "debug switch" is BS. What I meant is non-release builds.
Trying to remove non-existent elements would result in undefined
behavior in release builds.

> Moreover, I 
>personally think that debug switches should be saved for programmer-defined 
>debug code.

It has been proposed that array bounds checking should be controlled
by a separate switch. 


>
>> 2. Always throw an exception
>> 3. Make 'remove' return a pointer to the value
>
>And so if the key isn't present, return null.  Hmm....  I guess it would be 
>the programmer's responsibility not to keep lots of these pointers alive and 
>thereby prevent the AA nodes from being GC'd.  Hmm....
>
I don't think that is an issue. Why would there be "lots of these
pointers"? Most of the time the return values of 'remove' wouldn't be
used at all. Anyway, as pointers are nowadays in dishonor, this option
is not going to be accepted.

>> 4. Continue silently
>
>But .remove has to return something.  So how is this possible?
>
>> I prefer the first option. Option 4 (current semantics)  is the least
>> acceptible, in my opinion.
>
>Hang on ... is 4 meant to be an option under the premise that we want 
>.remove to return the removed value, or the option of not implementing this 
>feature at all?
>

You are right. This is not an option.