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

[Jacob Carlborg]

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

Oh, god, no. We already have way too many special magic members. 
We don't need any more. `__traits` is great because it has it's 
own namespace. It occupies just one keyword and you can add all 
the identifiers in the world without the risk of breaking 
existing code.

Yes, I know that identifiers starting with `__` is reserved, but 
there's nothing that stops anyone from using an identifier which 
starts with `__`. In my opinion is the double underscores that 
makes it look ugly. Your suggestion is not an improvement. Same 
thing with UFCS, it's no point if you need to use parentheses 
anyway: `(1 + 2).toString`.

If we need a new syntax for this (which I don't think we need), 
it would be better with some built-in/compiler recognized 
functions declared somewhere in the `core` package. Then it would 
be possible to use standard language constructs to deal with 
multiple symbols with the same name.

--
/Jacob Carlborg