Tracking issue for RFC 2302, Tuple struct construction with Self(v1, v2, ..)

[Centril]

This is a tracking issue for the RFC "Tuple struct construction with Self(v1, v2, ..)" (rust-lang/rfcs#2302).

Steps:

• Implement the RFC (Implement RFC 2302: tuple_struct_self_ctor #53751)
• Adjust documentation (see instructions on forge)
• Stabilization PR (see instructions on forge)

Unresolved questions:

None

[shepmaster]

Code that implements this has been merged.

#![feature(self_struct_ctor)]

struct Example(i32, bool);

impl Example {
    fn new() -> Self {
        Self(42, true)
    }
}

playground

[Centril]

@rfcbot merge

Stabilization report & proposal

Feature name: #![feature(self_struct_ctor)]
Version target: 1.32 (2019-01-18)

Originally accepted in rust-lang/rfcs#2302, I propose that we stabilize self_struct_ctor.
This has been in nightly since 2018-09-15 which is ~8 weeks ago.

The proposed change is not a blocker for anyone but it is a nice quality of life feature in some cases and more importantly, it makes the language less surprising and easier to learn. Furthermore, we do already permit Self { foo: ... }.

What is being stabilized

Relevant artefacts:

• Implementation
• Unstable book
• Feature gate
• Main tests

The changes are:

1. Self becomes a legal pattern and expression for unit structs in impls (both inherent and trait impls...).

match Self {
    Self => ...
}

2. Self(x1, x2, ...) becomes a legal pattern and expression for tuple structs in impls (both inherent and trait impls...).

match Self(0, 1) {
    Self(x, y) => ...
}

3. Self becomes a legal function pointer in impls (...).

opt.map(Self)

4. Points 1-3 work through type aliases just like Self { field: <thing> } does.

What is not being stabilized

Mentions of enum variants through Self is not being stabilized. For example:

enum Foo { Variant(u8), }

impl Foo {
    fn bar() {
        let x = Self::Variant(1);
    }
}

Divergences from RFC

None

[rfcbot]

Team member @Centril has proposed to merge this. The next step is review by the rest of the tagged teams:

• @Centril
• @aturon
• @cramertj
• @eddyb
• @joshtriplett
• @nikomatsakis
• @nrc
• @pnkfelix
• @scottmcm
• @withoutboats

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[caiopsouza]

A variant of what is not being stabilized gave me an internal compiler error.

Code:

#![feature(self_struct_ctor)]
#![allow(dead_code)]

enum Foo {}

impl Foo {
    fn bar() {
        Self(1u8);
    }
}

fn main() {}

Compiler output:

C:/Users/Caio/.cargo/bin/cargo.exe run --package nespera --bin nespera
   Compiling nespera v0.1.0 (C:\Users\Caio\projects\nespera)
error: internal compiler error: cat_expr Errd
 --> src\main.rs:7:14
  |
7 |       fn bar() {
  |  ______________^
8 | |         Self(1u8);
9 | |     }
  | |_____^

error: internal compiler error: cat_expr Errd
 --> src\main.rs:8:9
  |
8 |         Self(1u8);
  |         ^^^^^^^^^

error: internal compiler error: cat_expr Errd
 --> src\main.rs:8:9
  |
8 |         Self(1u8);
  |         ^^^^

error: internal compiler error: QualifyAndPromoteConstants: Mir had errors
 --> src\main.rs:7:5
  |
7 | /     fn bar() {
8 | |         Self(1u8);
9 | |     }
  | |_____^

error: internal compiler error: broken MIR in DefId(0/0:5 ~ nespera[1ed1]::{{impl}}[0]::bar[0]) ("return type"): bad type [type error]
 --> src\main.rs:7:5
  |
7 | /     fn bar() {
8 | |         Self(1u8);
9 | |     }
  | |_____^

error: internal compiler error: broken MIR in DefId(0/0:5 ~ nespera[1ed1]::{{impl}}[0]::bar[0]) (LocalDecl { mutability: Mut, is_user_variable: None, internal: false, is_block_tail: None, ty: [type error], user_ty: UserTypeProjections { contents: [] }, name: None, source_info: SourceInfo { span: src\main.rs:7:5: 9:6, scope: scope[0] }, visibility_scope: scope[0] }): bad type [type error]
 --> src\main.rs:7:5
  |
7 | /     fn bar() {
8 | |         Self(1u8);
9 | |     }
  | |_____^

thread 'main' panicked at 'no errors encountered even though `delay_span_bug` issued', src\librustc_errors\lib.rs:334:17
stack backtrace:
   0: std::sys_common::alloc::realloc_fallback
   1: std::panicking::take_hook
   2: std::panicking::take_hook
   3: rustc::ty::structural_impls::<impl rustc::ty::context::Lift<'tcx> for rustc::ty::instance::InstanceDef<'a>>::lift_to_tcx
   4: std::panicking::rust_panic_with_hook
   5: <rustc_errors::diagnostic::SubDiagnostic as core::fmt::Debug>::fmt
   6: <rustc_errors::Handler as core::ops::drop::Drop>::drop
   7: <humantime::duration::Error as std::error::Error>::cause
   8: <humantime::duration::Error as std::error::Error>::cause
   9: <humantime::duration::Error as std::error::Error>::cause
  10: <rustc_driver::derive_registrar::Finder as rustc::hir::itemlikevisit::ItemLikeVisitor<'v>>::visit_item
  11: _rust_maybe_catch_panic
  12: rustc_driver::profile::dump
  13: rustc_driver::main
  14: <unknown>
  15: std::panicking::update_panic_count
  16: _rust_maybe_catch_panic
  17: std::rt::lang_start_internal
  18: <unknown>
  19: <unknown>
  20: BaseThreadInitThunk
  21: RtlUserThreadStart
query stack during panic:
end of query stack

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.32.0-nightly (1f57e4841 2018-11-23) running on x86_64-pc-windows-msvc

note: compiler flags: -C debuginfo=2 -C incremental --crate-type bin

note: some of the compiler flags provided by cargo are hidden

error: Could not compile `nespera`.

To learn more, run the command again with --verbose.

Process finished with exit code 101

[Centril]

@caiopsouza Thanks for reporting this! Could you file this as a separate issue so that we can track and fix it?

[alexreg]

Stabilization PR

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

[stefson]

may I ask, in which release of rust was this merged? I hit it with rustc-1.31.1?

fixed in rustc-1.32.0, sry for the noise :-)