# Ambitious Wild Ideas and Vibe Checks

Josh Triplett

Let's do more than path-dependent hill-climbing and annealing.
Let's get out of local maxima.

3-4 minutes, to give plenty of time for everyone's ideas, we can circle back around.

What if we made the standard library a regular crate? Instead of no_std, you can add alloc as regular features.
Jacob Pratt spoke on that last year. Hard but possible, long-term.

Came from Go to Rust. Surprised that you can't just cross-compile with one command. Linker, compiler, etc. zig build

Would like to see clippy decomposed into smaller projects to make it easier to develop your own lints. Have a core that makes lint development easy.
Have rust-analyzer-specific lints that you don't want to see in the command line.
Have native lint-development framework in rustc (e.g. AST matching).
Many organizations may want to have internal lints!

Don't have to write mod.rs, Rust will infer it for you.

What if Rust supported erased types? Traits can be object-safe or not. What if every trait could be used in an object context? AFIT, what do you do with the future that comes back?
(Yes, please! Lang is looking at doing this!)

Bit fields and bit packing! Not like C where it's UB, but where it's safe. Build it into the language, so you don't have to use macros. Enum discriminants and where those are.
Do you care about matching an existing layout or just packing things? Match an existing layout.
"Move-only fields" would help with packing things in.

Linear types! Aggressively encode type safety into the type system.

Get the LLVM IR from rustc, want to move things to a GPU and autodifferentiate it or run Polyhedral optimization, or otherwise transform LLVM IR and hand it back to the compiler, without being part of the compiler.
Working on a project goal for GPUs and autodiff.
Want to not worry about supporting other backends.
E.g. Julia uses this. Java also has a prototype for Reflection with these examples.

semver checks. Could we make it mandatory? Could we make it better integrated? Make it automatic on publish?
Want to let people override it, but want it to be deliberate.

Auditing unsafe code is basically unscalable. Would like to require safety comments by default.
Could we add it to an opt-in thing for crates?
Idioms.

Add structure to safety invariants.
Pre/post conditions, or just more structured prose.
- Sometimes unsafe code is dependent on a const's value and people want to cross-link that, see https://github.com/toml-rs/toml/pull/720

We discourage people to use unsafe for things that aren't memory safety. But some project have their own constraints they want to enforce, e.g. bug-prone functions. Could we extend the concept of unsafety to annotate other kinds of functions?
Similar mechanisms for no panics in this chain.

Incremental linking!
Could we build wild into rustc?

Record types! I process JSON, I'd like to have this for ad-hoc formats. Rho polymorphism; ocaml has it.
Also see Esteban's recent proposals.

cargo-publish is a low-level tool, there are cargo release and release-plz and other tools. Could we stop recommending publish to new users and recommend tools that enforce best practices? Would help catch latent mistakes. e.g. the code that was published doesn't match any tag, has files that weren't meant to be there, we don't validate that the repo matches at all...
- See https://doc.rust-lang.org/cargo/reference/publishing.html#publishing-a-new-version-of-an-existing-crate

Make const the default!
"ooooooooh!" from the room
"const" isn't an effect/transformer/etc, "runtime"/"IO" is the effect/transformer.
What's the *most* consty thing to be the default?
koka's "total" is more pure than Haskell's pure.

macro_rules are terrible, replace them with comptime from zig.
Is comptime equivalent to proc macros?
Modulo layering complications
Multi-stage compiler.

proc macro just takes a token stream, because we didn't want to stabilize more than that
Could we stabilize more than that?
Struct names and fields, for instance?
Expose more things that aren't just surface syntax.

More power to macro rules! Do more without proc macros!
Derive with macro rules!
attribute position macro rules!
Security and sandboxing!

Also, sandboxed proc macros.

People use `build.rs` for three reasonable things, and a lot of unreasonable things.
Give people a non-`build.rs` for those three-ish things, so `build.rs` stands out more.
- snapshot testing for code-gen
- system-deps for `-sys` crates
- `cfg(accessible)` for build probes (except nightly which is rejected by the Cargo team)

Append-only attribute macros, or some way of marking attribute macros as append-only?
Know that the code that's there will stay there.
There's a known soundness hole in zerocopy that would be easier to avoid if we had this.

Compiler warnings from proc macros.

RPIT to be able to call trait methods on a value of that input trait, without the trait in scope.
Demo: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=0c7957e414c8ac6f853b7fc7a7bd5a1b
You can currently return an impl trait and can later return a concrete type; this would break.
Inherent traits?
Could we add `-> ConcreteType + impl InherentTrait`, to *add* an inherent trait even if it isn't inherent to ConcreteType?

`cargo new` should be more opinionated
README, CI configuration, etc
Everything but the code!
- https://github.com/rust-lang/cargo/issues/5151
- https://github.com/rust-lang/cargo/issues/5656

Actually use SPDX identifiers
Pull in a popular license?
`--license SPDX-ID` and automatically apply the license correctly.
Put big scary warnings on non-OSI licenses on crates.io

publish = false should be the default!
- https://github.com/rust-lang/cargo/issues/6153

We're very heavy on "we check everything at declaration time". Good in some ways, obnoxious in others. Might want to write a debug macro 20 calls deep, and not put `: Debug` on everything.
In const fn you can get use-time errors.
We already have these, could we get away with more.
maybe it'd be fine to have

fn add<T: Add>(x: T, y: T, z: T) -> T {
    x + y + z
}

instead of needind to talk about the generic and associated types too.
(Especially with cargo semver-checks that could check stuff anyway!)
Could we have `if T impls Trait`

Enforce more kinds of compile-time requirements? "keep this sorted".

Dereference something that's not a pointer, as something that's not a reference.
Deref without a `&`.
ndarray.
Indexing?
Receiver types RFC? Can't deref with that though. Arbitrary self types?
Does Erlang have something to learn from here?

Result autowrapping.
Throw syntax for functions that return a Result.
Don't have to wrap all of my return paths in Ok.

Anonymous enums

Anonymous sum types
Note: some things can't be delegated. Opt-in per trait.

& in Rust means a reference, `||` means a closure, get rid of `&&` and `||` and use `and` and `or`

re bitfields and discriminants
Was writing a GB emulator, had a giant enum for Z80 instructions, would love to make its layout match the actual hardware instructions
Logical representation vs physical representation

Stable has fewer bugs than nightly but doesn't allow unstable features
Connecting those is weird
Would like to be able to use unstable features on stable, but still have fewer bugs.
AOSP does this.

If I add feature gates to a module, I end up playing whackamole with rustc lints
Lint the code that's inside the feature gate
Specifically, see through for unused (dead code).

`cargo add`, automatically add it to workspace dependencies, and as a workspace dependency to the current crate.
- https://github.com/rust-lang/cargo/issues/10608

`cargo new --workspace`
- https://github.com/rust-lang/cargo/issues/8365

Serialize iterators in a way that I can recover them later. Run cargo-semver-checks, it completes some things and not others, the others are iterators in progress, dump and reload them.

Specify for each crate the default target configuration
Default cross target *per-package*
- https://github.com/rust-lang/cargo/issues/6179
- https://github.com/rust-lang/cargo/issues/9208

Please raise things on internals.rust-lang.org, or Zulip, or social media...