Aah, sorry. The code snippet at the top reflects everything that needs to live in libcore. Actual
BikeshedIntrinsicFrom will be generated on-the-fly by the compiler.
Everything outside of that snippet doesn't need to be in libcore or the compiler.
The associated GitHub issue has been renamed. Renaming this Zulip topic.
triagebot seems confused, it made a new stream instead of renaming lol
cc @Camelid , I think you implemented it
ok I see the relevant bits start at "Solution"
Ah the issue is that it renamed the topic for every message after the rename, not all the messages.
I'll open an issue later.
@Jack Wrenn just curious what the latest is on the status of this.
@rylev I think it needs review by the compiler team?
I can try to help there.
From reading the MCP, I have the impression that this is an unstable, experimental implementation to allow us to try out this concept before committing to it in the RFC. Is that correct?
@Wesley Wiser that is correct. The reason it was brought up as an MCP is the implementation is unlikely to be trivial and we wanted to make sure the compiler team was onboard before we start introducing some relatively complex machinery. But indeed, this will not be exposed to end users in any kind of stable way. That, of course, will go through the RFC process.
A thought for the internal version: maybe skip the
Assume, and just have a parameter for each of the things? (Just as a way to reduce the scope of the conversation.)
The struct is important for the stabilized thing, so it can be
non_exhaustive and have a nicer API, but for the internal thing it would be fine for it to add, remove, or rename parameters as it goes.
@T-compiler: Proposal #411 has been seconded, and will be approved in 10 days if no objections are raised.
This proposal has been accepted: #411.