• John Chapman (3/3) May 12 2012 Functions you want to memoize have to be visible to
• David Nadlinger (13/15) May 12 2012 This is an artifact of the way access protection for alias
• David Nadlinger (13/15) May 12 2012 If it wasn't clear from the context: I'd propose to instead check

"John Chapman" <johnch_atms hotmail.com> writes:

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?

"David Nadlinger" <see klickverbot.at> writes:

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

"David Nadlinger" <see klickverbot.at> writes:

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