is(x = module) vs. __traits(isModule, x)

[Steven Schveighoffer]

On 10/7/20 4:19 PM, Paul Backus wrote:
> On Wednesday, 7 October 2020 at 20:08:02 UTC, Stefan Koch wrote:
>> On Wednesday, 7 October 2020 at 19:15:30 UTC, Paul Backus wrote:
>>>
>>> Here's my strawman proposal: turn all __traits into properties. A few 
>>> before-and-after examples:
>>>
>>> __traits(isModule, foo)
>>>   => foo.__isModule
>>>
>>> __traits(getMember, T, "x")
>>>   => T.__member("x")
>>>
>>> __traits(compiles, some(kind, of + expression))
>>>   => (some(kind, of + expression)).__compiles
>>
>> I don't think that looks much better.
>> __traits are actually fine in my eyes.
>> It's easy on semantic and parser.
>> Determining whether a trait applies and therefore should be imported 
>> into the properties of a given node is more nasty.
>> (It means you have to change semanticX and semanticY as well as 
>> resolvePropertiesX in DMD)
> 
> Couldn't you unconditionally lower <Node>.__isModule to 
> __traits(isModule, <Node>) regardless of what type of node it is, and 
> rely on the existing error messages for incorrect trait arguments? You 
> don't have to worry about shadowing "real" properties, because anything 
> that starts with "__" is a reserved identifier.

If we got type functions, and have UFCS, isn't this as easy as e.g.:

bool isModule(alias x) { return __traits(isModule, x); }

static assert(std.stdio.isModule);

bool hasMember(alias T, string membername) { return __traits(hasMember, 
T, membername); }

static assert(T.hasMember("foo"));

alias getMember(alias T, string membername) { return __traits(getMember, 
T, membername));

static assert(is(typeof(T.getMember("foo")) == int);

alias foomember = someTInstance.getMember("foo");

Then we don't have to care about keywords, or adding properties that 
can't be overridden, etc. It's just a normal symbol we can define 
wherever (like std.traits).

-Steve