Stabilize const_constructor

[matthewjasper]

Stabilization proposal

I propose that we stabilize #![feature(const_constructor)].

Tracking issue: #61456
Version target: 1.40 (2019-11-05 => beta, 2019-12-19 => stable).

What is stabilized

User guide

Tuple struct and tuple variant constructors are now considered to be constant functions. As such a call expression where the callee has a tuple struct or variant constructor "function item" type can be called:

const fn make_options() {
    // These already work because they are special cased:
    Some(0);
    (Option::Some)(1);
    // These also work now:
    let f = Option::Some;
    f(2);
    {Option::Some}(3);
    <Option<_>>::Some(5);
}

Motivation

Consistency with other const fn. Consistency between syntactic path forms.

This should also ensure that constructors implement const Fn traits and can be coerced to const fn function pointers, if they are introduced.

Tests

• ui/consts/const_constructor/const-construct-call.rs - Tests various syntactic forms, use in both const fn and const items, and constructors in both the current and extern crates.
• ui/consts/const_constructor/const_constructor_qpath.rs - Tests that type qualified paths to enum variants are also considered to be const fn.(Self::EnumVariant not considered const fn #64247)

r? @oli-obk

Closes #61456
Closes #64247

[Centril]

Thanks for the report!
I also propose that we do indeed stabilize const_constructor.

@rfcbot merge

---

r? @Centril r=me once FCP completes.

[rfcbot]

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

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

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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.

[pnkfelix]

as described, this seems fine to me.

I would like to note that another case where const constructors arise is in the context of patterns, e.g.:

#[derive(PartialEq, Eq)]
struct Hi(i32);

const fn hi() -> Hi { Hi(10) }
const C: Hi = hi();

fn main() {
    match Hi(10) {
        self::C => println!("matched"),
        _ => println!("other"),
    }
}

But as far as I can tell, the change being suggested here does not introduce any interesting changes to our behavior for such cases.

[pnkfelix]

@rfcbot reviewed

[rfcbot]

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

[bors]

☔ The latest upstream changes (presumably #65804) made this pull request unmergeable. Please resolve the merge conflicts.

[rfcbot]

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

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

[matthewjasper]

@bors r=Centril

[bors]

📌 Commit 170718c has been approved by Centril

[bors]

⌛ Testing commit 170718c with merge 077619e...

[bors]

💥 Test timed out

[Centril]

@bors retry

[bors]

⌛ Testing commit 170718c with merge 03a50ae...

[bors]

☀️ Test successful - checks-azure
Approved by: Centril
Pushing 03a50ae to master...

[jadbox]

Does this improve performance at all when calling these constructors or no?

[matthewjasper]

No, this is just fixing inconsistent behaviour.