Tracking issue for "clarified ADT kinds" (RFC 1506)

[nikomatsakis]

Tracking issue for rust-lang/rfcs#1506.

Status:

Fully stabilized.

Stabilized by PR #41145:

• Numeric fields in struct expressions/patterns S { 0: a, 1: b } are not yet stabilized.
  • We've decided to stabilize the existing support, but we're still in need of a PR. If you're interested in contributing, directions for stabilizing this feature can be found here.

Stabilized by PR #36868:

• Lifted restrictions on tuple structs/variants are stabilized, i.e. S{..} can be used with any structs and empty tuple structs are permitted without feature gate.

[nikomatsakis]

@rfcbot fcp merge

I propose that we stabilize this feature. There are no known blockers or interactions and it is a relatively minor extension to existing syntax. I would very much welcome the ability to use {} more consistently.

[rfcbot]

FCP proposed with disposition to merge. Review requested from:

• @aturon
• @eddyb
• @nikomatsakis
• @nrc
• @pnkfelix

No concerns currently listed.
See this document for info about what commands tagged team members can give me.

[rfcbot]

All relevant subteam members have reviewed. No concerns remain.

[rfcbot]

It has been one week since all blocks to the FCP were resolved.

[nikomatsakis]

Entering FCP. Honestly I'm not clear for how long. =) Stabilizations still confuse me a bit.

[nikomatsakis]

The release is coming up, and this has not exactly been a controversial topic, so we've decide to make it official and approve this for stabilization.

[nikomatsakis]

@rfcbot fcp merge

I'd like to propose that we stabilize the remaining feature in this feature-gate, numeric field names. For example, this code works now:

#![feature(relaxed_adts)]

struct Foo(u32);

fn main() {
    let Foo { 0: x } = Foo(22);
    println!("{}", x);
}

[Ixrec]

@nikomatsakis It looks like the rfcbot ignored your second merge request and nobody noticed for a month. Maybe it can't handle two fcp merges on the same issue?

[aturon]

cc @rust-lang/lang, since RFC bot doesn't allow us to FCP again, I'll make the list manually. @nikomatsakis proposed to go to FCP for stabilizing the numeric field names feature.

• @nikomatsakis
• @aturon
• @pnkfelix
• @nrc
• @withoutboats
• @eddyb

[petrochenkov]

See rust-lang/rfcs#902 (comment) for one more possible motivation for numeric fields in patterns.

[nikomatsakis]

cc @withoutboats @pnkfelix -- stabilizing numeric field names?

[withoutboats]

@rfcbot reviewed

FWIW I personally hate this and would never use it. I think its the kind of thing we can all politely disagree about though. :-)

[eddyb]

Had we went with some of the other suggestions, S { .0 = a, .1 = b } would make a lot of sense IMO.
That said, the current syntax is... prettier, on some subjective scale.

[nikomatsakis]

All reviewed now. @rfcbot seems to be on PTO, so I'm going to manually declare that this issue is entering Final Comment Period for 3 weeks (until Feb 1).

[glaebhoerl]

Fwiw (as I already expressed in a comment on the RFC iirc), I think the S { 0: a, 1: b } syntax is a net negative. The practical utility of it is thin (it's not even syntax sugar, but uh... whatever the opposite of that is), and per the "everything syntactically legal that the compiler accepts will eventually end up in your codebase" adage, it will inevitably lead to WTF moments. (It's pretty minor either way in the scheme of things, though.)

[glaebhoerl]

And as far as I can tell, this is still not possible? struct Test { 0: bool, 1: bool }, so it doesn't even fully bridge the gap between tuple structs and "structural structs".

(I was going to ask, "at least we don't allow declaring non-contiguous numeric fields, right?", and as far as that goes, apparently we don't.)

[aturon]

@glaebhoerl

I agree that numeric field patterns seem actively detrimental for hand-written code, but I believe the main motivation is to make life easier for various kinds of code generation by increasing overall uniformity (or, put differently, removing somewhat pedantic distinctions between kinds of struct delcarations).

[nikomatsakis]

Hmm. I am sympathetic but I do think there is a need to consolidate tuple/field structs into one logical structure, as well as to enable macros that work uniformly over them. I actually think we should support struct declarations like struct Test { 0: bool, 1: bool }. It seems like a logical conclusion.

[glaebhoerl]

Doesn't that run into type namespace vs. value namespace issues for the constructor, for the record? I do agree that if we allow one we should also allow the other, otherwise. (As long as struct Huh { 1: bool, 2: bool } and struct What { 0: bool, 9: bool } are disallowed, which do not correspond to any tuple structs.)

[nikomatsakis]

@glaebhoerl

Doesn't that run into type namespace vs. value namespace issues for the constructor, for the record?

Doesn't what run into said conflicts, exactly? (I would assume that if you wrote struct Test { 0: bool } you would not get any associated value.)

[petrochenkov]

I actually think we should support struct declarations like struct Test { 0: bool, 1: bool }

I don't know, numeric fields in expressions/patterns, while mostly useless, at least refer to something already existsing and useful - fields of tuple structs. struct Test { 0: bool, 1: bool } is something that is both useless and new.
FWIW, struct Test { 0: bool, 1: bool } already can be created with syntax extensions - field names created by them are not validated and can be lexically/syntactically invalid in arbitrary ways (including numeric).

[nikomatsakis]

@petrochenkov Not totally useless; it would let you replace a tuple-struct with a modified constructor, for example, without disturbing existing code.

e.g. transforming

pub struct Foo(pub usize);

into

pub struct Foo {
    0: usize
}

pub fn Foo(x: usize) -> Foo { Foo { 0: x * 2 } }

But anyway I don't feel a burning desire to add it. Just saying that it doesn't seem a priori out of the question to me.

[petrochenkov]

@nikomatsakis

it would let you replace a tuple-struct with a modified constructor, for example, without disturbing existing code.

There're still tuple struct patterns let Foo(x) = .... which can't use fns, so the code being undisturbed is not a guarantee.
(However, it'd be nice to find a way to somehow use const functions in this context, I've encountered cases where this would be useful.)

[nikomatsakis]

@petrochenkov true; my feeling is that those should desugar to Foo { 0: x }.

[scottmcm]

@nikomatsakis FCP complete? (Pinging since @rfcbot seems to still be on PTO for this issue.)

[aturon]

@scottmcm Yeah, I think we're ready to stabilize; while there's been some discussion since FCP, it's mostly been clarifying technical details or motivation, rather than bringing new tradeoffs to light.

[aturon]

cc @petrochenkov @rust-lang/compiler -- anyone want to make a quick stabilization PR that we can backport to 1.17 beta?

[nikomatsakis]

Stabilization is a great place for a first PR. There are directions available on the forge:

https://forge.rust-lang.org/stabilization-guide.html

Marking this as E-easy and E-mentor.

[nikomatsakis]

Ah, an important question -- has this been documented? If so, we ought to do that first.

[steveklabnik]

I do not believe so.

[est31]

cc #42945