As we discussed multimap issue with not having indexes and lists, me and my friend liava improved the block to have them.
Original block:
Improved block:
ANOTHER version of improved block, firstly i wanted it to be separate like this:
But then i thought, since multimap already exists, they could be just combined to this:
What do you think?
No info
@bh bump
this guy wants his (slower but better)block to become a standard library
it is not better, it is CORRECT one, instead of broken one
My 2 cents 
AFAICT, the current multimap works perfectly when the number of supplied lists matches the number of parameters in the function
If this isn't true then it is broken
The case of what it should return if the numbers don't match up, is up to who ever defines the behaviour of the block
There are quite a few blocks that don't return what I'd like when pushed beyond their intended use but I don't consider them to be wrong - I just accept their current behaviour and if needs be - make a modified version of them with a different name -i.e. enhanced multimap
no.
No to what part of my post?
all.
maybe you should describe in a more detailed post rather than just saying one word? I'm really confused on what you're talking about
it is obvious that i don't think it should be added as another block, it should be replaced.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
