associative arrays: iteration is finally here

[Bill Baxter]

On Thu, Oct 29, 2009 at 10:33 AM, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:
> Bill Baxter wrote:
>>
>> On Thu, Oct 29, 2009 at 8:39 AM, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>
>>> Leandro Lucarella wrote:
>>>>
>>>> Andrei Alexandrescu, el 28 de octubre a las 20:29 me escribiste:
>>>>>>>
>>>>>>> Your test looks something up and then removes it.
>>>>>>>
>>>>>>>
>>>>>>> Andrei
>>>>>>
>>>>>> Well, my extended test case looks something up, manipulates the
>>>>>> found value, and then possibly removes it.
>>>>>
>>>>> Ok, I understand your points, thanks for explaining.
>>>>
>>>> What about and overload of remove() like this:
>>>> bool remove(in T key, out U value);
>>>>
>>>> If the element was present, it's returned in "value", so you can
>>>> manipulate it. I thought about just returning a pointer:
>>>> U* remove(in T key);
>>>>
>>>> But I guess that pointer would point to the element stored in the the AA
>>>> private data, but that element was just removed, so bad things would
>>>> happen, that's why the only option is to copy the data, right?
>>>
>>> I think this all is overdoing it. First, I disagree that remove should
>>> ever
>>> throw an exception. It's not a code that the user is supposed to check
>>> (with
>>> dire consequences if she doesn't), it's just additional information just
>>> in
>>> case you need it.
>>>
>>> I think bool remove(key) is better than all other designs suggested so
>>> far.
>>
>> I agree with the folks who say it's error-prone.  I can just see
>> myself now removing a key I know is in the dictionary and being
>> baffled when my program fails somewhere later on because I typed
>> aa.remove("theKey") when it should have been aa.remove("thekey").  I
>> knew it was there so I didn't want to clutter up my code with a check
>> for it.
>
> I don't find this reasonable. If you know removal must have succeeded, just
> type enforce(aa.remove("theKey")). I don't think that's the overwhelmingly
> common case though, and if it's, say, about 50/50, then it's much more
> sensible to have a non-throwing primitive than a throwing one. And it looks
> like defining two primitives just to save a call to enforce is not a good
> design. After all, if you argue people forget and misspell things and all, I
> could argue they call the wrong function out of two with very similar
> charters. Honest, I just read a couple of posts proposing two primitives and
> for the life of me I already can't remember which was throwing and which
> wasn't.
>
>> So the advice would be to always check to make sure the key you remove
>> got removed to be on the safe side.
>
> I'm not seeing how that comes about. The advice is to check if you care,
> which is common sense. I'm wondering how such an obvious design came into
> question.

Ok.  You convinced me that your way doesn't suck.  And you can ask the
Python designers how the so-called "obvious" design came into
question.  Apparently it's not as obvious as you think.  And I would
suggest from experience with Python that having two functions is also
not as bad as you think.  But I'm convinced that having two functions
is not significantly better than having one function that doesn't
throw.

--bb