The Great Glob Import Extinction (and requisite finishing touches)

[ExpHP]

As before, I tried to break this up into individually readible commits.

It includes several of the last-minute breaking changes mentioned here, each as its own commit (or two) near the beginning. This is followed by one really big commit that corrects all of the examples and tests to use the new use paths.

Closes #101

[ExpHP]

wtf why is 'doc updates for Func' listed after TGGIE, I thought I fixed all of the timestamps >_<

whatever, at least that's the only one out of order this time, and I guess it isn't THAT confusing.

[ExpHP]

Since you moved the indices stuff, maybe it might make sense to move Poly and Func in this PR as well? Just asking.

Very much so, I am simply not sure where to put them =P

[lloydmeta]

My simple mind is saying just a poly.rs module in frunk_core might work? Open to other ideas of course :)

[ExpHP]

I considered it and am open to changing it, but note that there is an observable difference to the user between a regular struct with a private member and a tuple struct with a private member. (the trouble is, I'm not actually sure at this point which is better for reified indices, or if it even matters at all!)

On Mon, Apr 9, 2018, 7:32 AM Mazdak Farrokhzad notifications@github.com wrote:

@Centril commented on this pull request.

In core/src/indices.rs https://github.com/lloydmeta/frunk/pull/116#discussion_r180064960:

+//! inference wherever the compiler can see that there is a unique solution. +//! Therefore, you don't really have much of a reason to use the things in this +//! module. +//! +//! ...yet. ;) + +use std::marker::PhantomData; + +// Largely lifted from https://github.com/Sgeo/hlist/blob/master/src/lib.rs#L30 + +/// Used as an index into an HList. +/// +/// Here is 0, pointing to the head of the HList. +/// +/// Users should normally allow type inference to create this type. +pub struct Here(());

Should probably use { priv: () } here to make the privacy thingy more intentional-looking.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/lloydmeta/frunk/pull/116#pullrequestreview-110418983, or mute the thread https://github.com/notifications/unsubscribe-auth/ABWI0BAjjgIDpeo3lVyyfR3yrh4EYvjmks5tm0bYgaJpZM4TLw6X .

[ExpHP]

Scratch that, actually. Even tuple structs can use struct expression syntax and struct pattern syntax, so I guess regular structs are the clear winner for maximum flexibility in the future. I will change both Here and There.

On Mon, Apr 9, 2018, 7:36 AM Michael Lamparski diagonaldevice@gmail.com wrote:

I considered it and am open to changing it, but note that there is an observable difference to the user between a regular struct with a private member and a tuple struct with a private member. (the trouble is, I'm not actually sure at this point which is better for reified indices, or if it even matters at all!)

On Mon, Apr 9, 2018, 7:32 AM Mazdak Farrokhzad notifications@github.com wrote:

@Centril commented on this pull request.

In core/src/indices.rs https://github.com/lloydmeta/frunk/pull/116#discussion_r180064960:

+//! inference wherever the compiler can see that there is a unique solution. +//! Therefore, you don't really have much of a reason to use the things in this +//! module. +//! +//! ...yet. ;) + +use std::marker::PhantomData; + +// Largely lifted from https://github.com/Sgeo/hlist/blob/master/src/lib.rs#L30 + +/// Used as an index into an HList. +/// +/// Here is 0, pointing to the head of the HList. +/// +/// Users should normally allow type inference to create this type. +pub struct Here(());

Should probably use { priv: () } here to make the privacy thingy more intentional-looking.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/lloydmeta/frunk/pull/116#pullrequestreview-110418983, or mute the thread https://github.com/notifications/unsubscribe-auth/ABWI0BAjjgIDpeo3lVyyfR3yrh4EYvjmks5tm0bYgaJpZM4TLw6X .

[ExpHP]

Oops, mail replies don't appear where I thought they would on this page. =P

[ExpHP]

My simple mind is saying just a poly.rs module in frunk_core might work? Open to other ideas of course :)

This is definitely possible, although I don't think ToRef will quite fit in there. My trouble is with having too many little modules for small groups of things; I feel this harms discoverability.

I tried making them live at the root but I didn't like how the resulting documentation for frunk_core/index.html looked (it made them look too important); so for now I've moved them into a public module called traits. This name feels vague enough to be able to cover most of the things I want to remove from HList; however, it goes counter to the naming scheme of the rest of frunk (which mostly groups things by feature).