www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.traits vcs __traits

reply =?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!
Jan 15 2017
next sibling parent reply 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.
Jan 15 2017
parent =?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!
Jan 15 2017
prev sibling next sibling parent reply 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.
Jan 16 2017
parent reply =?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.
Jan 16 2017
next sibling parent 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!
Jan 16 2017
prev sibling parent reply =?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.
Jan 17 2017
parent 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?
Jan 19 2017
prev sibling parent reply 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.
Jan 16 2017
next sibling parent 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.
Jan 16 2017
prev sibling parent reply 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
Jan 16 2017
next sibling parent 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.
Jan 16 2017
prev sibling parent reply 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.
Jan 17 2017
parent 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
Jan 17 2017