#rust-lang

cramertj, I think its not unreasonable to have `abstract type` as the impl of an associated type

its just a modifier on the definition similar to `default` for specialization

im not sold that the abstract type syntax is better, i just dont think its categorically ruled out by that difference

finally published a blog post on the module system: https://internals.rust-lang.org/t/revisiting-ru...

cc wycats, nrc, woboats, est31, ubsandroid2

and lots of others :)

cramertj: mm yeah, the trait object thing is always a thorn in my side

aturon: pinned for later - looks long :-)

acrichto: would love a gut check on ^

aturon: looks like there are some styling issues with items like "**futures**"

"an exercise I performed repeatedly" is missing the close paren. This hurts the programmer

aturon: "I spent some time surveying some of the most popular and most respected crates to get a qualitative feel for this question, including: futures, regex, rayon, log, openssl, flate2, bytes, irc, clap, url, serde, chalk , std and chrono" - sorry to be a broken record, these are all library crates, no apps

chalk is an app :)

i looked at Cargo as well

i'm curious to hear more about how you see the distinction playing out

ah, ok, one app :-)

heh

nrc: can you elaborate on the difference you expect to find?

(you probably have spelled it out before but i no longer recall it)

I'm not entirely sure, and I think that probably libraries have strictly more complex needs than apps, so if we come up for a good system for apps too, but it is probably worth sanity checking with apps

ok, that matches my intuition also

the big difference I think is that library authors are likely to care more about what is exported

right

but app authors dont

and app authors probably (but not always) will care more about encapsulation

so i think for apps, this boils down to: (1) you never use _ and (2) you very rarely use re-exports

(the _ in the proposal)

I haven't finished the post yet

istm for an app, that every module should be a `_` one, rather than never using it?

at least, you'd get better dead code coverage

ehhh :)

nrc: actually i don't think that matters much for dead code coverage unless you're *also* marking all of your items pub

anyway seems like small potatoes

I think you've mentioned before you think module privacy and other item privacy are kind of different? This proposal makes me feel they are very different, which I've not noticed so much with the current system

I'm not sure if that is good or bad, just an observation

nrc: the key thing about modules is: the only thing they do is contain other items; they have no inherent functionality

nrc: therefore, a module that is visible to you but contains no items that are visible to you is totally irrelevant

making everything `_` rather than pub is arguably better if you one day evolve your app into a lib (which I think is common-ish), but again, probably small potatoes

nrc: hence the pub vs pub(crate) distinction being the whole ballgame for modules

(this is not *quite* a slamdunk, in that sometimes modules contain items that are re-exported elsewhere, in which case you now have two paths to that item, and going via the submodule ties down a bit of the internal crate structure)

hmm, no private mods?

correct

(not counting inline modules, which i ignore in the post)

my claim is that anything finer-grained than pub(crate) for a module name is not doing much for you

In my code I feel like `pub mod` is less common than `mod` currently, maybe not important

yeah i think most of that would turn into "these aren't even modules" in this proposal

at least sometimes I have reasoned that an entire module is private, I can't remember why

nrc: hm so my argument is, the only thing that a module being visible gives you is that you can use it's name to access items within it --

and either the items were private anyway,

or, if they're visible to you, they're almost certainly re-exported in another location you can access

however, in today's setup, i think it is common to make modules private when they contain `pub` items that should actually be `pub(super)` or some such

I think it is nice to reason that an entire module is private, but re-exports prevent that being really useful, I guess

but i think in this proposal that kind of thing flattens out and such privacy gymnastics are not necessary

yeah, that sounds like a win

I think I have a use case which is reading a crate to find out how it works, rather to find out what I can use when calling it. I find privacy useful in that case, even if it is not 100% conservative - maybe because I would read top-down I would see re-exports? Or maybe just because they are rare in apps.

nrc: module privacy specifically?

nrc: it might be worthwhile to dive into a concrete example

I think so, yeah

different point - I am not happy about relying more on pub(...) - I was happy with that syntax because it was meant to be rare. Making pub(self) and pub(crate) common feels bad

nrc: it does make it easier to see, at an arbitrary point in the hierarchy, "What could sibling modules possibly see?"

nrc: yeah if we go this route we definitely need to think about sugar

so, concrete example, rustfmt - which is kind of a hybrid between an app and lib - https://github.com/rust-lang-nursery/rustfmt/bl...

if I were coming new to rustfmt and wanted to figure out how it worked, I'd start with that list

and the pub items in the root

nrc: ok -- i think you're saying: at this level, `pub` tells you which modules are "entry points" that you should read first?

the pub mods immediately jump out as places to start reading, whereas I can be pretty sure that the non-pub `mod`s are implementation detail - furthermore, that each of those is going to self-contained, vs things that are more global

nrc: right makes sense. but at least at the top level, the _ distinction should convey the same thing i think?

probably

it would be partly convention, but I guess that it is today too

well, except that in an app (c.f. lib) one might not use `_` at all

sorry, I feel like I'm just sloshing thoughts around

I'll finish reading and think and then should be able to give better quality feedback

nrc: no worries! i'm just drinking wine and responding to emails and don't mind a bit :)

:-)

"Breaking code into files without module structure: the futures example" this seems pure win :-)

yeah! change: delete a few hundred lines of code.

aturon: umm

hmm

aturon: I'm starting the blog post, I can't finish it because work

but... would it be so bad to bring back .rc files?

(or something that did that)

ubsandroid2: i mention that as a optional add-on toward the end

there's also an alternative proposal that's more directly focused on that

aturon: like, I'm thinking maybe

implicit modules + if you want/need to be explicit for bigger projects

ubsandroid2: right, exactly

then use something like a .rc file

that's precisely what i had in mind

aturon: cool, I gotta go make coffee

o7

(though i don't see these as "implicit" modules, but rather modules explicitly described by the file system ;-)

ubsandroid2: ttyl :)

aturon: 🍅 🥔

aturon: well, that got me thinking

I feel like I like most of the proposal, but the reliance on the pub(...) forms is a major downside for me

but most of all it got me thinking about really, how do I make use of encapsulation when I code

the sibling pseudo-modules is a new paradigm in a way

and it got me thinking about privacy and so forth

and again the difference between apps and libs

in this case

I think a library module typically exposes one (or a small number) of 'classes'

or a set of related functions

whereas an app module might expose a bunch of datatypes and fairly heterogeneous functions

and in a lib, there tends to not be so many private items, I think