Functions you want to memoize have to be visible to std.functional.memoize, so it only works with public functions. Is this a bug or merely a bugbear?

On Saturday, 12 May 2012 at 09:08:30 UTC, John Chapman wrote:
> Functions you want to memoize have to be visible to std.functional.memoize, so it only works with public functions.

This is an artifact of the way access protection for alias parameters is currently implemented – when accessing (»resolving«) an alias parameter, protection attributes are checked in the same way as if you just wrote the symbol name, i.e. in the scope of the module where e.g. memoize is defined.

In my opinion, this is a … uhm … _questionable_ design decision, even more so than the fact that private module members are not at all private to that module (as they are still taken into account for overload resolution). Several other issues, e.g. being unable to std.concurrency.spawn() private functions, are also caused by this.

David

On Saturday, 12 May 2012 at 11:33:10 UTC, David Nadlinger wrote:
> In my opinion, this is a … uhm … _questionable_ design decision, […]

If it wasn't clear from the context: I'd propose to instead check protection for aliases exactly once at the place where it is »created«. In my opinion, this is clearly the behavior that one would intuitively expect, just like for (e.g. function) pointers, where it doesn't matter if the type system would allow you to access the entity directly once somebody who is allowed to passed you a reference.

The only possible complication I can see right now caused by this is with (rarely used) synchronized classes, where a closer look might be necessary regarding aliases to private functions (which are not automatically protected by the class mutex).

David