Passing private functions to template algorithms

[Dicebot via Digitalmars-d]

On 06/12/2016 01:55 PM, Timon Gehr wrote:
> On 12.06.2016 10:28, Dicebot wrote:
>> On 06/07/2016 09:59 PM, Timon Gehr wrote:
>>> I think it is obvious that this should work. Visibility checks need to
>>> happen during identifier lookup. This lookup is happening in the module
>>> where isFileNothrow is visible.
>>
>> My understanding is that right now template alias argument means
>> transparent symbol lookup. It acts as if doesn't access alias symbol in
>> template but aliased one directly.
>> ...
> 
> The lookup accesses the alias and is immediately rewritten to refer to
> the aliased symbol. Visibility checks should be applied during the
> lookup, but not after the rewrite.

Yes, that is natural solution but it makes alias itself first-class
symbol which leads to my example snippet question.

>> I agree such semantics are sub-optimal but changing that can break quite
>> some existing idioms. Consider this snippet for example:
>>
>> enum name ( alias sym ) = sym.stringof;
>>
>> Right now it evaluates to name of passed symbol.  If we change lookup
>> semantics to be non-transparent, it must always return `sym` for
>> consistency.
>>
> 
> I completely disagree that this would need to happen. E.g.
> fullyQualifiedName should work with private symbols just as well as with
> public ones.
> 
> Maybe this is helpful: https://en.wikipedia.org/wiki/Information_hiding

Private or public is irrelevant here, it seems you have misunderstood my
concern. The essential question is "what the alias is?", not how it is
accessed. There must be no special cases for aliases regarding
private/public symbol access, it is matter of defining actual alias
semantics so that generic access rules start being useful.