Passing private functions to template algorithms

Timon Gehr via Digitalmars-d digitalmars-d at puremagic.com
Sun Jun 12 06:52:09 PDT 2016


On 12.06.2016 13:05, Dicebot wrote:
> 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.
> ...

In my mind it already is a first-class symbol (it can even be part of an 
overload set), but after you look it up, it is immediately rewritten to 
another symbol.

https://github.com/tgehr/d-compiler/blob/master/semantic.d#L4670

Does DMD special-case it during lookup instead?

>>> 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.

Probably I indeed misunderstood your concern, but what I disagree with 
is the notion that breaking code not directly checking for visibility is 
somehow a prerequisite for having the correct visibility checks in 
place. You may very well be right that it would be more consistent to 
return the name of the alias, but I think what .stringof returns is an 
independent concern. (Last time I checked, it was completely unspecified 
anyway btw.)

> 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,

There are no special cases in what I propose. The alias rewrite has 
nothing to do with lookup:

https://github.com/tgehr/d-compiler/blob/master/scope_.d#L185

I guess this is precisely your proposal too?

> it is matter of defining actual alias
> semantics so that generic access rules start being useful.
>

I agree. (Or maybe rather, it is a matter of defining both such that the 
resulting semantics are useful, I don't know precisely where DMD goes 
astray here.)


More information about the Digitalmars-d mailing list