#rust-lang

Can someone review https://github.com/rust-lang/rfcs/pull/2353?

do you think these are a good fit for rust? https://internals.rust-lang.org/t/associated-st...

I'm trying to save my users some pain, suffering and confusion

in Java I'd do this with ASM/bytecode manipulation libs. doesn't quite work in Rust tho. ;)

Soni: it is interesting as a consistency fix, but I personally don't have uses for this.

hmm I guess I could also try something with macros for the time being... are macros truly hygienic if e.g. they make a static and a trait impl? (at least then I can #[doc(hidden)] the stuff) it won't be the nicest thing in the world (it won't be nice at all) but might work??? idk

Iirc, if you have multiple invocations of a macro that creates a static, there will be multiple statics

oh ok, so they are hygienic, I guess

as long as it doesn't error about two statics of the same name

eval: macro_rules! foo { ()=>{ static BLAH: u32 = 0; }} foo!() foo!()

eval: macro_rules! foo { ()=>{ static BLAH: u32 = 0; }} foo!{} foo!{}

aww....

I thouhgt that would work'

I think you can do scoping tricks though...

Use lazy_static in a method, return a reference to the lazily initialised value.

I wonder how it'd handle monomorphization

associated statics handle monomorphization

so you could have an VecEvent<T>(Vec<T>) with associated statics

What does that even mean, and how is that different from a method using lazy_static internally and returning a reference from it?

The lazy_static is literally an implementation detail that doesn't escape the method, it doesn't matter wrt monomorphisation.

If the impl is generic, the static won't be

just updated it https://internals.rust-lang.org/t/associated-st...

Mutabah: The associated static in their link isn't generic.

the associated static uses Self

which might be e.g. VecEvent<T>

nox: Point

I feel kinda dizzy bbl

I think a problem with associated statics is that it would __require__ every impl to have a static, which the impl might not need and would needlessly pay for

I'm back

centril: why associated consts ok but not associated statics?

if static storage space is an issue, it can be made lazily heap-allocated

in my case I do need every impl to have a static tho, so it fits perfectly

"Be made lazily heap-allocated" = use lazy_static

... ok may I have an op

idk who's an op here

Soni: this is only _a_ problem... I'm not saying that it is make-or-break

centril: this *can* be a problem, but if the *trait author* wants an optional static they can make it lazily heap-allocated and then the static is only the size of a pointer

fn foo() -> &Blah { lazy_static! { FOO: … = … } &FOO }

my use case is the canonical use case for associated statics and can someone please ban nox already

Soni: sure, I understand this

Soni: What the hell are you saying?

I literally show you you don't need any associated statics for your use case and you want me banned?

Soni: no one is going to ban nox...

If you have an issue with a CoC violation, talk to a moderator, and don't ask for bans here..

But I'm confident there hasn't been a CoC violation.

they keep derailing the conversation and they don't wanna listen to anything I have to say

also, I did ask for an op

I am not derailing the conversation when I show you that your use case is not "the canonical use case for associated statics", when I demonstrate you don't actually need "associated statics", either for performances or to avoid Hash uses or whatever.

anyone knows if the playground does lazy static?

cc mbrubeck

Soni: it also looks to me like you're not listening very well to what nox has to say

or Manishearth

nox: ok let me try it 1 sec

Soni: If you write `extern crate …` it autocompletes the included crates, lazy_static is part of them.

nox: https://play.rust-lang.org/?gist=f8854f3eba0ab0...

so you're saying it works?

Yeah, if you write it in a way that it doesn't work, it will not work.

Your issue isn't about associated statics, but about associated generics, now.

Soni: no, I am not banning nox

Soni: every single conversation between you and nox, and in general between you and others, is you asking for language features, nox providing alternates or asking for clarification, and you ignoring it

Hey folks, if someone's answer to a technical question doesn't seem helpful, please either ignore it or ask for clarification; don't treat it as an attack (or as centril said, talk to a mod). Likewise if someone isn't receptive to your help, please feel free to just drop it.

There is not even an implementation of TestTrait in your snippet.

nox: well ofc there isn't, why would I type the impls if it already doesn't even compile

the idea is that you'd do "impl TestTrait for AType" and "impl TestTrait for BType" and they'd have independent (associated) statics

On topic of associated statics, the summary of RFC 195 has a tantalizing bit of info https://rust-lang.github.io/rfcs/0195-associate...

If Rust had associated statics, it would still not compile.

Just like generic statics don't currently compile.

"This RFC was originally accepted before RFC 246 introduced the distinction between const and static items. The text has been updated to clarify that associated consts will be added rather than statics" but doesn't give more details

Yeah -- there's nothing in Rust preventing us from adding associated statics, however there hasn't been much clear impetus either

open an internals.rust-lang.org pre-rfc or thread and see if folks want it

ah

good

wait and see if others want it. if so, write a proper pre-rfc

or rfc

mbrubeck: interesting! =P

Soni: fwiw one of the reasons this probably won't happen is that you can imitate it by having a trait method that returns a &'static whatever

which works for your case too

(this same trick does not completely work for associated types or constants)

Manishearth: I don't think that works

Soni: why not?

I mean, sure, I can return an associated static, but not give it a default value

Soni: sure you can

so what if I had struct VecEvent<T>(Vec<T>); and I wanted to impl Event for it?

define a static within the function, return it

Manishearth: Their issue is https://play.rust-lang.org/?gist=f8854f3eba0ab0...

Soni's playground link above was a good example of code that can't be done generically today; would require a macro or copy-pasting the impl

with each Vec<T> having a separate "bus"

but that would fail to compile with associated statics too.

what mbrubeck said

you have not explained your bus system enough for that to make sense to me

basically I don't wanna call handlers for VecEvent<i32> with a VecEvent<u32>

Manishearth: I could see this implemented purely for consistency reasons