associative arrays: iteration is finally here

Bill Baxter wbaxter at gmail.com
Thu Oct 29 11:31:12 PDT 2009


On Thu, Oct 29, 2009 at 11:16 AM, Leandro Lucarella <llucax at gmail.com> wrote:
> Andrei Alexandrescu, el 29 de octubre a las 12:33 me escribiste:
>> Bill Baxter wrote:
>> >>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
>
> I don't agree, this is like saying you should bound-check every array
> access. I think it's nice to have safety by default. If you are expecting
> to have an error, you will be extra careful to spell the key correctly.
> This should cover the cases where you are distracted and not expecting any
> errors.
>
> I think the check could be done in non-release mode only though, just
> like bound checking.
>
>> 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.
>
> This is one case where I think practicality beats purity, because the
> whole point of throwing an exception is for the cases you don't expect it
> to fail. Again, think of array bounds, you can force the programmer to add
> lots of enforce() in the code and remove bound checking from the compiler.

The problem with this argument (which I was also about to make) is
that accessing an array out of bounds is almost never normal behavior.
 But for deleting things, it often is.  Think also about delete
itself.  In C++ and D delete on a null pointer is fine, and is defined
to be a no-op.  This was done explicitly to avoid always having to do
if(p) delete p; all the time.  And really it works out just fine in
practice.   If we're going to keep arguing that remove() should throw,
then really delete should too.

--bb



More information about the Digitalmars-d mailing list