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

Stefan Koch uplink.coder at googlemail.com
Wed Oct 7 20:08:02 UTC 2020


On Wednesday, 7 October 2020 at 19:15:30 UTC, Paul Backus wrote:
> On Wednesday, 7 October 2020 at 19:07:34 UTC, H. S. Teoh wrote:
>> I'm on the fence about this one. Having to type 
>> __traits(isModule,xxx) is painful.  Is it really necessary to 
>> make it so hard just to check whether a symbol is a module??  
>> It's not as if it's something we want to discourage.  Typing 
>> is(xxx == module) is much easier, and more pleasant on the 
>> eyes.
>
> IMO this is one of those situations where your pain is trying 
> to tell you something. If using __traits syntax is so painful 
> that we're willing to add hacky special cases to other language 
> features in order to avoid it, maybe the message we should take 
> from that is "we need to improve __traits syntax."
>
> 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)


More information about the Digitalmars-d mailing list