On 10/7/2020 1:29 PM, Adam D. Ruppe wrote:
> If the language is going to pretend modules are children of packages (which they aren't and it shouldn't!!!!!), it should at least do so consistently. As it sits now, stuff that was possible a couple versions ago is now just hopelessly broken now.

Please file regressions on bugzilla.

On Wednesday, 7 October 2020 at 18:46:07 UTC, Steven Schveighoffer wrote:
> Why both? The first thing that struck me is that, std.stdio is NOT a type. `is` specifically says it works with types. So that seems out of place (indeed the documentation does not mention anything special about this).

Guess, it's a bit of pl theory, I saw mentioned somewhere that modules count as types. Not sure about packages though.

On Thursday, 8 October 2020 at 08:12:51 UTC, Kagamin wrote:
> On Wednesday, 7 October 2020 at 18:46:07 UTC, Steven Schveighoffer wrote:
>> Why both? The first thing that struck me is that, std.stdio is NOT a type. `is` specifically says it works with types. So that seems out of place (indeed the documentation does not mention anything special about this).
>
> Guess, it's a bit of pl theory, I saw mentioned somewhere that modules count as types. Not sure about packages though.

Well you can see a module as being the same as a singleton struct.
In D though Modules are not types. IIRC.

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

On Wednesday, 7 October 2020 at 19:44:59 UTC, H. S. Teoh wrote:

> However, the way things turned out, it appears that __traits has become sorta a de facto standard for metaprogramming primitives, and Phobos has kinda fallen behind on the job.  So perhaps it's time to rethink this decision?

Yes, because just wrapping existing `__traits` in templates don't give you much value, just a different syntax. But it comes with all the problems that templates bring (which have been discussed many times).

--
/Jacob Carlborg

On Thursday, 8 October 2020 at 09:42:22 UTC, Jacob Carlborg wrote:
> On Wednesday, 7 October 2020 at 19:44:59 UTC, H. S. Teoh wrote:
>
>
> Yes, because just wrapping existing `__traits` in templates don't give you much value, just a different syntax.

Wrapping __traits in templates is a necessity if you want to use them for anything interesting (such as passing them to higher order functions):

filter!(__traits(isPOD), A, B C); // no way
filter!(isPod, A, B, C); // can be

On Thursday, 8 October 2020 at 10:11:59 UTC, Max Samukha wrote:
> On Thursday, 8 October 2020 at 09:42:22 UTC, Jacob Carlborg wrote:
>> On Wednesday, 7 October 2020 at 19:44:59 UTC, H. S. Teoh wrote:
>>
>>
>> Yes, because just wrapping existing `__traits` in templates don't give you much value, just a different syntax.
>
> Wrapping __traits in templates is a necessity if you want to use them for anything interesting (such as passing them to higher order functions):
>
> filter!(__traits(isPOD), A, B C); // no way
> filter!(isPod, A, B, C); // can be

or you use type functions which can use them at ctfe;)

On Wednesday, 7 October 2020 at 23:17:18 UTC, Walter Bright wrote:
> I'm not sure which is the one to go, but we should not have both.

I think that the line of reasoning is that __traits should be leveraged by std.traits to offer user-friendly alternatives. Therefore, in this case I suggest that we deprecate `is(S == module)` (since a module is not a type anyway) and implement an isModule template in std.traits.

On Thursday, 8 October 2020 at 10:11:59 UTC, Max Samukha wrote:
> Wrapping __traits in templates is a necessity if you want to use them for anything interesting (such as passing them to higher order functions):

I kinda wish we had a template lambda.

On Thursday, 8 October 2020 at 12:54:49 UTC, Adam D. Ruppe wrote:
> On Thursday, 8 October 2020 at 10:11:59 UTC, Max Samukha wrote:
>> Wrapping __traits in templates is a necessity if you want to use them for anything interesting (such as passing them to higher order functions):
>
> I kinda wish we had a template lambda.

you mean alias compiles (__top A) = ((__top x) => __traits(compiles, x)(A); ?