spir: > Also, I think D should not annoy us with the func/delegate distinction -- > which is only for saving space -- and accept func defs that match the given > type signature. The annoying distinction is semantically irrelevant; the > signature is relevant.
A system language (that supports inline asm too, as D) must allow you to make your choices on practical (implementation) basis too. > (*) By the way, why does D call closures "delegates"? I find this very > misleading, since delegation already has some meaning in the context of > programming. And well, "closure" is well established precisely in this sense. > Sometimes, PL designers amaze me ;-) In D1 there were delegates (fat pointers) but not closures. So the name distinction was correct. Later closures were added, but the name didn't change. Bye, bearophile
