It only takes a few more characters to return the original alpha, or 255... but if you were creating an image algorithmically or something, not returning anything would be a lot cleaner than having to have else return 0, 0, 0, 0 or whatever. Is this the kind of thing you meant?
Or you might want the same sort of thing in the case of an image with either full alpha or no alpha pixels, and you want to do some transformation to only the pixels with full alpha.
I was also going to say it might be a good want to clear an ImageData too by passing it an empty function, but maybe it's quicker to just create a new ImageData?
That said... I assume it would be more common to want to have an alpha of 255 than to not, and then it might be nice just to ignore the alpha. But maybe this is a bit "assuming", if not incorrect? And it's "consistent" with other color functions to have a default alpha, but maybe it doesn't make sense in this situation?
Another idea: What about returning the previous alpha by default? Would this be possible/useful/not slow?
That was what I was hinting at. Also, slime pointed out in irc that there's precedence of a function that defaults to 0,0,0,0 without arguments, and alpha 255 with arguments. Maybe the same should be done here? (i.e. if only alpha is missing, use 255, else use 0 for everything)
As well as making nop functions do nothing and making the alpha channel something you don't have to worry about if you're not dealing with it, returning what was previously there would also be useful for when you want to change some pixels but not others.
For example, if you were making pixels of a certain color transparent (which isn't a great example because you probably shouldn't be doing this at run time :P), you could simply do this:
I think it should return the previous pixel value if any of the return values are missing or nil. The main reason I think this is that the description of the method becomes way more complex if there was error checking. It's like:
"mapPixel takes a function with parameters of the pixel coordinates and values, and returns the new pixel values, which default to the previous value if nil."
"mapPixel takes a function with parameters of the pixel coordinates and values, and returns the new pixel values, which default to the previous value if nil, unless one of the red, green, or blue values is nil in which case it errors, but not if all the return values are nil."
Surely that could be better written, but even then, it could still be the case that understanding the error checking takes more time than understanding the purpose of the method. :P Someone could misspell a variable name and be like "huh, my colors are wacky" and have to recheck their code, but I think the cost of that is less than the cost of mapPixel being more complicated, and therefore taking longer to understand.
Also, I just remembered that the standard map functions don't have a direct relation to the input data, typically. That is the output of map is only related to the output of the procedure applied to the input, not the input itself. Is a mapping function that doesn't return anything even valid?
I think I would rather mapPixel require the function argument to return at least r,g,b. All the options for returning default values seem fairly arbitrary - as a lover I would much rather have an error when not returning r,g,b than something being set which I was not expecting.
It's very trivial to return r,g,b, on my own in the function argument's code, and much more explicitly shows what's going on.