Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking: Rust All-Hands 2020 #82

Open
7 tasks
Wodann opened this issue Jan 17, 2020 · 8 comments
Open
7 tasks

Tracking: Rust All-Hands 2020 #82

Wodann opened this issue Jan 17, 2020 · 8 comments

Comments

@Wodann
Copy link
Contributor

Wodann commented Jan 17, 2020

Leading up to the Rust All-Hands 2020, I'd like to compile a document of proposals that we as the gamedev wg would like to raise - whether we are able to attend in person or not.

This issue is intended to outline what topics are currently under discussion, links to relevant information, and who are working on the topics.

@TimDiekmann
Copy link

What do you mean by coexisting both Box types from std and (probably) alloc_wg (you wrote alloc)? A few days ago we had a small discussion at zulip about implementing From traits for the alloc_wg types for convenient and typesafe conversation.

@Wodann
Copy link
Contributor Author

Wodann commented Jan 17, 2020

If I understood correctly, the reason that we cannot easily try the alloc-wg's traits in nightly, is because a generic parameter such as A: Alloc cannot only be added on nightly. It will also have to be added on stable.

@Lokathor proposed making a clone of the standard library in which we use the alloc traits where possible (e.g. Box, Vec). On nightly you'd then be able to also use the "cloned" standard library (e.g. using a syntax like temp_alloc::Box::new(...). In that sense the non-alloc and alloc versions of the std would coexist.

edit: changed syntax in the original comment to temp_alloc to avoid confusion with rust's alloc library.

@TimDiekmann
Copy link

There is an open PR rust-lang/rust#65083 which allows unstable annotations to generics. This is basically the one thing blocking the alloc WG to push upstream.

@Lokathor
Copy link
Member

Yeah, that's been open for 4 months though :P

@Lokathor
Copy link
Member

note though that std::Box is an alias for alloc::boxed::Box

we'd need to make alloc2 or some other temporary crate

@aclysma
Copy link
Contributor

aclysma commented Jan 19, 2020

+1 that sounds like a great idea! I'd also like to see these discussed:

However custom allocator support is more important in my opinion, and we don't really have a specific proposal for these three, although we could work towards that in the next month or two. (Fast floats I think we'd get quite far with a global switch that allows specifying using fast float by default instead of safe floats. It's not a perfect solution, but it is a proven solution since C++ does it that way.)

We could also seek opinions from industry professionals who don't usually engage in this wg to make sure they have a voice.

Maybe a good thing to bring up at our next Wednesday meeting.

@aclysma aclysma mentioned this issue Jan 19, 2020
3 tasks
@Wodann
Copy link
Contributor Author

Wodann commented Jan 19, 2020

Those are good topics to discuss next Wednesday. I've added them to the list.

It's a good idea to ask for their opinions too. I'll reach out to the industry devs that I connected with previously.

@Wodann
Copy link
Contributor Author

Wodann commented Jan 30, 2020

The Rust All-Hands was cancelled, but I'd still like to push forward in this direction. Maybe we can combine this work with the results of the Rust Gamedev Survey and create a Roadmap for 2020?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants