Jump to page: 1 25  
Page
Thread overview
core.traits?
Jan 05, 2019
Manu
Jan 05, 2019
kinke
Jan 08, 2019
Brian
Jan 05, 2019
Seb
Jan 05, 2019
Nicholas Wilson
Jan 06, 2019
Walter Bright
Jan 07, 2019
Manu
Jan 07, 2019
H. S. Teoh
Jan 07, 2019
H. S. Teoh
Jan 07, 2019
Manu
Jan 07, 2019
Jonathan M Davis
Jan 08, 2019
Nick Treleaven
Jan 07, 2019
Manu
Jan 08, 2019
Mike Franklin
Jan 08, 2019
Mike Franklin
Jan 09, 2019
Jacob Carlborg
Jan 08, 2019
kinke
Jan 09, 2019
Mike Franklin
Jan 09, 2019
Neia Neutuladh
Jan 09, 2019
Mike Franklin
Jan 09, 2019
Jacob Carlborg
Jan 09, 2019
Mike Franklin
Jan 09, 2019
Patrick Schluter
Jan 09, 2019
bioinfornatics
Jan 09, 2019
H. S. Teoh
Jan 09, 2019
jmh530
Jan 09, 2019
H. S. Teoh
Jan 10, 2019
Mike Franklin
Jan 10, 2019
Mike Franklin
Jan 10, 2019
Ethan
Jan 10, 2019
Ethan
Jan 10, 2019
luckoverthere
Jan 11, 2019
Ethan
Jan 11, 2019
bioinfornatics
Jan 11, 2019
Ethan
Jan 11, 2019
bioinfornatics
Jan 09, 2019
Jacob Carlborg
Jan 10, 2019
Mike Franklin
January 05, 2019
So, druntime has core.internal.traits where a bunch of std.traits have
been mirrored to support internal machinery within druntime.
This is clear evidence that a lot of these traits are really
super-critical to doing basically anything interesting with D.
I have experience with no-phobos projects in the past where I've been
frustrated that I had to mirror all the traits I needed manually.

I suggest, a fair set of std.traits (no-brainer traits that you
basically can't live without) should be officially moved to
core.traits, so that they are always available to all D users.
Traits are pure-templates, they don't emit code, and have no impact on
the size of the druntime binary. They significantly shouldn't affect
build times unless they are instantiated.
...and they're already there in core.internal.traits.

We should move them to core.traits, and that should be their official home. It really just makes sense. Uncontroversial low-level traits don't belong in phobos.
January 05, 2019
On Saturday, 5 January 2019 at 21:12:54 UTC, Manu wrote:
> We should move them to core.traits, and that should be their official home. It really just makes sense. Uncontroversial low-level traits don't belong in phobos.

I fully agree.
January 05, 2019
On Saturday, 5 January 2019 at 21:12:54 UTC, Manu wrote:
> So, druntime has core.internal.traits where a bunch of std.traits have
> been mirrored to support internal machinery within druntime.
> This is clear evidence that a lot of these traits are really
> super-critical to doing basically anything interesting with D.
> I have experience with no-phobos projects in the past where I've been
> frustrated that I had to mirror all the traits I needed manually.
>
> [...]

I would go even one step further and move everything and just alias things in std.traits, s.t. no breakage happens.
January 05, 2019
On Saturday, 5 January 2019 at 21:12:54 UTC, Manu wrote:
> So, druntime has core.internal.traits where a bunch of std.traits have
> been mirrored to support internal machinery within druntime.
> This is clear evidence that a lot of these traits are really
> super-critical to doing basically anything interesting with D.
> I have experience with no-phobos projects in the past where I've been
> frustrated that I had to mirror all the traits I needed manually.
>
> [...]

Makes sense to me.
January 05, 2019
On 1/5/2019 1:12 PM, Manu wrote:
> We should move them to core.traits, and that should be their official
> home. It really just makes sense. Uncontroversial low-level traits
> don't belong in phobos.

Sounds good.

January 07, 2019
On Sat, Jan 5, 2019 at 11:00 PM Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 1/5/2019 1:12 PM, Manu wrote:
> > We should move them to core.traits, and that should be their official home. It really just makes sense. Uncontroversial low-level traits don't belong in phobos.
>
> Sounds good.

Okay, so this is a challenging effort, since phobos is such a tangled
rats nets of chaos...
But attempting to move some traits immediately calls into question std.meta.
I think we can all agree that Alias and AliasSeq should be in druntime
along with core traits... but where should it live?
Should there be core.meta as well? It's kinda like core.traits, in
that it doesn't include runtime code, it doesn't increase the payload
of druntime.lib for end-users..
Perhaps AliasSeq should live somewhere different?
I'm feeling like a lean/trimmed-down core.meta might want to exist
next to core.traits though; it seems reasonable.

...yes, this process will go on and on. The only way forward is to take each hurdle one at a time... and ideally, in attempting this effort, we can de-tangle a lot of cruft during the process.
January 07, 2019
On Mon, Jan 07, 2019 at 01:25:17PM -0800, Manu via Digitalmars-d wrote: [...]
> Okay, so this is a challenging effort, since phobos is such a tangled rats nets of chaos...

It's already gotten better over the years in some ways (though not others -- unfortunately I'm afraid std.traits might be one of the places where things have probably gotten more tangled).  It certainly hasn't lived up to the promise of that old Phobos Philosophy page that once existed but has since been removed, of Phobos being a collection of lightweight, self-contained, mostly-orthogonal, reusable components.  It has become quite the opposite, where the dependency graph of Phobos modules is approaching pretty close to being a complete graph.  (And yes, there are some pretty deep-seated cyclic dependencies that thus far nobody has been able to truly unravel in any satisfactory way.)


> But attempting to move some traits immediately calls into question std.meta.  I think we can all agree that Alias and AliasSeq should be in druntime along with core traits... but where should it live? Should there be core.meta as well? It's kinda like core.traits, in that it doesn't include runtime code, it doesn't increase the payload of druntime.lib for end-users..

Shouldn't all of core.traits be like that?  I'd hardly expect any runtime component to be associated with something called 'traits'.


> Perhaps AliasSeq should live somewhere different?
> I'm feeling like a lean/trimmed-down core.meta might want to exist
> next to core.traits though; it seems reasonable.

I'm afraid this would set the wrong precedent -- since there's core.traits for std.traits and core.meta for std.meta, why not also have core.typecons, core.range, and then it's all gonna go downhill from there, and before you know it there's gonna be core.stdio and core.format... *shudder*


> ...yes, this process will go on and on. The only way forward is to take each hurdle one at a time... and ideally, in attempting this effort, we can de-tangle a lot of cruft during the process.

I'm tempted to say we should put everything in core.traits for now. And just the absolute bare minimum it takes to meet whatever druntime needs, and nothing more.


T

-- 
I think Debian's doing something wrong, `apt-get install pesticide', doesn't seem to remove the bugs on my system! -- Mike Dresser
January 07, 2019
On 1/7/19 4:25 PM, Manu wrote:
> On Sat, Jan 5, 2019 at 11:00 PM Walter Bright via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>>
>> On 1/5/2019 1:12 PM, Manu wrote:
>>> We should move them to core.traits, and that should be their official
>>> home. It really just makes sense. Uncontroversial low-level traits
>>> don't belong in phobos.
>>
>> Sounds good.
> 
> Okay, so this is a challenging effort, since phobos is such a tangled
> rats nets of chaos...
> But attempting to move some traits immediately calls into question std.meta.
> I think we can all agree that Alias and AliasSeq should be in druntime
> along with core traits... but where should it live?
> Should there be core.meta as well? It's kinda like core.traits, in
> that it doesn't include runtime code, it doesn't increase the payload
> of druntime.lib for end-users..
> Perhaps AliasSeq should live somewhere different?
> I'm feeling like a lean/trimmed-down core.meta might want to exist
> next to core.traits though; it seems reasonable.
> 
> ....yes, this process will go on and on. The only way forward is to
> take each hurdle one at a time... and ideally, in attempting this
> effort, we can de-tangle a lot of cruft during the process.
> 

I was going to say core.meta should just have the basic definitions, but why not just dump all of it in there. As you said, they are templates (and so you only pay if you use them), and really part of the core language definition.

There are already parts of std.meta inside core.internal as well, so if we want to be consistent, we should just move it all ;)

-Steve
January 07, 2019
On 1/7/19 4:41 PM, H. S. Teoh wrote:
> On Mon, Jan 07, 2019 at 01:25:17PM -0800, Manu via Digitalmars-d wrote:
> [...]
>> Perhaps AliasSeq should live somewhere different?
>> I'm feeling like a lean/trimmed-down core.meta might want to exist
>> next to core.traits though; it seems reasonable.
> 
> I'm afraid this would set the wrong precedent -- since there's
> core.traits for std.traits and core.meta for std.meta, why not also have
> core.typecons, core.range, and then it's all gonna go downhill from
> there, and before you know it there's gonna be core.stdio and
> core.format... *shudder*

std.internal.traits contains pieces of std.meta -- a quick look shows it has AliasSeq (but under the name TypeTuple), allSatisfy, anySatisfy, Filter, staticMap. We might as well just move the whole thing there.

The fear of moving other pieces is real, but only if you look superficially. traits and meta are really part of the language, I can't imagine using D without it (and neither can any of the people who put pieces of those modules into druntime).

I don't want to see anything more complex and interdependent get sucked in. I know the goal for Manu right now is emplace, which does feel like a language feature. But as has been said many times here, std.traits is a no-brainer, and std.meta is really a building block that std.traits uses.

-Steve
January 07, 2019
On Mon, Jan 07, 2019 at 04:54:15PM -0500, Steven Schveighoffer via Digitalmars-d wrote:
> On 1/7/19 4:41 PM, H. S. Teoh wrote:
> > On Mon, Jan 07, 2019 at 01:25:17PM -0800, Manu via Digitalmars-d wrote: [...]
> > > Perhaps AliasSeq should live somewhere different?  I'm feeling like a lean/trimmed-down core.meta might want to exist next to core.traits though; it seems reasonable.
> > 
> > I'm afraid this would set the wrong precedent -- since there's core.traits for std.traits and core.meta for std.meta, why not also have core.typecons, core.range, and then it's all gonna go downhill from there, and before you know it there's gonna be core.stdio and core.format... *shudder*
> 
> std.internal.traits contains pieces of std.meta -- a quick look shows it has AliasSeq (but under the name TypeTuple),

What, wut...?  `TypeTuple` still exists?! I thought we had gone through a somewhat painful deprecation cycle just to kill it off. Or is that cycle not done yet...?


> allSatisfy, anySatisfy, Filter, staticMap. We might as well just move the whole thing there.

I dunno, IMO allSatisfy, anySatisfy, and esp. Filter and staticMap are all heavy-weight templates (not in terms of code complexity, but in the sheer amount of templates that will get instantiated when you use them, AKA compiler slowdown fuel).  I'm not so sure they should go into druntime.


> The fear of moving other pieces is real, but only if you look superficially.  traits and meta are really part of the language, I can't imagine using D without it (and neither can any of the people who put pieces of those modules into druntime).

Actually, I find myself redefining AliasSeq locally with a shorter name all the time.  Scarily enough, doing that is shorter than typing `import std.traits : AliasSeq;`.


> I don't want to see anything more complex and interdependent get sucked in.  I know the goal for Manu right now is emplace, which does feel like a language feature. But as has been said many times here, std.traits is a no-brainer, and std.meta is really a building block that std.traits uses.
[...]

Wait, so you're saying we should move the *entire* std.meta and std.traits to druntime...?


T

-- 
ASCII stupid question, getty stupid ANSI.
« First   ‹ Prev
1 2 3 4 5