Such lints already fire in the absence of let when dealing with function/closure parameters:

#[expect(clippy::shadow_unrelated, reason = "example")]
fn foo() -> u32 {
    let x = 3u32;
    x + Some(0u32)
        .map(|mut x| {
            x += 1;
            x
        })
        .unwrap_or_default()
}

let foo = "foo";

...

mut foo = "bar";

bjorn3:

Because it would require needlessly duplicating functions for every instantiation

No, it wouldn't. Under refined proposal (dropping same origin dispatch), the solver makes the specialization decision before lifetime erasure and bakes it into MIR as a direct function call. Codegen never looks at lifetimes to decide anything.

No function body is ever duplicated based on lifetimes. If a generic function has T: 'static in its where clause, the solver picks the specialized impl for every call into that function, because every T entering it is 'static by construction. One copy per concrete type, same as today. If the function doesn't have the bound, the solver falls back to the default. Also one copy. There's no case where the monomorphizer produces two copies differing only in lifetime. @robofinch raised valid point though that this would "expose" internal workings of the borrow checker to the actual code execution.

It is compatible: inside takes_callback(f: for<'a> fn(&'a u8)), the solver sees for<'a>, which means "must work for all lifetimes." There's no 'static bound, no concrete lifetime visible. The solver falls back to the default impl which is one function body. The HRTB case is just another instance of "generic context where the solver doesn't have the information, so it uses the default." The single function pointer is never asked to behave differently for different lifetimes.

Just to reiterate:

Or did I miss something?

jrose:

fclonefileat operates on a directory descriptor + basename for the destination

Thanks for the clarification, I didn't read the code closely enough to notice that.

Serhii:

But is this really the case? Specializing on 'static seems like a perfectly valid use case. 'static is not an origin computed by the borrow checker, it's a property of the data itself. No borrow checker upgrade will change whether a string literal or an owned type is 'static. T: 'static is already a bound the solver understands.

Because it would require needlessly duplicating functions for every instantiation. And it is incompatible with HRTB (for<'a> fn(&'a ()) might need different codegen for when it is passed an &'static () or a &'notstatic (), but it represents only a single function pointer that needs to be valid for both lifetime instantiations)

Should the FCP start before the changes are made? That doesn't seem right to me. I could be wrong though

EDIT: …and copyfile now has a COPYFILE_CLONE flag, so maybe fclonefileat is a distraction anyway.

Occasionally, the problem is also that we FCPed an RFC while saying it needs a couple of changes, and the changes haven't been made yet.

RalfJung:

one also has to fix up the filename and potentially the "rendered" link and maybe more

This, at least, should be better now as the bot will IIRC do the rename when the PR is initially opened now.

nvijayap:

I am talking about the future - an enhancement to make the code elegant.

The core problem is that you're also, perhaps unknowingly, asking for

• a giant argument about when it's better to use which form
• a giant argument about whether everyone should have to move to the new form
• a giant argument about how rustfmt should decide which to use
• a bunch of confusion when people see older resources that weren't updated
• a ton of churn on everyone with existing code to move to the new thing

It's just not worth it.

The rust philosophy for this is that it's fine to ask people to just accept the structured suggestion. I, for example, continually make the mistake of struct Foo { x: u32; y: u32 } -- a semicolon instead of a comma -- but the answer isn't "Rust should accept that"; it's "oops, I accepted the structured suggestion and it's fine now".

Frequently Requested Changes

This page documents some of those ideas, along with the concerns that argue against them.

If something appears on this page, that doesn’t mean Rust would never consider making any similar change. It does mean that any hypothetical successful proposal to do so would need to address at a minimum all of these known concerns, whether by proposing a new and previously unseen approach that avoids all the concerns, or by making an extraordinary case for why their proposal outweighs those concerns.

Hopeful proposers of any of these ideas should document their extensive research into the many past discussions on these topics and ensure they have something new to offer.

[…]

Fundamental changes to Rust syntax

This includes proposals such as changing the generic syntax to not use </>, changing block constructs to not require braces, changing function calls to not require parentheses, and many other similar proposals. These also include proposals to add “alternative” syntaxes, in addition to those that replace the existing syntax. Many of these proposals come from people who also write other languages. Arguments range from the ergonomic (“I don’t want to type this”) to the aesthetic (“I don’t like how this looks”).

Changes that would break existing Rust code are non-starters. Even in an edition, changes this fundamental remain extremely unlikely. The established Rust community with knowledge of existing Rust syntax has a great deal of value, and to be considered, a syntax change proposal would have to be not just better, but so wildly better as to overcome the massive downside of switching.

In addition, such changes often go against one or more other aspects of Rust’s design philosophy. For instance, we don’t want to make changes that make code easier to write but harder to read, or changes that make code more error-prone to modify and maintain.

That said, we are open to proposals that involve new syntax, especially for new features, or to improve an existing fundamental feature. The bar for new syntax (e.g. new operators) is high, but not insurmountable. But the bar for changes to existing syntax is even higher.

I am talking about the future - an enhancement to make the code elegant.

Let me drill-down a bit ...

During the Lexing & Parsing step of the compiler, can the term set (which can be introduced in the future) get replaced by let mut?

FUTURE ==> Code will then be elegant with let and set <== FUTURE

FUTURE ==> Coders can then use these interchangeably - let mut and set <== FUTURE

Thanks,

Naga Vijayapuram

Instead the sequence “let mut” appears in let statement containing mut x-style identifier pattern. The mut is part of the pattern.

let mut x = 123;

is technically composed of let, followed by mut x, not let mut followed by x.

Like, you could think of it as bracketing; let (mut x) not (let mut) x. [Note that let (mut x) = 123; is even valid Rust syntax.]

Hence, it’s also the case that

// error
let mut _ = 123;

is illegal syntax, and

let (mut x, mut y) = (1, 2);

is not written like this:

// error
let mut (x, y) = (1, 2);

I suggest/recommend support for just the mut keyword for mutable variables alongside existing let mut

If we cannot accommodate mut, can we think of a new 3-character keyword that rhymes with let - from soundex or other criteria?

Some suggestions ...

tel - the reverse of let

cut

set - highly recommended for clarity - (clean, clear, crisp) !

Naga Vijayapuram

(I didn't include the mitigation enforcement RFC because it is comparatively recent.)

The main problem I have with this is the finality of FCPs (final comment periods) not being entirely representative. After a final comment period, where the community has the time to raise objections, the RFC should be merged as a decision has already been made and all concerns arealready answered. So after the final comment period, IMO RFCs should be merged as soon as possible (immediately?) but they aren't always.

Edit:oops, hand-typed the link. Thanks @dlight!

Assuming so, first, let me explain in somewhat more detail where I'm coming from. What I care about is getting to a place where no project ever needs to ship a .cargo/config.toml in their source tree, as expeditiously as possible. Right now, sometimes people have to do that; for example, I know of software that has to be built with -C target-feature=+crt-static -C relocation-model=static or it won't link. The only way to accomplish that, as of the last time the project I'm thinking of was updated,^[1] was to set rustflags in .cargo/config.toml.

But it's bad that people have to do that, and I hope you agree with that at least in principle. Many developers don't even know you can put a .cargo/config.toml in a workspace or package, and so it's a potential source of confusion for people new to a project. It might even be a place where someone could hide underhanded tricks, in the style of the xz exploit. Both these issues are made worse by .cargo/config.toml being a hidden file.

Furthermore, it seems to me that any setting that would be problematic in a Cargo.toml is equally problematic in a workspace or package .cargo/config.toml, only, because it's much less visible in .cargo/config.toml, the problems are exacerbated. That's why I can't get behind your plan to sort out the problems and then only move the settings that aren't problematic. I think a world in which all those problematic settings can appear in Cargo.toml, but Cargo throws deprecation warnings on the mere existence of package- or workspace-scope .cargo/config.toml, is strictly better than the world we have now. I also think that doing the file-level deprecation first and then going back to the problematic settings case by case is a better overall strategy for getting the whole job done in a reasonable amount of time.

1. it's been on ice for a bit more than a year, so the situation may well have changed ↩︎

chrisd:

On Windows ... there's no single function to copy using file handles ... there are some low-level functions which can help, such as NtCopyFileChunk, but [it doesn't do the whole job and] doesn't work in all cases ...

Linux's copy_file_range also doesn't do the whole job and doesn't work in all cases; callers need to check for a "can't do it this time" error return and fall back to a manual copy loop. It sounds like the Windows implementation of io::copy might usefully be taught to use NtCopyFileChunk if it doesn't already, but fs::copy on Windows should keep using CopyFile, would you agree?

On Linux (including Android), this function uses copy_file_range(2) , sendfile(2) or splice(2) syscalls to move data directly between file descriptors if possible.

NtCopyFileChunk is used internally by CopyFile for most forms of copy. Current exceptions include cloud copies, SMB offload and ODX.

zackw:

What would be so bad about moving everything, and I really do mean everything, from .cargo/config.toml to Cargo.toml, right now, so that we can deprecate the existence of .cargo/config.toml in packages and workspaces as soon as possible?

I'd recommend actually looking at the config before making such broad statements

• alias: there is no manifest lookup for these today
• build: half of these are caller, machine, or user specific
• credential-alias: user specific
• doc: user or machine specific
• env: unenumerable use case
• future-incompat-report: user specific
• cache: user or machine specific
• cargo-new: user as the point is that you aren't in a repo
• http: user or machine specific
• install: caller, user, or machine specific
• net: ditto
• patch: already in manifest
• profile: ditto
• resolver: controlled by workspace.resolver. Maybe more can go in but design work is needed
• registries: unsure
• source: ditto
• target links: overriding build scripts should likely not be in a static file
• term: caller, user, or machine specific

Another problem is RUSTFLAGS is a raw escape hatch that users can shoot themselves in the foot with and so it needs a "here be dragons" rather than having a paved path in the manifest,

epage:

We will likely never directly support .cargo/config.toml fields in Cargo.toml. Instead, we will need to look at how they should be abstracted in Cargo.toml.

This plan means package/workspace .cargo/config.toml will continue to need to exist indefinitely. I don't like that.

What would be so bad about moving everything, and I really do mean everything, from .cargo/config.toml to Cargo.toml, right now, so that we can deprecate the existence of .cargo/config.toml in packages and workspaces as soon as possible?

You could still migrate these settings to a better schema within Cargo.toml, later, probably on a setting-by-setting basis. It seems to me it would go more smoothly overall.

On Windows, the CopyFile family of functions really does operate on pathnames, not file handles. I wasn't able to find an equivalent that operates on file handles in a couple minutes skimming MSDN, but that doesn't mean there isn't one. However, CopyFile doesn't appear to allow you to control the ACL of the destination file, either, so the feature you want may not be possible to implement for Windows. (People who know more about low-level Windows programming than I do, please correct me if I'm wrong about anything in this paragraph.)

Therefore, I think the Right Thing would be to push the MacOS-specific fs::copy down into io::copy, make a documented guarantee that io::copy will use copy_file_range or equivalent primitive whenever possible, and also document in fs::copy that if you want to control the ownership, permissions, or other metadata of the destination file, create it yourself and use io::copy.

Specializing on some compiler-implemented HasNoLifetimeParameters trait could be reasonable, though. I believe that

struct Foo(&'static str);

could implement HasNoLifetimeParameters, while &'static str would not, in order to avoid relying on context to determine whether a given string is “really genuinely guaranteed to always be 'static”, “always 'static in the current rustc version, but not explicitly annotated as 'static so this might surprise the user”, or “only sometimes 'static”.

jrose:

fs::copy can do filesystem cloning or kernel-space-only copying that io::copy can't,

This is the issue we came across while trying to implement the cp utility.

Do you think that the permissions need solving?

robofinch:

we further don't want to allow specialization on lifetimes at all.

But is this really the case? Specializing on 'static seems like a perfectly valid use case. 'static is not an origin computed by the borrow checker, it's a property of the data itself. No borrow checker upgrade will change whether a string literal or an owned type is 'static. T: 'static is already a bound the solver understands.

The lack of an option to set a mode during copying has resulted in inelegant hacks like this (by yours truly) in software that needs to set file permissions before copying data over (to avoid permission races).

What do people think about this? I don't think it would be a very significant change, but I do think it could have quite positive effects on security.

jhpratt:

but now you no longer have the start value to store.

Step has Clone as a supertrait.

Maybe you can pr with some warn by default lint about Copy ZSTs and we'll see how many decide to switch it to allow?

scottmcm:

How about just a function? Range::from_start_and_len(start, length) would be fine, no new type.

I'll ask again: what is the type signature of from_start_and_len? Are both T? If so, what of the signed types and negative length? Perhaps T and Into<T::Unsigned> to at least remove the negative-ness concern? Should there be a try_ variant that catches that and overflow? If it is "just" Add-gated, what about floating point types? What is f32::Unsigned if that path is chosen? Or perhaps this only makes sense for usize at all?

Also, consider the following:

let n: u8 = 0;
let n_ref = &n;
{
    let other: u8 = 1;
    let another_ref = n_ref;
    // Fairly sure that `if false { .. }` would have the same effect.
    if random_u32().is_multiple_of(2) {
        another_ref = &other;
        // Conditional early return of a borrow.
        return another_ref;
    }

    // Under the current borrow checker, I'm fairly sure the origins are:
    // {shared(n)} and {shared(n), shared(other)}, not the same.
    // Under Polonius, I'm fairly sure the origins are:
    // {shared(n)} and {shared(n)}, the same.
    let result = (n_ref, another_ref).merge();
}

In other words, your proposal would make the exact behavior of the borrow checker load-bearing, and improving the borrow checker would be a breaking change.

In general one could imagine simpler case when codegen doesn't have knowledge of origins:

1. Solver sees (&s, &s).merge() at a concrete call site
2. Solver determines the origins are the same
3. Solver picks the specialized impl
4. Solver writes into MIR: "call this specific function" (the specialized one)
5. Lifetimes get erased
6. Codegen sees a direct function call and compiles it

Each call site gets its own resolution. So (&s, &s).merge() and (&a, &b).merge() become two different resolved function calls in MIR. By the time codegen runs, the decision is already made.

For specialization that depends on lifetime properties ('static, same-origin, outlives), anything that goes through a generic function can only be resolved if the relevant bounds are explicitly declared in the function signature. Without explicit bounds, the solver falls back to the default impl. For method-only specialization (where the return type doesn't change), monomorphization can pick the specialized code path for type-based properties like T: Copy, and for T: 'static on owned types where 'static is determinable from the type structure alone (e.g. u32, String). But for reference types like &str, the monomorphizer can't tell if it was &'static str or &'a str after lifetime erasure, so it falls back to the default.

If origin/lifetime information were preserved into codegen, it would unlock additional optimizations beyond what the solver can prove statically. Method-only specialization could be resolved at monomorphization time for cases like same-origin dispatch through generic functions, or 'static dispatch for reference types. But even without that, the proposal still stands. We'd just miss those optimizations, falling back to the default (slower) code path. The soundness story doesn't depend on codegen having origin information, only the optimization story does.

So in a way, we get proper full specialization for "concrete" types, but when lifetime shenanigans are involved, it becomes specialization only at the call-site level, or through explicitly declared bounds.

Serhii:

The trait solver and codegen see the same information. There's no "abstract during checking, concrete during codegen" split for origins.

I see no mention of this in Niko's blogpost and non reason why it would be the case.

appleGun22:

Doesn't have a possibility to express an invalid (start > end) range

It still does, just via things like 200_u8 ..+ 100.

Unfortunately it works very poorly with general ranges in other places. "a".."b" works fine, and is even used in things like BTreeMap methods.

But if you had something like "a" ..+ 10, what does that mean? It clearly can't implement RangeBounds in std::ops - Rust, for example.

I think if you want the "counted" part, separating it out is useful. my_btree.range(start..).take(count), for example, works well.

How about just a function? Range::from_start_and_len(start, length) would be fine, no new type.