On Fri, 18 Jul 2008 22:27:16 +0100, "Stewart Gordon" <smjg_1998@yahoo.com> wrote:

>"Max Samukha" <samukha@voliacable.com.removethis> wrote in message
>news:9d2r74tuopl0dt05sgnkagss4gu4824k9m@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
2. Always throw an exception
3. Make 'remove' return a pointer to the value
4. Continue silently

I prefer the first option. Option 4 (current semantics)  is the least
acceptible, in my opinion.

On Sat, 19 Jul 2008 10:35:01 +0300, Max Samukha <samukha@voliacable.com.removethis> wrote:

>On Fri, 18 Jul 2008 22:27:16 +0100, "Stewart Gordon" <smjg_1998@yahoo.com> wrote:
>
>>"Max Samukha" <samukha@voliacable.com.removethis> wrote in message
>>news:9d2r74tuopl0dt05sgnkagss4gu4824k9m@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:

I meant four options.

"Max Samukha" <samukha@voliacable.com.removethis> wrote in message news:d85384p9e1heua1f8f6vn2cesd9cosjlrc@4ax.com...
> On Fri, 18 Jul 2008 22:27:16 +0100, "Stewart Gordon"
> <smjg_1998@yahoo.com> wrote:
>
>>"Max Samukha" <samukha@voliacable.com.removethis> wrote in message
>>news:9d2r74tuopl0dt05sgnkagss4gu4824k9m@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"?  Moreover, I personally think that debug switches should be saved for programmer-defined debug code.

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

> 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?

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies on the 'group where everybody may benefit. 

On Sat, 19 Jul 2008 16:39:18 +0400, Stewart Gordon <smjg_1998@yahoo.com> wrote:

> But .remove has to return something.  So how is this possible?

It doesn't return anything now.

> And what would remove do if the key is already not in the AA?  ReturnValueType.init?  Throw an exception?

I think returning null is ok. Otherwise a redundant check and a lookup will be necessary:

Object[char[]] map;
if (auto o = "test" in map) { // this is redundant, in my opinion
    delete map.remove("test");
}

and it is exactly the same as:

if (auto o = "test" in map) {
   map.remove("test");
   delete *o;
}

"Koroskin Denis" <2korden+dmd@gmail.com> wrote in message news:op.uejmwq0sn8fdl4@korden...
> On Sat, 19 Jul 2008 16:39:18 +0400, Stewart Gordon <smjg_1998@yahoo.com> wrote:
>
>> But .remove has to return something.  So how is this possible?
>
> It doesn't return anything now.

Are you missing my point, or guessing what Max meant?

>> And what would remove do if the key is already not in the AA?  Return ValueType.init?  Throw an exception?
>
> I think returning null is ok. Otherwise a redundant check and a lookup will be necessary:

What if the value type has no null?

> Object[char[]] map;
> if (auto o = "test" in map) { // this is redundant, in my opinion
>     delete map.remove("test");
> }
<snip>

Indeed, the "auto o =" bit is unnecessary here.

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies on the 'group where everybody may benefit. 

On Sat, 19 Jul 2008 19:25:15 +0400, Stewart Gordon <smjg_1998@yahoo.com> wrote:

> "Koroskin Denis" <2korden+dmd@gmail.com> wrote in message news:op.uejmwq0sn8fdl4@korden...
>> I think returning null is ok. Otherwise a redundant check and a lookup will be necessary:
>
> What if the value type has no null?
>

Hmm.. I missed that. At first, I though than remove() behaviour should be consistent with opIn(), i.e. it should return a pointer to a value, but it is not possible.

Looks like the best guess is to return the stored value or T.init, if no value is found (i.e. null for ref types and some default value for value types).

Stewart Gordon wrote:
> "Koroskin Denis" <2korden+dmd@gmail.com> wrote in message news:op.uejmwq0sn8fdl4@korden...
>> On Sat, 19 Jul 2008 16:39:18 +0400, Stewart Gordon <smjg_1998@yahoo.com> wrote:
>>
>>> But .remove has to return something.  So how is this possible?
>>
>> It doesn't return anything now.
> 
> Are you missing my point, or guessing what Max meant?
> 
>>> And what would remove do if the key is already not in the AA?  Return ValueType.init?  Throw an exception?
>>
>> I think returning null is ok. Otherwise a redundant check and a lookup will be necessary:
> 
> What if the value type has no null?

I think the compiler should remove the extra delete so that writing generic code is easy.  Alternatively the compiler could report an error if delete doesn't work with the given type however I less like that option.  Also you could do this if remove returned something:

auto value = map.remove("test");
assert(value); //Value not found.
delete value;

> 
>> Object[char[]] map;
>> if (auto o = "test" in map) { // this is redundant, in my opinion
>>     delete map.remove("test");
>> }
> <snip>
> 
> Indeed, the "auto o =" bit is unnecessary here.
> 
> Stewart.
> 

I

Stewart Gordon, el 19 de julio a las 13:39 me escribiste:
> 
> "Max Samukha" <samukha@voliacable.com.removethis> wrote in message news:d85384p9e1heua1f8f6vn2cesd9cosjlrc@4ax.com...
> >On Fri, 18 Jul 2008 22:27:16 +0100, "Stewart Gordon" <smjg_1998@yahoo.com> wrote:
> >
> >>"Max Samukha" <samukha@voliacable.com.removethis> wrote in message
> >>news:9d2r74tuopl0dt05sgnkagss4gu4824k9m@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"?  Moreover, I personally think that debug switches should be saved for programmer-defined debug code.

If the idea was to add an assert in the remove code, I guess he meant not to raise an assert exception if compiled with the release flag.

In case the exception is not raised that could just be undefined behavior
(SIGSEGV or whatever).

> >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 think this solution can be perfectly viable too.

But I still think delete hash["x"]; should just work =)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Software is like sex: it's better when it's free.
	-- Linus Torvalds

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

>
>"Max Samukha" <samukha@voliacable.com.removethis> wrote in message news:d85384p9e1heua1f8f6vn2cesd9cosjlrc@4ax.com...
>> On Fri, 18 Jul 2008 22:27:16 +0100, "Stewart Gordon" <smjg_1998@yahoo.com> wrote:
>>
>>>"Max Samukha" <samukha@voliacable.com.removethis> wrote in message
>>>news:9d2r74tuopl0dt05sgnkagss4gu4824k9m@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.