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