Inferred types _::Enum

[JoshBashed]

This RFC is all about allowing types to be inferred without any compromises. The syntax is as follows. For additional information, please read the bellow.

struct MyStruct {
    value: usize
}

fn my_func(data: MyStruct) { /* ... */ }

my_func(_ {
    value: 0
});

I think this is a much better and more concise syntax.

If you plan on pressing the dislike button, please leave a comment explaining your disproval. Every piece of constructive feedback helps.

Rendered

[Lokathor]

I'm not necessarily against the RFC, but the motivation and the RFC's change seem completely separate.

I don't understand how "people have to import too many things to make serious projects" leads to "and now _::new() can have a type inferred by the enclosing expression".

[JoshBashed]

I don't understand how "people have to import too many things to make serious projects" leads to "and now _::new() can have a type inferred by the enclosing expression".

In crates like windows-rs even in the examples, they import *. This doesn't seem like good practice and with this feature, I hope to avoid it.

use windows::{
    core::*, Data::Xml::Dom::*, Win32::Foundation::*, Win32::System::Threading::*,
    Win32::UI::WindowsAndMessaging::*,
};

[Lokathor]

Even assuming I agreed that's bad practice (which, I don't), it is not clear how that motivation has lead to this proposed change.

[JoshBashed]

Even assuming I agreed that's bad practice (which, I don't), it is not clear how that motivation has lead to this proposed change.

How can I make this RFC more convincing? I am really new to this and seeing as you are a contributor I would like to ask for your help.

[Lokathor]

First, I'm not actually on any team officially, so please don't take my comments with too much weight.

That said:

• the problem is that you don't like glob imports.
• glob imports are usually done because listing every item individually is too big of a list, or is just annoying to do.
• I would expect the solution to somehow be related to the import system. Instead you've expanded how inference works.

Here's my question: Is your thinking that an expansion of inference will let people import less types, and then that would cause them to use glob imports less?

Assuming yes, well this inference change wouldn't make me glob import less. I like the glob imports. I want to write it once and just "make the compiler stop bugging me" about something that frankly always feels unimportant. I know it's obviously not actually unimportant but it feels unimportant to stop and tell the compiler silly details over and over.

Even if the user doesn't have to import as many types they still have to import all the functions, so if we're assuming that "too many imports" is the problem and that reducing the number below some unknown threshold will make people not use glob imports, I'm not sure this change reduces the number of imports below that magic threshold. Because for me the threshold can be as low as two items. If I'm adding a second item from the same module and I think I might ever want a third from the same place I'll just make it a glob.

Is the problem with glob imports that they're not explicit enough about where things come from? Because if the type of _::new() is inferred, whatever the type of the _ is it still won't show up in the imports at the top of the file. So you still don't know specifically where it comes from, and now you don't even know the type's name so you can't search it in the generated rustdoc.

I hope this isn't too harsh all at once, and I think more inference might be good, but I'm just not clear what your line of reasoning is about how the problem leads to this specific solution.

[JoshBashed]

Is your thinking that an expansion of inference will let people import less types, and then that would cause them to use glob imports less?

Part of it yes, but, I sometimes get really frustrated that I keep having to specify types and that simple things like match statements require me to sepcigy the type every single time.

whatever the type of the _ is it still won't show up in the imports at the top of the file. So you still don't know specifically where it comes from, and now you don't even know the type's name so you can't search it in the generated rustdoc.

Its imported in the background. Although we don't need the exact path, the compiler knows and it can be listed in the rust doc.

I hope this isn't too harsh all at once, and I think more inference might be good, but I'm just not clear what your line of reasoning is about how the problem leads to this specific solution.

Definitely not, you point out some great points and your constructive feedback is welcome.

[BoxyUwU]

Personally _::new() and _::Variant "look wrong" to me although i cant tell why, I would expect <_>::new() and <_>::Variant to be the syntax, no suggestion on _ { ... } for struct exprs which tbh also looks wrong but <_> { ... } isnt better and we dont even support <MyType> { field: expr }

[compiler-errors]

I think this question needs to be resolved before the RFC is landed, since it pretty drastically changes the implementation and behavior of the RFC.

[JoshBashed]

I would love to discuss it (:

[SOF3]

I would like to suggest an alternative rigorous definition that satisfies the examples mentioned in the RFC (although not very intuitive imo):

---

When one of the following expression forms (set A) is encountered as the top-level expression in the following positions (set B), the _ token in the expression form should be treated as the type expected at the position.

Set A:

• Path of the function call (e.g. _::function())
• Path expression (e.g. _::EnumVariant)
• When an expression in set A appears in a dot-call expression (expr.method())
• When an expression in set A appears in a try expression (expr?)
• When an expression in set A appears in an await expression (expr.await)

Set B:

• A pattern, or a pattern option (delimited by |) in one of such patterns
• A value in a function/method call argument list
• The value of a field in a struct literal
• The value of a value in an array/slice literal
• An operand in a range literal (i.e. if an expression is known to be of type Range<T>, expr..expr can infer that both exprs are of type T)
• The value used with return/break/yield

Set B only applies when the type of the expression at the position can be inferred without resolving the expression itself.

---

Note that this definition explicitly states that _ is the type expected at the position in set B, not the expression in set A. This means we don't try to infer from whether the result is actually feasible (e.g. if _::new() returns Result<MyStruct>, we still set _ as MyStruct and don't care whether new() actually returns MyStruct).

Set B does not involve macros. Whether this works for macros like vec![_::Expr] depends on the macro implementation and is not part of the spec (unless it is in the standard library).

Set A is a pretty arbitrary list for things that typically seem to want the expected type. We aren't really inferring anything in set A, just blind expansion based on the inference from set B. These lists will need to be constantly maintained and updated when new expression types/positions appear.

[JoshBashed]

s (set A) is encountered as the top-level expression in the following positions (set B), the _ token in the expression form should be treated as the type expected at th

That is so useful! Let me fix it now.

[SOF3]

One interesting quirk to think about (although unlikely):

fn foo<T: Default>(t: T) {}

foo(_::default())

should this be allowed? we are not dealing with type inference here, but more like "trait inference".

[JoshBashed]

One interesting quirk to think about (although unlikely):

fn foo<T: Default>(t: T) {}

foo(_::default())

should this be allowed? we are not dealing with type inference here, but more like "trait inference".

I think you would have to specify the type arg on this one because Default is a trait and the type is not specific enough.

fn foo<T: Default>(t: T) {}

foo::<StructImplementingDefault>(_::default())

[SOF3]

oh never mind, right, we don't really need to reference the trait directly either way.

[clarfonthey]

I've been putting off reading this RFC, and looking at the latest version, I can definitely feel like once the aesthetic arguments are put aside, the motivation isn't really there.

And honestly, it's a bit weird to me to realise how relatively okay I am with glob imports in Rust, considering how I often despise them in other languages like JavaScript. The main reason for this is that basically all of the tools in the Rust ecosystem directly interface with compiler internals one way or another, even if by reimplementing parts of the compiler in the case of rust-analyzer.

In the JS ecosystem, if you see a glob import, all hope is essentially lost. You can try and strip away all of the unreasonable ways of interfacing with names like eval but ultimately, unless you want to reimplement the module system yourself and do a lot of work, a person seeing a glob import knows as much as a machine reading it does. This isn't the case for Rust, and something like rust-analyzer will easily be able to tell what glob something is coming from.

So really, this is an aesthetic argument. And honestly… I don't think that importing everything by glob, or by name, is really that big a deal, especially with adequate tooling. Even renaming things.

Ultimately, I'm not super against this feature in principle. But I'm also not really sure if it's worth it. Rust's type inference is robust and I don't think it would run into technical issues, just… I don't really know if it's worth the effort.

[SOF3]

@clarfonthey glob imports easily have name collision when using multiple globs in the same module. And it is really common with names like Context. Plus, libraries providing preludes do not necessarily have the awareness that adding to the prelude breaks BC.

[JoshBashed]

And honestly, it's a bit weird to me to realise how relatively okay I am with glob imports in Rust, considering how I often despise them in other languages like JavaScript. The main reason for this is that basically all of the tools in the Rust ecosystem directly interface with compiler internals one way or another, even if by reimplementing parts of the compiler in the case of rust-analyzer.

In the JS ecosystem, if you see a glob import, all hope is essentially lost. You can try and strip away all of the unreasonable ways of interfacing with names like eval but ultimately, unless you want to reimplement the module system yourself and do a lot of work, a person seeing a glob import knows as much as a machine reading it does. This isn't the case for Rust, and something like rust-analyzer will easily be able to tell what glob something is coming from.

I can understand your point, but, when using large libraries in conjunction, like @SOF3 said, it can be easy to run into name collisions. I use actix and seaorm and they often have simular type names.

[JoshBashed]

Personally _::new() and _::Variant "look wrong" to me although i cant tell why, I would expect <_>::new() and <_>::Variant to be the syntax, no suggestion on _ { ... } for struct exprs which tbh also looks wrong but <_> { ... } isnt better and we dont even support <MyType> { field: expr }

In my opinion, it's really annoying to type those set of keys. Using the QWERTY layout requires lots of hand movement. Additionally, it's syntax similar to what you mentioned has already been used to infer lifetimes, I am concerned people will confuse these.

[clarfonthey]

Right, I should probably clarify my position--

I think that not liking globs is valid, but I also think that using globs is more viable in Rust than in other languages. Meaning, it's both easier to use globs successfully, and also easier to just import everything you need successfully. Rebinding is a bit harder, but still doable.

Since seeing how useful rust-analyzer is for lots of tasks, I've personally found that the best flows for these kinds of things involve a combination of auto-import and auto-complete. So, like mentioned, _ is probably a lot harder to type than the first letter or two of your type name plus whatever your auto-completion binding is (usually tab, but for me it's Ctrl-A).

Even if you're specifically scoping various types to modules since they conflict, that's still just the first letter of the module, autocomplete, two colons, the first letter of the type, autocomplete. Which may be more to type than _, but accomplishes the goal you need to accomplish.

My main opinion here is that _ as a type inference keyword seems… suited to a very niche set of aesthetics that I'm not sure is worth catering to. You don't want to glob-import, you don't want to have to type as much, but also auto-completing must be either too-much or not available. It's even not about brevity in some cases: for example, you mention cases where you're creating a struct inside a function which already has to be annotated with the type of the struct, which cannot be inferred, and therefore you're only really saving typing it once.

Like, I'm not convinced that this can't be better solved by improving APIs. Like, for example, you mentioned that types commonly in preludes for different crates used together often share names. I think that this is bad API design, personally, but maybe I'm just not getting it.

[programmerjake]

I do think inferred types are useful when matching for brevity's sake:
e.g. in a RV32I emulator:

#[derive(Copy, Clone, Default, Eq, PartialEq, Ord, PartialOrd, Debug, Hash)]
pub struct Reg(pub Option<NonZeroU8>);

#[derive(Debug)]
pub struct Regs {
    pub pc: u32,
    pub regs: [u32; 31],
}

impl Regs {
    pub fn reg(&self, reg: Reg) -> u32 {
        reg.0.map_or(0, |reg| self.regs[reg.get() - 1])
    }
    pub fn set_reg(&mut self, reg: Reg, value: u32) {
        if let Some(reg) = reg {
            self.regs[reg.get() - 1] = value;
        }
    }
}

#[derive(Debug)]
pub struct Memory {
    bytes: Box<[u8]>,
}

impl Memory {
    pub fn read_bytes<const N: usize>(&self, mut addr: u32) -> [u8; N] {
        let mut retval = [0u8; N];
        for v in &mut retval {
            *v = self.bytes[addr.try_into().unwrap()];
            addr = addr.wrapping_add(1);
        }
        retval
    }
    pub fn write_bytes<const N: usize>(&mut self, mut addr: u32, bytes: [u8; N]) {
        for v in bytes {
            self.bytes[addr.try_into().unwrap()] = v;
            addr = addr.wrapping_add(1);
        }
    }
}

pub fn run_one_insn(regs: &mut Regs, mem: &mut Memory) {
    let insn = Insn::decode(u32::from_le_bytes(mem.read_bytes(regs.pc))).unwrap();
    match insn {
        _::RType(_ { rd, rs1, rs2, rest: _::Add }) => {
            regs.set_reg(rd, regs.reg(rs1).wrapping_add(regs.reg(rs2)));
        }
        _::RType(_ { rd, rs1, rs2, rest: _::Sub }) => {
            regs.set_reg(rd, regs.reg(rs1).wrapping_sub(regs.reg(rs2)));
        }
        _::RType(_ { rd, rs1, rs2, rest: _::Sll }) => {
            regs.set_reg(rd, regs.reg(rs1).wrapping_shl(regs.reg(rs2)));
        }
        _::RType(_ { rd, rs1, rs2, rest: _::Slt }) => {
            regs.set_reg(rd, ((regs.reg(rs1) as i32) < regs.reg(rs2) as i32) as u32);
        }
        _::RType(_ { rd, rs1, rs2, rest: _::Sltu }) => {
            regs.set_reg(rd, (regs.reg(rs1) < regs.reg(rs2)) as u32);
        }
        // ...
        _::IType(_ { rd, rs1, imm, rest: _::Jalr }) => {
            let pc = regs.reg(rs1).wrapping_add(imm as u32) & !1;
            regs.set_reg(rd, regs.pc.wrapping_add(4));
            regs.pc = pc;
            return;
        }
        _::IType(_ { rd, rs1, imm, rest: _::Lb }) => {
            let [v] = mem.read_bytes(regs.reg(rs1).wrapping_add(imm as u32));
            regs.set_reg(rd, v as i8 as u32);
        }
        _::IType(_ { rd, rs1, imm, rest: _::Lh }) => {
            let v = mem.read_bytes(regs.reg(rs1).wrapping_add(imm as u32));
            regs.set_reg(rd, i16::from_le_bytes(v) as u32);
        }
        _::IType(_ { rd, rs1, imm, rest: _::Lw }) => {
            let v = mem.read_bytes(regs.reg(rs1).wrapping_add(imm as u32));
            regs.set_reg(rd, u32::from_le_bytes(v));
        }
        // ...
    }
    regs.pc = regs.pc.wrapping_add(4);
}

pub enum Insn {
    RType(RTypeInsn),
    IType(ITypeInsn),
    SType(STypeInsn),
    BType(BTypeInsn),
    UType(UTypeInsn),
    JType(JTypeInsn),
}

impl Insn {
    pub fn decode(v: u32) -> Option<Self> {
        // ...
    }
}

pub struct RTypeInsn {
    pub rd: Reg,
    pub rs1: Reg,
    pub rs2: Reg,
    pub rest: RTypeInsnRest,
}

pub enum RTypeInsnRest {
    Add,
    Sub,
    Sll,
    Slt,
    Sltu,
    Xor,
    Srl,
    Sra,
    Or,
    And,
}


pub struct ITypeInsn {
    pub rd: Reg,
    pub rs1: Reg,
    pub imm: i16,
    pub rest: ITypeInsnRest,
}

pub enum ITypeInsnRest {
    Jalr,
    Lb,
    Lh,
    Lw,
    Lbu,
    Lhu,
    Addi,
    Slti,
    Sltiu,
    Xori,
    Ori,
    Andi,
    Slli,
    Srli,
    Srai,
    Fence,
    FenceTso,
    Pause,
    Ecall,
    Ebreak,
}
// rest of enums ...

[Aloso]

I do like type inference for struct literals and enum variants.

However, type inference for associated functions doesn't make sense to me. Given this example:

fn expect_foo(_: Foo) {}
foo(_::bar());

• According to this RFC, the _ should be resolved to Foo (the function argument's type), but this isn't always correct. I suspect that this behavior is often useful in practice, but there are cases where it will fail, and people may find this confusing. For example, Box::pin returns a Pin<Box<T>>, so _::pin(x) couldn't possibly be inferred correctly.

• Even when Foo has a bar function that returns Foo, there could be another type that also has a matching bar function. Then _ would be inferred as Foo, even though it is actually ambiguous.

• Another commenter suggested that we could allow method calls after the inferred type (e.g. _::new().expect("..."), or _::builder().arg(42).build()?). But this still wouldn't help in a lot of cases, because methods often return a different type than Self (in contrast to associated functions, where Self is indeed the most common return type).

  For example, the _ in _::new(s).canonicalize()? can't be inferred as Path, because Path::canonicalize returns Option<PathBuf>.

• Another issue is that it doesn't support auto-deref (e.g. when a function expects a &str and we pass &_::new() ¹, which should be resolved as &String::new(), but that may be ambiguous).

All in all, it feels like this would add a lot of complexity and make the language less consistent and harder to learn.

Footnotes

1. I realize this is a contrived example ↩

[lemon-gith]

Addressing previously made points

To address @igotfr's point about the use of other keywords, the as keyword is used in rust to cast between types, which is not what we're doing with this syntax.
Instead, keywords like using or the colon (:), are both 'keywords' that relate to this syntax more directly:

• using would be a modification on use, somewhat like a temporary import
  • inspired by python's with and c++'s using
• : {type} is now my preferred keyword: it mirrors the type specification syntax that we're already familiar with in rust
  • it's also more true to my suggested syntax: the scrutinee has one type, primitive/compound/etc., we're just re-specifying what that type is

To address @daniel-pfeiffer here, I feel that putting the generic use statements at the top of the match-statement without binding typing to specific variables, continues to introduce ambiguity in more complex structures. As you correctly identified in your example, it's now the responsibility of the user to know that there are ambiguous variants between both imported enums: in my opinion, the user shouldn't have to need to know all possible variant clashes.

---

Underscore and Colon Syntaxes

To speak to the response from @idanarye: you make a very good point about the existing meaning of the _ syntax in rust and how the compiler should already be able to type the scrutinee and match arm destructurings, even without any special syntax (in theory). I don't have much else to say, it's a good point :)

Nonetheless, there are 2 reasons I still prefer the type specification syntax:

A less important reason is that it moves the extra syntax from the match arms to the match head (?); that way, the extra verbosity is concentrated in one place, and doesn't need to be repeated, i.e. bite the bullet declaring your type at the top, then don't worry about the syntax after that.

The much more important reason, is that the syntax here serves 2 purposes:

1. let the compiler know it needs to focus on the typing here (as with the _:: syntax)
2. let the reader know what types you're working with here

That is to say, by re-declaring the types you're working with, just above a complex operation involving those types, it makes it easier to understand the code without flitting back and forth; seeing _::, in my opinion, just tells the reader that it's possible to figure out the typing, if they so wish.
It could be said that it increases the spatial locality of the type annotation for readers.

Naturally, if one didn't want to write out a type (or sub-sections for a more complex type), it would make sense to allow _ in the type specification, e.g. match fred: (Foo::Fruits, _) {...}, since these notations are not mutually exclusive.

To add to that, the colon syntax is very specific to match-like constructs, whereas I can see the underscore being very useful in a lot of places, described by many comments in this RFC, back in 2023 and early 2024.

Of course, regarding the compiler, I imagine that the _:: syntax would likely be easier to implement?

---

Match Statement Debate Overview (to the best of my knowledge)

Just to give a full example:

// import this enum from somewhere
use idk::Bar;  // use idk::Bar::{operation, ..., Companies};  // may be better
// define this enum here
enum Fruits {
    Apple,
    Orange(u32),
    Durian,
    Cantaloupe
}

let fruit: Fruits = { ... };
let company = { ... };  // some operation related to imported `Bar` module

let fred = (fruit, company);

The existing syntax (without workarounds like scoped imports):

match fred {
    (Fruits::Apple, Bar::Companies::Google) => { ... }
    (Fruits::Orange(x), Bar::Companies::Samsung) if x < 7 => { ... }
    (Fruits::Orange(_), x) if !matches!(x, Bar::Companies::Samsung) => { ... }
    (Fruits::Durian, Bar::Companies::Apple) => { ... }
    _ => { ... }
}

This is the underscore syntax (I believe?) that has been suggested:

match fred {
    (_::Apple, _::Google) => { ... }
    (_::Orange(x), _::Samsung) if x < 7 => { ... }
    (_::Orange(_), x) if !matches!(x, _::Samsung) => { ... }
    (_::Durian, _::Apple) => { ... }
    _ => { ... }
}

This is the colon syntax that I'm suggesting:

match fred: (Fruits, Bar::Companies) {
    (Apple, Google) => { ... }
    (Orange(x), Samsung) if x < 7 => { ... }
    (Orange(_), x) if !matches!(x, Samsung) => { ... }
    (Durian, Apple) => { ... }
    _ => { ... }
}

To note, tuple variants under underscore syntax, like _::Orange(_), would be valid, semantically correct syntax, which doesn't break anything, but there's just something to be said about juxtaposing two different usages of the same symbol ¹.

If we get into the point that only ambiguous variants should use _::, I'd like to raise the point that Orange is also a company² and would then also require disambiguation, but you can't tell that just by looking at the code here.

I think the heart of the problem is that we're happy to have imported things beforehand, and to have properly qualified our types, but not to keep qualifying them again and again in match arms.

---

This RFC and Implementation

One benefit of all these suggestions is to reduce glob imports, which @JoshuaBrest mentions near the start of this issue. I agree with both sides, but side more with @JoshuaBrest:

• glob imports are alright when importing from well-written crates with good publishing hygiene
  • because they often include helper functions that you may not have realised you need to import
  • sometimes they can be necessary when importing from crates that extend functionality, implicitly
• glob imports are generally bad, because most users don't check everything they're importing
  • as a cybersecurity person: whitelisting is just usually better practice than blacklisting
  • a general "import what you need" philosophy often helps to reduce clashes and ambiguities

I (also?) agree with the notion that the underscore syntax is a good idea, but I do prefer the extra (and more spatially localised) information conveyed to the reader by the colon syntax, which I think is the main benefit of the non-underscore syntaxes that people are suggesting.
I am, of course, slightly biased, and more than open to other thoughts regarding potential flaws and edge cases that the colon syntax can't handle, as well as worries of increasing the implementation complexity.

P.S. sorry for the massive essay, I'm just hoping to summarise some of the key discussions here

Footnotes

1. also, !matches!() is very interesting, though I mainly find it amusing :} ↩

2. which is why I picked that as the second fruit ↩

[idanarye]

Nonetheless, there are 2 reasons I still prefer the type specification syntax:

...

The much more important reason, is that the syntax here serves 2 purposes:

1. let the compiler know it needs to focus on the typing here (as with the `_::` syntax)

Why would the compiler need to "focus"? It's not a human - it does not have a limited attention span that needs help limiting itself to the important things.

2. let the reader know what types you're working with here

That is to say, by re-declaring the types you're working with, just above a complex operation involving those types, it makes it easier to understand the code without flitting back and forth; seeing _::, in my opinion, just tells the reader that it's possible to figure out the typing, if they so wish. It could be said that it increases the spatial locality of the type annotation for readers.

The reader, on the other hand, does need to focus. And so does the writer. I think, in a match statement (TBH - pretty much in any place where this feature is relevant) the type is not what one needs to focus on - it's the variants. Just like omitting the type when you use combinators (where would one even write the types when using combinators? EXACTLY!) doesn't hurt readability, so does inferring the types in these cases.

Naturally, if one didn't want to write out a type (or sub-sections for a more complex type), it would make sense to allow _ in the type specification, e.g. match fred: (Foo::Fruits, _) {...}, since these notations are not mutually exclusive.

I'm confused - wouldn't omitting the type there mean you have to write it in every branch of the match?

This is the colon syntax that I'm suggesting:

match fred: (Fruits, Bar::Companies) {
    (Apple, Google) => { ... }
    (Orange(x), Samsung) if x < 7 => { ... }
    (Orange(_), x) if !matches!(x, Samsung) => { ... }
    (Durian, Apple) => { ... }
    _ => { ... }
}

I don't like this syntax for the following reasons:

1. I think the rules are too complicated. From the rest of what you wrote, I understand that the : (Fruits, Bar::Companies) brings the variants of Fruits and Bar::Companies into scope - but only in the places where they'd fit into the patterns of destructuring fred? But the matches!(x, Samsung) bit implies it gets extended to items bound into these pattern? How far does it go? Can I use the other variants Bar::Companies inside the branch block itself, as long as it refers to x?
2. When use Fruits::*; brings Apple, Orange and Durian into scope, these names are represented by the *. With just Fruits, what represents the variants?
3. It's much less versatile than _. Even in the scope of match - consider if Fruits::Orange's payload was an struct Orange { ... }:

   match fred: (Fruits, _) {
       (Orange(Orange { size, firmness }), _) => { ... }
       _ => { ... }
   }

   We have to repeat the word Orange twice (because no one brought the Orange struct into scope) whether with the _ syntax we can infer that too since it's the type of the variant's payload:

   match fred {
       (_::_Orange(_ { size, firmness }), _) => { ... }
       _ => { ... }
   }

To note, tuple variants under underscore syntax, like _::Orange(_), would be valid, semantically correct syntax, which doesn't break anything, but there's just something to be said about juxtaposing two different usages of the same symbol.

This is already supported - e.g. one could use Some::<_>(_) as a pattern.

If we get into the point that only ambiguous variants should use _::, I'd like to raise the point that Orange is also a company and would then also require disambiguation, but you can't tell that just by looking at the code here.

There is no ambiguity because the _::Orange resolution does not start from Orange. It starts from _. The compiler looks at _ and says "there should be a constructor pattern here - but of which type?" and uses the other information (type of first item of fred) to infer that type. Once it knows the type, it replaces _ with it - and only then looks at the ::Orange. At no point does it care that other enums also have an Orange variant.

I think the heart of the problem is that we're happy to have imported things beforehand, and to have properly qualified our types, but not to keep qualifying them again and again in match arms.

I'm not happy with either of these things. I don't want to pollute the namespace with something the compiler can easily infer for me, and more importantly - having to needlessly acknowledge types decreases the power of macros (which can't always determine the type)

[kennytm]

: {type} is now my preferred keyword: it mirrors the type specification syntax that we're already familiar with in rust

afte type-ascription got nuked from orbit (#3307) I'm quite certain the expr: Type syntax will never pass T-lang.

[lemon-gith]

Colon and Underscore Syntax Flaws

Readability is partially about how quickly a reader can understand code; reducing effort on the writer's side generally increases the effort on the reader's side, and rust is a language that's designed for maintability and sacrificing write-time (be that for run-time or for read-time).

2. When use Fruits::*; brings Apple, Orange and Durian into scope, these names are represented by the *. With just Fruits, what represents the variants?

Nothing represents the variants, the whole enum is 'brought into scope', which is in line with the way that pub enum is handled in rust, as opposed to pub struct.

3. It's much less versatile than _. Even in the scope of match - consider if Fruits::Orange's payload was an struct Orange { ... }: [...] We have to repeat the word Orange twice.

Firstly, I did admit that the _-syntax is indeed more versatile, and that I'm only advocating for a different syntax for match statements, specifically.
Secondly, in the example you put forwards (below), I'm actually completely in favour of repeating Orange twice. That is because each Orange refers to a completely different type, and therefore should be qualified individually.

I don't mean this in an antagonistic way, but could you really tell me if you saw:

match fred {
    (_::Orange(_ { size, firmness }), _)

in an unfamiliar codebase, that it would be easier for you to understand than:

match fred using (Fruits, b::C) { // qualifying:
    (Orange(Orange { size, firmness }), _)

The former tells me that there's an enum (? I'm guessing) somewhere, with an Orange variant, holding a struct with a name.
The latter tells me that there's an enum called Fruits, and that its Orange variant holds a struct, also called Orange.

Moreover, if I want to find its definition, I'd know that Fruits is either:

• fully qualified by a use statement somewhere in this module
• defined within this module
• or were it std::foo::Fruits (e.g.), that's already its full qualification path

Though the compiler would likely be fine with either, as the reader, you understand what's going on much quicker with the latter syntax.

This is already supported - e.g. one could use Some::<_>(_) as a pattern.

This is a good example, I don't particularly like that pattern, but if it is part of the language, then my previous point is rendered moot.

after type-ascription got nuked from orbit (#3307) I'm quite certain the expr: Type syntax will never pass T-lang.

Thank you @kennytm, I wasn't aware: there are good points in there. Independently, I've also realised another problem with the colon syntax: it is a lie, i.e. it's misleading as to what is happening under-the-hood.

---

Proposing regression to using keyword

@idanarye, thank you for highlighting a very important point here, which is that type specification is indeed not the proper way to qualify these match heads.
Admittedly, I think I was just drawn in by how clean and familiar the colon syntax was, but you're absolutely right to point out that type specification is not actually what the colon syntax translates to under-the-hood: that syntax would be misleading. I was wrong to pick that syntax.

Instead of editing my previous comment, and distorting a good debate, I'll put this here¹:

match fred using (Fruits, bar::Companies) {
    (Apple, Google) => { ... }
    (Orange(x), Samsung) if x < 7 => { ... }
    (Orange(_), x) if !matches!(x, Samsung) => { ... }
    (Durian, Apple) => { ... }
    _ => { ... }
}

My suggestion here, is that this would translate to path expansion under-the-hood, e.g. Google -> bar::Companies::Google. In something akin to, but not exactly like, the use keyword (hence using).

Based on our previous discussions of what _:: can do as is, I think we can agree that it would be possible for the compiler to fill in this much information, given what it already knows and the qualifications provided by the using clause, e.g. expanding Apple to Fruits::Apple given that it's being compared to sub-variable of type Fruits.

In this Rust Playground, I've written a crude example of what a compiler expansion could look like.

Going Forwards (match statements)

I also feel like using syntax still isn't an optimal solution, since it would require the introduction of a new keyword that has a very limited use-case.

Warning

It may be a good idea to separate the discussions surrounding:

1. _:: syntax for imports and inferred types
2. more concise match patterns

since I think the solutions may differ slightly in their optimal implementations.

To bring us back to square one, I'd like to consider what our goal is (for match), i.e. what the ideal syntax would look like for match statements:

match fred {
    (Apple, Google) => { ... }
    (Orange(x), Samsung) if x < 7 => { ... }
    (Orange(_), x) if !matches!(x, Samsung) => { ... }
    (Durian, Apple) => { ... }
    _ => { ... }
}

In my head, this would be perfect:

• no boilerplate on the match head
• match arms as simple as they can be
• type-continuity within match arms, for match guards

I think it would be a good idea to define what we're working towards, and then from there decide what we're willing to compromise on, in order to achieve a result as close to it as possible.

Footnotes

1. I've lowercased Bar to bar, to conform to module naming practices, since it was just a placeholder ↩

[idanarye]

Readability is partially about how quickly a reader can understand code; reducing effort on the writer's side generally increases the effort on the reader's side, and rust is a language that's designed for maintability and sacrificing write-time (be that for run-time or for read-time).

The way I see it, readability is not about info-dumping as much as possible on the reader. Omitting information only hurts readability if the omitted information is required for understanding the code (the flow of the code - not every little decision the compiler is going to make when compiling it)

My argument is that in cases handled by this feature¹, this information is not required. I'll explain with the example you gave:

I don't mean this in an antagonistic way, but could you really tell me if you saw:

match fred {
    (_::Orange(_ { size, firmness }), _)

in an unfamiliar codebase, that it would be easier for you to understand than:

match fred using (Fruits, b::C) { // qualifying:
    (Orange(Orange { size, firmness }), _)

The former tells me that there's an enum (? I'm guessing) somewhere, with an Orange variant, holding a struct with a name. The latter tells me that there's an enum called Fruits, and that its Orange variant holds a struct, also called Orange.

In both versions, I know that I'm handling the Orange case of fred.0 and I know that I'm using the size and firmness values of that case. I don't know what the types of size and firmness are in either version, and no one suggest we have to spell these types here - even though we are probably going to use size and firmness inside the branch's block.

No version tells me what the Orange case means. Knowing that the name of the type inside it is Orange provides no additional insight ("orange is orange". Brilliant). The documentation comment of Orange - either one in the variant or one in the struct - could have explained what "orange" means - but I hope no one suggest we should force developers to copy-paste the documentation comments to patterns?

The second version tells me that there is a struct named Orange. So what? I'm not using that struct. I'm using its fields. When reading this code, I don't care which methods this struct supports, because there is no binding of type Orange here that can use these methods. That type would be of interest had it not been destructured:

match fred using (Fruits, b::C) { // qualifying:
    (Orange(orange), _) => { ... }

Because then we could do orange.some_orange_method() inside the block. But in this case - even current Rust syntax that does not have this feature does not force us (or even make it possible, at least without rebinding it inside the block) to acknowledge that type.

Fruits is similar. We don't use fred.0 as a Fruits - we destruct it immediately. Why is acknowledging the type more important when accessing a variant than when accessing a method? If anything, I'd say it's less important because you want to focus on the variant.

Footnotes

1. One exception of this rule is the newtype pattern, which can be solved by either linting the usage of this feature with single-item tuple structs or by disabling it for tuple structs entirely (either way - this limitation should only apply for tuple structs. Tuple variants of enums should still be able to use the feature) ↩

[tmccombs]

Ideally, I think the solution for this should work in all pattern contexts, not just match expressions. That would include things like if let, while let, let/else, macros like matches!, etc.

The using syntax (and : syntax in the scrutinee part) don't really work for that.

[idanarye]

I don't think the using syntax is even meaningful for other patterns. match is the only one where the type is repeated. I don't see how this:

if let Orange(orange) = fruit using Fruits {
    ...
}

Is better than this:

if let Fruits::Orange(orange) = fruit {
    ...
}

[JoshBashed]

I wrote this PR when I was much younger and more naive. Looking back, I realize there are definitely areas that need revision.

One major concern I’ve been reflecting on is how we resolve the base type when using _::. A core principle of Rust is explicitness, especially around imports; developers are expected to use every type they interact with. But this proposal introduces what could be seen as “ghost imports,” where a type can be referenced and instantiated without being explicitly brought into scope.

This is a pretty fundamental shift from how Rust usually operates. It creates a case where types are being used without a visible import path, which could affect both readability and tooling support. For example, it becomes harder to track type usage by grepping for its name or relying on IDE tooling, since _ hides the identity of the type.

One possible solution is to require that the type behind _:: must already be in scope via a use statement (similar in spirit to the using keyword proposal). While this would keep type usage explicit, it may reduce the ergonomics and conciseness the proposal aims to provide. It also introduces the odd case where something is technically used but appears unused in the code.

These are just some of my thoughts. I don’t have a fully formed solution yet, but I’d love to hear your input so I can revise the RFC accordingly.

[idanarye]

But this proposal introduces what could be seen as “ghost imports,” where a type can be referenced and instantiated without being explicitly brought into scope.

Rust can already do that - e.g. with Default::default().

[JoshBashed]

Whoops! You’re right! Yet another reason why this change is not problematic!

[bbb651]

Proposing regression to using keyword

@idanarye, thank you for highlighting a very important point here, which is that type specification is indeed not the proper way to qualify these match heads.
Admittedly, I think I was just drawn in by how clean and familiar the colon syntax was, but you're absolutely right to point out that type specification is not actually what the colon syntax translates to under-the-hood: that syntax would be misleading. I was wrong to pick that syntax.

Instead of editing my previous comment, and distorting a good debate, I'll put this here1:

match fred using (Fruits, bar::Companies) {
    (Apple, Google) => { ... }
    (Orange(x), Samsung) if x < 7 => { ... }
    (Orange(\_), x) if !matches!(x, Samsung) => { ... }
    (Durian, Apple) => { ... }
    \_ => { ... }
}

My suggestion here, is that this would translate to path expansion under-the-hood, e.g. Google -> bar::Companies::Google. In something akin to, but not exactly like, the use keyword (hence using).

Based on our previous discussions of what _:: can do as is, I think we can agree that it would be possible for the compiler to fill in this much information, given what it already knows and the qualifications provided by the using clause, e.g. expanding Apple to Fruits::Apple given that it's being compared to sub-variable of type Fruits.

In this Rust Playground, I've written a crude example of what a compiler expansion could look like.

Doesn't this have the exact same problems as use Enum::*? If I remove Fruits::Apple, suddenly Apple in the pattern is now an identifier, which will make the pattern match anything silently without an error (only an unused variable warning, and maybe an unreachable pattern warning).
_::Apple on the other hand is explicitly an enum variant and will to compile.

I also don't like the syntax, firstly I think using should be replaced with use: using is not a keyword so we either have to reserve it which is a ton of churn and needs to wait for an edition or make it a "soft keyword" which is bad for tooling, especially simpler syntax highlighting. More importantly, it forces you to opt-in to it in a way that's global to the match rather than local to the pattern, which is bad in general - it makes it harder to reason about large matchs without seeing the start (which is where this is most useful), to copy code, to correlate the changes in diffs, etc. And it's incompatible with other contexts patterns are used.

[daniel-pfeiffer]

I agree that its much better to infer _::Apple as the enum expected in that context.

match fred {
    (_::Apple, _::Google) => { ... }
    (_::Orange(x), _::Samsung) if x < 7 => { ... }
    (_::Orange(_), x) if !matches!(x, _::Samsung) => { ... }
    (_::Durian, _::Apple) => { ... }
    _ => { ... }
}

[joshtriplett]

One major concern I’ve been reflecting on is how we resolve the base type when using _::. A core principle of Rust is explicitness, especially around imports; developers are expected to use every type they interact with. But this proposal introduces what could be seen as “ghost imports,” where a type can be referenced and instantiated without being explicitly brought into scope.

In addition to the mention below that we already support this in some cases: in general, this would be most useful when a function is already accepting or returning such a type, and that function is in scope (or being referenced by an explicit path). That means the type is indirectly referenced, and the type system is already willing to infer it as the type of something. For instance, if you write:

    let x = func();

Then x has a type that you might not have imported; you might have to add a use if you want to name the type of x. But the compiler knows what type it is.

I can definitely see a few different cases for being able to write _::Variant. The variants that depend on what you import or what is available would involve more complexity and be more prone to breakage, but be more flexible; the variants that depend on already knowing the type would be simpler but allow elision in fewer cases. The maximum complexity comes when combining both.

(The options below reference enums, specifically. This RFC also covers inferring struct types, but I think the variations are different for that, and I'll mention later in this comment how I think that ties in.)

Option 1:

• Allow writing _::Variant only when the concrete type is already clear, such as a function argument or variable whose type was inferred from a function return value.
• Relatively simple, but needs clear specification.
• Potential pressure to expand the cases that support it.
• Does not allow eliding in all cases someone might want to (e.g. initializing something and then passing it to a function, or passing something to a generic argument).

Option 2:

• Allow writing _::Variant for any enum that's in scope.
• The simplest version just doesn't allow any name that has a conflict, requiring disambiguation in that case.
• Would be somewhat prone to breakage, if you import a new enum, or an enum you import adds a new variant.
• Potentially less obvious to a human reader what enum/struct/etc is being used, because it isn't tied directly to a function argument. It's at least constrained to types imported, but that may not help much since those are at the top of the file.

Option 3:

• Allow writing _::Variant for any enum even if not in scope (e.g. because it's an argument or return value of a called function).
• Extremely prone to breakage when a new enum or variant gets added anywhere.
• Potentially much less obvious to a human reader what enum/struct/etc is being used, because it isn't necessarily tied directly to a function argument or return value, and isn't even imported.

Option 4:

• Option 2 or 3, but also make it subject to type inference to disambiguate, like option 1.
• This would address the additional elision cases people might want from option 1, but would be much more complex.
• Breakage gets somewhat addressed by the disambiguation, but depending on the rules here, might still be as prone to breakage as option 3.
• Still potentially hard to find when not disambiguated by a function argument / return value.

I think we should rule out option 2, because it loses most of the benefit of not having to write a use just to pass an argument. I think we should rule out 3, on the basis of being extremely breakage-prone; I think it'd make the ecosystem substantially more fragile.

I used to favor something closer to option 4, for the flexibility. But I'm now concerned about the breakage/fragility in the ecosystem, and about the potential ambiguity for a human reader about what type is being referenced.

I would personally advocate for option 1: only allow the elision when it's made obvious by existing type inference. Function arguments, function return values, (non-generic) field of another struct, etc. This would still need careful specification, for cases like func(Some(_::Variant)) (if those are supported), but it seems like the safest and simplest of the options.

I think the same goes for structs, here. In theory there are analogous options for "infer a struct by its field types", but those seem even less reasonable than inferring an enum by its variant name. I think we should go with the equivalent option 1 there, too: only infer a struct when its type is already obvious from type inference.

[idanarye]

Option 1:

• ...
• Does not allow eliding in all cases someone might want to (e.g. initializing something and then passing it to a function, or passing something to a generic argument).

Why? The type inference rules Rust currently has already allow initializing something with inferred type and then passing it to a function:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=9d492b2cbe966f607d597f22f26c7e61

fn foo(bar: i32, baz: f32, qux: bool) {
    dbg!(bar, baz, qux);
}

fn main() {
    let bar = Default::default();
    let baz = Default::default();
    let qux = Default::default();
    foo(bar, baz, qux);
}

TBH I don't know why the other options are seriously considered. They are not type inference - they are just "scan every symbol available to the compiler and see if something fits". I mean, why not support let x = _(_, _, _, _, _); and have the compiler check if there happens to be a function with arity of 5 somewhere?

[traviscross]

This discussion reminds me of method resolution. Many of the tradeoffs seem roughly similar.

E.g., the presented "Option 1" is spiritually similar to a method resolution rule that only considers "inherent" candidates.

mod m {
    pub trait Tr<T> { fn f(&self) {} }
}

fn g<T>(x: impl m::Tr<T>) {
    x.f(); //~ Inherent candidate.
}

"Option 2" (if I understand the proposal) is spiritually similar to a method resolution rule that would reject the above (since Tr<T> is not in scope) and would consider only "extension" candidates (methods from in-scope traits).

mod m {
    pub trait Tr<T> { fn f(&self) {} }
    impl<U> Tr<()> for U {} //~ This is the "one impl".
}
use m::Tr as _; //~ `Tr` is now in scope.

fn g(x: impl Sized) {
    x.f(); //~ Extension candidate (also note "one impl rule").
}

That we consider extension candidates is a source of (RFC 1105-allowed) breakage. That this can interact with the one impl rule (a.k.a. "1-impl rule"), as above, extends this further.

It's an interesting counterfactual to consider what Rust would have looked like if we had prioritized avoiding this breakage and had only done method resolution based on inherent candidates (e.g., probably we would have added a way at the use site to make a trait's methods inherent candidates for a receiver of concrete type by explicitly asserting the type implements the trait). Maybe or maybe not there are lessons to draw from this for the design here. At least, it seems maybe worthwhile to compare what breakage we consider acceptable due to new trait methods and new trait impls with what breakage we might or might not consider acceptable for new enum variants, etc., and if we feel differently between these, why that is.

[igotfr]

@lemon-gith as is used to cast, yet this code compile successfully:

enum Fruits {
    Orange,
    Grape
}

fn main() {
  match Fruits::Orange as Fruits {
      Fruits::Orange => print!("orange"),
      Fruits::Grape => print!("grape")
  }
}

it's not made for it but suits very well

[fee1-dead]

I am very surprised to see this discussion still being active. I thought this thread would have died down, but it looks like there are people who genuinely want to see this happen.

I understand the desire to make Rust developers write less characters. I still personally hold the idea that this hurts readability, and also greppability. (how do I find all code that uses a particular variant on a particular enum (construct/deconstruction) when the variant name can clash with other enums? One may argue that we have enough LSP power to just use that, but I don't find the reliance on LSPs very pleasant) For the same reason, I would consider allowing things like Default::default() a mistake. Rust to me is still an "explicit" language, and we have successfully shown that the explicitness does not hurt productivity given we still have plenty of ways to dedup code and write code in an elegant way.

With that, I still want to leave some practical considerations. This does not seem specifiable with only words. Lots of alternatives and potential directions are being given, but no specific implementation has been drafted (at least according to my knowledge).

We cannot do language design on a feature this impactful without at least some experimental support. No amount of specification can predict implementation challenges, potential pitfalls, or cover all edge cases.

And I don't think folks working on the compiler will like this proposal:

1. It is vague as it has to interact with type inference. When are we able to resolve _::Variant and when are we not? This is a messy bi-directional between expected types and actual types of an expression/pattern
2. It touches both type inference and path resolution. These two areas are the most hard to hack in the compiler (at least IMO)
3. (IMO) It isn't very fun. It doesn't enable any additional interesting use cases, it doesn't make it possible to do things that we previously cannot before. Unclear impact about how much time this saves, really, would there be additional time taken trying to know which enums these are?

And this is not just me trying to convince yall to stop considering this proposal, though I just want to say that I think no meaningful progress can be made without work on the compiler, and it will be hard to get compiler work done.

[JoshBashed]

@fee1-dead

I am very surprised to see this discussion still being active. I thought this thread would have died down, but it looks like there are people who genuinely want to see this happen.

I understand the desire to make Rust developers write less characters. I still personally hold the idea that this hurts readability, and also greppability. (how do I find all code that uses a particular variant on a particular enum (construct/deconstruction) when the variant name can clash with other enums? One may argue that we have enough LSP power to just use that, but I don't find the reliance on LSPs very pleasant) For the same reason, I would consider allowing things like Default::default() a mistake. Rust to me is still an "explicit" language, and we have successfully shown that the explicitness does not hurt productivity given we still have plenty of ways to dedup code and write code in an elegant way.

With that, I still want to leave some practical considerations. This does not seem specifiable with only words. Lots of alternatives and potential directions are being given, but no specific implementation has been drafted (at least according to my knowledge).

We cannot do language design on a feature this impactful without at least some experimental support. No amount of specification can predict implementation challenges, potential pitfalls, or cover all edge cases.

And I don't think folks working on the compiler will like this proposal:

1. It is vague as it has to interact with type inference. When are we able to resolve _::Variant and when are we not? This is a messy bi-directional between expected types and actual types of an expression/pattern
2. It touches both type inference and path resolution. These two areas are the most hard to hack in the compiler (at least IMO)
3. (IMO) It isn't very fun. It doesn't enable any additional interesting use cases, it doesn't make it possible to do things that we previously cannot before. Unclear impact about how much time this saves, really, would there be additional time taken trying to know which enums these are?

And this is not just me trying to convince yall to stop considering this proposal, though I just want to say that I think no meaningful progress can be made without work on the compiler, and it will be hard to get compiler work done.

In the past, T-Compiler has weighed in on this discussion and has said that they don't really want to implement it in its current state:

pnkfelix11:32
we also may have an issue in that it seems like members of the T-lang team were sympathetic to trying to solve the problem described by this RFC, which was a reason we wanted to enable moving forward with an experiment, but at the same time, (some) members of T-compiler are skeptical about feasibility of implementation.
So we hit this weird situation where T-lang does not want to be blocking forward progress, and thus approves experimental work, but representatives of T-compiler raise objections and say "this needs more fleshing out via RFC process."

workingjubilee 11:54
@josh to be clear, if T-compiler says no, it doesn't matter what T-lang says.

You are the first in this thread to offer concrete direction on how the RFC could be improved. Given the implementation concerns you outlined, would it make sense to scope an initial experiment to function calls and match patterns only? If limited to that surface area, do you think T-Compiler would be open to considering it?

[fee1-dead]

You are the first in this thread to offer concrete direction on how the RFC could be improved.

I am not. I am telling you this instead: Because it is very unlikely you can find an experienced contributor to carry out the implementation work, there is no way for this RfC to proceed. Hence I believe spending a lot of effort in discussing the language design will not yield satisfactory results. Hence I recommend either dropping this proposal (to be clear, I don't think lang ever authorized an experiment here) or attract an experienced compiler folk to work towards your goal. Otherwise this cannot get any additional traction.

[JoshBashed]

You are the first in this thread to offer concrete direction on how the RFC could be improved.

I am not. I am telling you this instead: Because it is very unlikely you can find an experienced contributor to carry out the implementation work, there is no way for this RfC to proceed. Hence I believe spending a lot of effort in discussing the language design will not yield satisfactory results. Hence I recommend either dropping this proposal (to be clear, I don't think lang ever authorized an experiment here) or attract an experienced compiler folk to work towards your goal. Otherwise this cannot get any additional traction.

Thanks for the response. I strictly do not agree that the discussion should stop at this point. Whether the proposal can progress should depend on the design and on implementation feasibility. I plan to continue refining the RFC and to investigate what a prototype would involve. If the concerns are about ambiguity or feasibility, I am prepared to address those.

[idanarye]

scope an initial experiment to function calls and match patterns only

I'm not a compiler developer, so I could be totally off the mark, but is this really limiting the surface area? Function calls (I assume you mean the arguments?) are Expr and match patterns are Pat (I'm using the syn types, but I assume the structure inside the compiler is similar?) - aren't these two smaller constructs cover pretty much everything the full implementation of this feature will need?

What's the difference between supporting foo(_::Bar) and supporting foo.baz = _::Bar;? In both _::Bar is the same syntax subtree, and in both cases the compiler already knows how to infer the type of the expression that needs to go in that place (because it can do it for, say, Default::default()). Wouldn't it be the same amount of work and the same amount of code changes to support both vs only supporting one?

If we want to suggest a limitation to the surface area, I think it would make more sense to pick one - either only support patterns for the experiment or only support expressions for the experiment.

[JoshBashed]

@idanarye

What's the difference between supporting foo(_::Bar) and supporting foo.baz = _::Bar;?

The main case I was trying to avoid is using _:: or _ { } when the type is determined by the context. For example:

#[derive(Debug, Default)]
struct Test {
    pub test: u8,
}

pub fn main() {
    let mut a = _ { test: 0 }; // Type is not known at this point.
    println!("{:?}", a);
    a = Test { test: 1 }; // Type becomes known here.
    println!("{:?}", a);
}

Handling this seems like a different level of complexity compared to _::Variant in match patterns or function arguments.

[fee1-dead]

I'm not a compiler developer, so I could be totally off the mark, but is this really limiting the surface area?

precisely the reason why you need an experienced compiler contributor....

[idanarye]

@JoshBashed I don't understand how that differs (for our purpose) from a function call.

Consider this:

pub fn main() {
    let mut a = _ { test: 0 }; // Type is not known at this point.
    let mut b = Default::default(); // Type is not known at this point.
    println!("{a:?} {b:?}");
    a = Test { test: 1 }; // Type becomes known here.
    b = Test { test: 2 }; // Type becomes known here.
    println!("{a:?} {b:?}");
}

The compiler deduces the type of a in the exact same way it deduces the type of b. Which means it reuses the type inference code, and "simply" applies the regular rules to the new construct.

Now, consider:

fn test(_: Test) {}

fn main() {
    test(_ { test: 0 });
    test(Default::default());
}

Here, also, the compiler uses the same inference rules it used for Default::default() to deduce the type of _ { test: 0 }.

In both cases we want the compiler, when it sees _ { test: 0 }, to use the regular inference rules for expressions in that slot. Rules that it already has. So wouldn't the implementing it for one case "automatically" also apply to the other?

[kanashimia]

With regards to implementation the feature described in this RFC
is conceptually similar to the following:

type Thing<T> = T;
struct Foo {}

fn main() {
  let _foo: Foo = Thing::<_> {};
}

The above code currently gives the following error:
error[E0071]: expected struct, variant or union type, found inferred type
but it works if you specify the generic as Foo explicitly.
Similar happens with enums too.

I reason implementing the above would be simpler as it is an existing syntax,
I'm not suggesting that as a feature, but if anyone wants to take a go at implementing this RFC
then implementing the support for the inferred types at all in that position would be reasonable as a first step.

I took a go at it some time ago and it was unexpectedly complicated,
indeed it seems having someone with actual experience here is needed.

---

Also for context the following works on nightly already:

#![feature(default_field_values)]
#![feature(type_alias_impl_trait)]
#![allow(unused)]
// -Znext-solver=globally is required

macro_rules! infer {
    (_ $($tt:tt)+) => {
        'block: {
            type InferredType = impl ?Sized;

            if false {
                let fake_value: InferredType = loop {};
                break 'block fake_value;
            }

            InferredType $($tt)+
        }
    }
}

struct Foo {
    foo: u32 = 0,
    bar: String,
}

enum Bar {
    Huh,
}

fn main() {
    let _foo: Foo = infer!(_ {
        bar: "lol".to_string(),
        ..
    });

    let _bar: Bar = infer!(_::Huh);
}

playground link: https://godbolt.org/z/sYY6WM8eb

Which is kinda funny that that is allowed but inferred types aren't...

So when TAIT and next-solver=globally are stabilized,
they could be abused to get some of the benefits.
At least if the above behaviour isn't yanked.

Of course that isn't as useful and as nice as what is proposed in this RFC,
but at least for those APIs that use config structs it would be nice.
Maybe could write an attribue macro to hack all constructs for inferance like that.

[jhpratt]

3. It doesn't enable any additional interesting use cases

While strictly true, having this feature in combination with default field values (already RFC-accepted) would permit this to be more ergonomic by not requiring an import or cluttering the code with something that is obvious (to the reader) in context.

impl Foo {
    pub fn new_with(params: Params) -> Self { /* … */ }
}

Foo::new_with(_ { alpha: 0, beta: "", .. })

That's not to say that your concerns are unfounded; I absolutely agree this is not trivial. But I want to push back slightly against the assertion that it doesn't unlock anything new. It will enable new patterns to be established imo.

[JoshBashed]

@idanarye

I don't understand how that differs (for our purpose) from a function call.

If it does, then that's great. I haven't took a crack at it yet. I hope that will be how it works.

[fmease]

Also for context the following works on nightly already:
[…]
https://godbolt.org/z/sYY6WM8eb

That sure is interesting. rustc behaves quite buggily there IINM. If you swap the branches and substitute false with true it no longer compiles, meaning the LUB coercion isn't commutative / order-independent which it should be unless I'm super off-base (it's late). I've reported this as a bug here: rust-lang/rust#149078.