• =?UTF-8?B?Tm9yZGzDtnc=?= (9/9) Jan 15 2017 Why is there both
• Jack Stouffer (5/10) Jan 15 2017 Several reasons, including usability in meta-templates like
• =?UTF-8?B?Tm9yZGzDtnc=?= (2/3) Jan 15 2017 Great!
• Bauss (4/14) Jan 16 2017 I thought it already did that. I hope this can be a thing so
• =?UTF-8?B?Tm9yZGzDtnc=?= (2/5) Jan 16 2017 That's exactly my plan.
• Bauss (2/8) Jan 16 2017 Thank you!
• =?UTF-8?B?Tm9yZGzDtnc=?= (4/5) Jan 17 2017 Plan:
• Nick Treleaven (7/8) Jan 19 2017 This makes (at least) UnsignedTypeOf unused in Phobos, and it's
• Stefan Koch (6/16) Jan 16 2017 There is a simple reason, you don't want complicated
• Bauss (7/29) Jan 16 2017 I believe it still makes sense, since the logic need not to be
• Jonathan M Davis via Digitalmars-d (8/30) Jan 16 2017 I can see that as an argument not to add something that it's in std.trai...
• Stefan Koch (8/16) Jan 16 2017 Ah my bad, I thought nordlow was proposing implementing things as
• QAston (5/13) Jan 17 2017 Why? Because working with introspection in D requires constantly
• Jonathan M Davis via Digitalmars-d (8/22) Jan 17 2017 That's completely unaffected by whether a trait in std.traits uses somet...

=?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:

Why is there both

http://dlang.org/phobos/std_traits.html

and the builtin

https://dlang.org/spec/traits.html

?

Should we modify std.traits to make use of __traits? I've noticed 
measurably faster compilations with __traits instead of 
std.traits for simple things such as isIntegral, isUnsigned, etc.

If so, I'll happily make that happen!

Jack Stouffer <jack jackstouffer.com> writes:

On Sunday, 15 January 2017 at 12:53:04 UTC, Nordlöw wrote:
 Why is there both

 http://dlang.org/phobos/std_traits.html

 and the builtin

 https://dlang.org/spec/traits.html

Several reasons, including usability in meta-templates like 
allSatisfy and the fact that it's way more user friendly and 
clear as a template.

 Should we modify std.traits to make use of __traits?

If it's faster and passes all of the tests, then sure.

=?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:

On Sunday, 15 January 2017 at 13:45:52 UTC, Jack Stouffer wrote:
 If it's faster and passes all of the tests, then sure.

Great!

Bauss <jj_1337 live.dk> writes:

On Sunday, 15 January 2017 at 12:53:04 UTC, Nordlöw wrote:
 Why is there both

 http://dlang.org/phobos/std_traits.html

 and the builtin

 https://dlang.org/spec/traits.html

 ?

 Should we modify std.traits to make use of __traits? I've 
 noticed measurably faster compilations with __traits instead of 
 std.traits for simple things such as isIntegral, isUnsigned, 
 etc.

 If so, I'll happily make that happen!

I thought it already did that. I hope this can be a thing so 
std.traits actually makes use of what's build-in, rather than 
attemtping to apply the same logic that arleady exist elsewhere.

=?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:

On Monday, 16 January 2017 at 09:09:34 UTC, Bauss wrote:
 I thought it already did that. I hope this can be a thing so 
 std.traits actually makes use of what's build-in, rather than 
 attemtping to apply the same logic that arleady exist elsewhere.

That's exactly my plan.

Bauss <jj_1337 live.dk> writes:

On Monday, 16 January 2017 at 11:20:16 UTC, Nordlöw wrote:
 On Monday, 16 January 2017 at 09:09:34 UTC, Bauss wrote:
 I thought it already did that. I hope this can be a thing so 
 std.traits actually makes use of what's build-in, rather than 
 attemtping to apply the same logic that arleady exist 
 elsewhere.

 That's exactly my plan.

Thank you!

=?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:

On Monday, 16 January 2017 at 11:20:16 UTC, Nordlöw wrote:
 That's exactly my plan.

Plan:

https://github.com/dlang/phobos/pull/5038

Feedsback, please.

Nick Treleaven <nick geany.org> writes:

On Tuesday, 17 January 2017 at 18:22:06 UTC, Nordlöw wrote:
 https://github.com/dlang/phobos/pull/5038

This makes (at least) UnsignedTypeOf unused in Phobos, and it's 
undocumented but public. There are LREFs in the std.traits docs 
under the SomethingTypeOf section - none of these links go 
anywhere AFAICT. Presumably the links should be removed from the 
docs (independently of the above pull), but should unused 
undocumented public templates also be removed?

Stefan Koch <uplink.coder googlemail.com> writes:

On Sunday, 15 January 2017 at 12:53:04 UTC, Nordlöw wrote:
 Why is there both

 http://dlang.org/phobos/std_traits.html

 and the builtin

 https://dlang.org/spec/traits.html

 ?

 Should we modify std.traits to make use of __traits? I've 
 noticed measurably faster compilations with __traits instead of 
 std.traits for simple things such as isIntegral, isUnsigned, 
 etc.

 If so, I'll happily make that happen!

There is a simple reason, you don't want complicated 
type-introspection logic welded into the compiler.

The reason why std.traits it slow is because of inefficiencies 
inside the template-system, which I intend to fix.
Therefore your efforts would be wasted.

Bauss <jj_1337 live.dk> writes:

On Monday, 16 January 2017 at 11:54:23 UTC, Stefan Koch wrote:
 On Sunday, 15 January 2017 at 12:53:04 UTC, Nordlöw wrote:
 Why is there both

 http://dlang.org/phobos/std_traits.html

 and the builtin

 https://dlang.org/spec/traits.html

 ?

 Should we modify std.traits to make use of __traits? I've 
 noticed measurably faster compilations with __traits instead 
 of std.traits for simple things such as isIntegral, 
 isUnsigned, etc.

 If so, I'll happily make that happen!

 There is a simple reason, you don't want complicated 
 type-introspection logic welded into the compiler.

 The reason why std.traits it slow is because of inefficiencies 
 inside the template-system, which I intend to fix.
 Therefore your efforts would be wasted.

I believe it still makes sense, since the logic need not to be 
applied both in the standard library and the compiler, when the 
compiler can deliver the information to the standard library, the 
standard library should use that information and at most wrap 
around it, not attempt to create an identical logic to that of 
the compiler.

Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Monday, January 16, 2017 11:54:23 Stefan Koch via Digitalmars-d wrote:
 On Sunday, 15 January 2017 at 12:53:04 UTC, Nordlöw wrote:
 Why is there both

 http://dlang.org/phobos/std_traits.html

 and the builtin

 https://dlang.org/spec/traits.html

 ?

 Should we modify std.traits to make use of __traits? I've
 noticed measurably faster compilations with __traits instead of
 std.traits for simple things such as isIntegral, isUnsigned,
 etc.

 If so, I'll happily make that happen!

 There is a simple reason, you don't want complicated
 type-introspection logic welded into the compiler.

 The reason why std.traits it slow is because of inefficiencies
 inside the template-system, which I intend to fix.
 Therefore your efforts would be wasted.

I can see that as an argument not to add something that it's in std.traits
to __traits or why something should be added to std.traits rather than
__traits, but if something already exists with __traits, why duplicate that
logic in std.traits? It seems like it complicates std.traits for no benefit
as well as risking having the behavior of  __traits and std.traits differ,
which could cause confusion and bugs.

- Jonathan M Davis

Stefan Koch <uplink.coder googlemail.com> writes:

On Monday, 16 January 2017 at 19:45:33 UTC, Jonathan M Davis 
wrote:

 I can see that as an argument not to add something that it's in 
 std.traits to __traits or why something should be added to 
 std.traits rather than __traits, but if something already 
 exists with __traits, why duplicate that logic in std.traits? 
 It seems like it complicates std.traits for no benefit as well 
 as risking having the behavior of  __traits and std.traits 
 differ, which could cause confusion and bugs.

 - Jonathan M Davis

Ah my bad, I thought nordlow was proposing implementing things as 
traits,
I did overlook that there are already __traits for that.

Well then Nordlow go ahead an transform the relevant 
phobos-traits.
to make use of __traits.

QAston <qaston gmail.com> writes:

On Monday, 16 January 2017 at 19:45:33 UTC, Jonathan M Davis 
wrote:
 I can see that as an argument not to add something that it's in 
 std.traits to __traits or why something should be added to 
 std.traits rather than __traits, but if something already 
 exists with __traits, why duplicate that logic in std.traits? 
 It seems like it complicates std.traits for no benefit as well 
 as risking having the behavior of  __traits and std.traits 
 differ, which could cause confusion and bugs.

 - Jonathan M Davis

Why? Because working with introspection in D requires constantly 
switching between at least 4 different documentation pages to 
find the introspection you're interested in.

Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Tuesday, January 17, 2017 11:17:10 QAston via Digitalmars-d wrote:
 On Monday, 16 January 2017 at 19:45:33 UTC, Jonathan M Davis

 wrote:
 I can see that as an argument not to add something that it's in
 std.traits to __traits or why something should be added to
 std.traits rather than __traits, but if something already
 exists with __traits, why duplicate that logic in std.traits?
 It seems like it complicates std.traits for no benefit as well
 as risking having the behavior of  __traits and std.traits
 differ, which could cause confusion and bugs.

 - Jonathan M Davis

 Why? Because working with introspection in D requires constantly
 switching between at least 4 different documentation pages to
 find the introspection you're interested in.

That's completely unaffected by whether a trait in std.traits uses something
from __traits or whether it implements it on its own. It is affected by
whether something is in __traits or std.traits, but that's not the question
here. What Nordlow is looking to do is make existing traits in std.traits
use the corresponding __traits where they already exist rather than having a
separate implementation. It's entirely an implementation detail.

- Jonathan M Davis