#rust-lang

not sure where that is going still

different thought

one thing I like about Rust privacy is the module-scoping - c.f., class-scoping in C++ or Java

I'm not sure whether pseudo-modules encourage or discourage that

I feel like it lets you make bigger modules (because you can use many files) and thus module-scoped privacy offers less encapsulation

and that encourages you to put functions in impls rather than use free functions, etc.

will think more, hopefully I'll have some more coherent thoughts tomorrow.

rjung: Do you think it would be possible for the intptrcast model to assign concrete and logical addresses on pointer creation, but not actually allowing non-logical pointers to access it until after casting it to an int?

Hm.. just making pointer comparisons with concrete pointers leak the other pointer seems reasonable

It does seem that that would kill off too many optimizations

rjung: I like the idea of encoding pointer to integer as a function in LLVM. That might enable us to measure the impact of intptrcast on optimizations

rjung: The argmemonly attribute on such a function declaration seems like a good fit

skimming this it seems very similar to what Rust has

aturon: the modules proposal overall looks fantastic!

aturon: the issues presented at the beginning make a lot of sense, and while I may have some comments about the specifics it overall seems like a great idea

acrichto: woo! that's great to hear. if you have a chance and want to write a slightly more detailed comment -- i'd in particular like to hear whether you think this would smooth ergonomics and readability for you personally -- that'd be helpful

aturon: ok sure yeah, I'll write up a comment later

aturon: https://internals.rust-lang.org/t/revisiting-ru...

est31: thanks, will take a look!

<3

holy crap, 1.2k people followed the link from internals to aturon's module post

in < 24 hours

eddyb: mtg?

:)

scott: scottmcm: mtg

wheee! :D

<3 this proposal

That was RFC 2056.

What's the document you're typing in?

I don't have the link.

aturon> https://paper.dropbox.com/doc/Implied-bounds-03...

Thanks, found it in the log too.

!gh rfcs 2063

[PR 2063] <open> Infer function signatures from trait declaration into 'impl's <https://github.com/rust-lang/rfcs/pull/2063>;

cramertj++

I wonder

why not just have implied generics

as in if impl<T: Debug> Foo<T> {} is so bad

and the proposed replacement is impl<T> Foo<T> {}

why not impl Foo<T> {

}

where is the reason in the <T> after the impl

ah I guess

you want to be able to differentiate between T

as generic param

and T as struct name