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

[Paul Backus]

On Thursday, 8 October 2020 at 09:38:40 UTC, Jacob Carlborg 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
>
> 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 `__`.

Except, you know, the language spec. I understand the desire to 
avoid breaking changes if possible, but why even bother to have 
reserved identifiers in the first place if you're going to treat 
them as sarcosanct? Even the ISO C standard is willing to make 
changes like this, and that's about the most conservative 
language there is.

In any case, it would be quite easy to put this behind a 
`-preview` flag and have a deprecation period during which the 
compiler warns about all uses of the identifiers that the 
language is planning to claim.

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

Are you sure? You really can't see any difference in readability 
between this

     __traits(getOverloads, __traits(parent, sym), 
__traits(identifier, sym))

and this?

    sym.__parent.__overloads(sym.__identifier)

Maybe it's not perfect, but surely it's still an improvement.

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

I would also be fine with this. Of course, they would have to be 
"magic" functions specially recognized by the compiler, not real 
ones, but at least that would let us get rid of the dreaded 
double-underscore.