__traits(compiles,...) <=> ? is(typeof(...))

[Timon Gehr]

On 10/30/2012 02:53 AM, Jonathan M Davis wrote:
> On Tuesday, October 30, 2012 02:22:42 Timon Gehr wrote:
>> On 10/30/2012 01:43 AM, Jonathan M Davis wrote:
>>> On Tuesday, October 30, 2012 00:29:22 Timon Gehr wrote:
>>>> On 10/30/2012 12:17 AM, Jonathan M Davis wrote:
>>>>> On Monday, October 29, 2012 23:38:34 Timon Gehr wrote:
>>>>>> On 10/29/2012 12:03 PM, Jonathan M Davis wrote:
>>>>>>> On Monday, October 29, 2012 11:42:59 Zhenya wrote:
>>>>>>>> Hi!
>>>>>>>>
>>>>>>>> Tell me please,in this code first and second static if,are these
>>>>>>>> equivalent?
>>>>>>>> with arg = 1, __traits(compiles,"check(arg);") = true,
>>>>>>>> is(typeof(check(arg))) = false.
>>>>>>>
>>>>>>> In principle, is(typeof(code)) checks whether the code in there is
>>>>>>> syntatically and semantically valid but does _not_ check whether the
>>>>>>> code
>>>>>>> actually compiles. For instance, it checks for the existence of the
>>>>>>> symbols
>>>>>>> that you use in it, but it doesn't check whether you can actually use
>>>>>>> the
>>>>>>> symbol (e.g. it's private in another module).
>>>>>>> ...
>>>>>>
>>>>>> Accessing private symbols is always illegal, even within typeof
>>>>>> expressions.>
>>>>>
>>>>> As I understand it, that's not supposed to be the case.
>>>>> is(typeof(T.init))
>>>>> tests for existance not for compilability, and private symbols are fully
>>>>> visible by everything that imports the module that they're in. They're
>>>>> just
>>>>> not accessible. I completely agree that it would be better for them to
>>>>> be
>>>>> hidden as well, but it doesn't work that way right now, and no one has
>>>>> been
>>>>> able to convince Walter that it should.
>>>>> ...
>>>>
>>>> That is a different issue.
>>>
>>> But as long as private symbols are visible, they should work with
>>> is(typeof(blah)), because it's testing for their existence, not whether
>>> they can be used or not..
>>>
>>> - Jonathan M Davis
>>
>> wtf.
>
> ??? Nothing else would make sense. As long as private symbols are visible,
> then typeof should interact with them like it interacts with all other visible
> symbols. It's not testing for compilability, just existence. It would be very
> inconsistent for it to consider private variables as non-existent when they're
> visible.

Even if there was no difference between accessibility in an information 
hiding context and accessibility related to existence of a suitable 
frame pointer, and therefore, an actual inconsistency, it would not be 
very clever to fix an inconsistency by generalising the stupid bits 
instead of the parts that are sane. You are arguing for a "language 
change" in either case.

> Everything else considers them to exist. It's just that nothing
> outside of the module that they're declared in can use them. The _only_ thing
> that private affects at this point is whether a symbol can be used. So, it
> should definitely affect __traits(compiles, foo), but since is(typeof(foo)) only
> cares about existence, not compilability, it should work with private
> variables.
>

Well, define 'work'. It should evaluate to 'false'. typeof(foo) should 
not compile if foo refers to a private declaration in a different 
module. Is that not obvious?

> Things change if/when private variable become invisible outside of their
> module, but for now, they're not.
>

I do not care whether they are invisible or not. In fact, this can 
become an implementation detail. What needs fixing is the symbol 
conflicts involving inaccessible symbols situation. It is ridiculous.