[WIP, Pre-RFC] statics inside <...> and fixing unsoundness bugs

[Soni]

You already have two proposals (1 , 2 ) which involve function calls expanding to an expression and the implicit creation of a static (or more).

Neither of which a) are a pre-RFC b) talk about fixing Any/TypeId.

[johnthagen]

Alternatives

• Drop Windows support

You aren’t proposing this as a serious alternative, are you?

[Soni]

it’s a serious alternative. the question is whether it’s an acceptable alternative.

we do have WSL now, which gives you an native linux-compatible runtime on windows 10. this is a huge improvement over the emulated linux from cygwin and friends.

[steveklabnik]

That’s not a serious alternative.

[Soni]

can we please keep criticism about the rfc and not about whether that’s a serious alternative or not? because I’d be willing to drop winapi on windows, personally, so it’s serious to me.

[drXor]

Allow me to apologize for the harsh tone, but I think it’s merited in this case. Allow me to further point out that I really don’t like Windows’ idiosyncrasies either.

Dropping support for a major operating system, especially one with the majority market share on desktop clients, is comparable to suggesting removing the borrowck because it still has open unsoundness bugs. This is how you drive your language into irrelevance.

It is definitionally unreasonable, and very much a criticism of the RFC, because alternatives are a crucial part of an RFC. It is hard to take an RFC with unironicly ludicrous components seriously.

[Soni]

Rust works just fine on WSL and nothing stops us from bootstrapping WSL from a Windows C program.

[IsaacWoods]

Rust supports Windows versions from Vista upwards (I think there was an idea to drop XP support, but atm it’s a Tier 3 platform afaik). WSL does not support the majority of those supported platforms and as such is not a viable solution. To keep your pre-RFC on track, it would probably make sense to remove that alternative and move forward.

[wesleywiser]

WSL is not Windows support. As Microsoft puts it:

Note that, just as on Windows 10, WSL is for running your favorite Linux distros & tools for local interactive use, not for hosting production Linux workloads .

- https://blogs.msdn.microsoft.com/commandline/2017/08/08/wsl-arrives-on-windows-server/

Rust already has many organizations shipping applications written or partially written in Rust on Windows. It would be unacceptable to our users to remove Windows support.

[matt1985]

How does this interact with function pointers,eg if you tried to do this:

fn foo<static BAR: usize = 0>() -> usize {
    BAR
}
fn bar<static BAZ: AtomicUsize = ATOMIC_USIZE_INIT>() -> usize {
    BAZ.fetch_add(1, SeqCst)
}

fn baz(func:fn()->usize){
    func()
}

baz(foo);
baz(bar);

Do this, but hide the implementation details so I’m still forced to use macros in eventbus crate.

You are saying this like using macros is a bad thing.

This is obviously no better than macros.

[Soni]

This is a lot better than macros:

• Generic type inference actually works.
• Cleanly propagates to generic callers.
• Backwards compatible.
• Can you even make function pointers to generic functions? I never tried tbh.

[retep998]

Can you even make function pointers to generic functions? I never tried tbh.

Yes, you can have function pointers to monomorphizations of a generic function.

[Soni]

how does that work?

yes, you can have pointers to monomorphizations of these.

[matt1985]

• Generic type inference actually works.
• Backwards compatible.

How do these not apply to macros?(It’s not obvious what you are talking about here.)

• Cleanly propagates to generic callers.

I would not call propagating statics to the caller clean. At least with macros you can tell something weird might be happening.

Also,as one of the alternatives you should mention passing down a &'static Foo instead of a generic static,and say why that does not work.

[Soni]

let x: &Foo = any.downcast_ref();
let x: &Foo = downcast_ref!(any); // doesn't work, no way to get/use &Foo from inside the macro

[matt1985]

Your specific macro is wrong.

[Soni]

how? it clearly shows the lack of type inference…

[matt1985]

In you macro specifically,not Rust in general.See vec in the standard library.

[Soni]

okay, do you think you can convert the two macros of eventbus to remove the need of explicitly passing in the type?

[matt1985]

Maybe,I haven’t seen them yet.And even I looked at them,I would have to know what you want them to be like(beyond not passing the type).