Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
nikomatsakis opened this issue Aug 12, 2016 · 31 comments

Comments

Projects
None yet
@nikomatsakis
Copy link
Contributor

commented Aug 12, 2016

Tracking issue for rust-lang/rfcs#1506.

Status:

Fully stabilized.

Stabilized by PR #41145:

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

This comment has been minimized.

Copy link
Contributor Author

commented Oct 4, 2016

@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

This comment has been minimized.

Copy link

commented Oct 4, 2016

FCP proposed with disposition to merge. Review requested from:

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

@rfcbot

This comment has been minimized.

Copy link

commented Oct 13, 2016

All relevant subteam members have reviewed. No concerns remain.

@rfcbot

This comment has been minimized.

Copy link

commented Oct 20, 2016

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

@nikomatsakis

This comment has been minimized.

Copy link
Contributor Author

commented Oct 21, 2016

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

@nikomatsakis

This comment has been minimized.

Copy link
Contributor Author

commented Nov 2, 2016

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.

eddyb added a commit to eddyb/rust that referenced this issue Nov 9, 2016

Rollup merge of rust-lang#36868 - petrochenkov:adtstab, r=nikomatsakis
Partially stabilize RFC 1506 "Clarify relationships between ADTs"

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.
Numeric fields in struct expressions/patterns `S { 0: a, 1: b }` are **NOT** stabilized.
This was implemented 1.5 months ago in Rust 1.12, but this is a tiny technical change that could probably go even without RFC/stabilization period.

cc rust-lang#35626 rust-lang#36871
r? @nikomatsakis
@nikomatsakis

This comment has been minimized.

Copy link
Contributor Author

commented Nov 11, 2016

@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

This comment has been minimized.

Copy link
Contributor

commented Dec 14, 2016

@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

This comment has been minimized.

Copy link
Member

commented Jan 4, 2017

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.

@petrochenkov

This comment has been minimized.

Copy link
Contributor

commented Jan 10, 2017

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

@nikomatsakis

This comment has been minimized.

Copy link
Contributor Author

commented Jan 10, 2017

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

@withoutboats

This comment has been minimized.

Copy link
Contributor

commented Jan 10, 2017

@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

This comment has been minimized.

Copy link
Member

commented Jan 10, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Jan 11, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Jan 11, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Jan 12, 2017

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

This comment has been minimized.

Copy link
Member

commented Jan 12, 2017

@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

This comment has been minimized.

Copy link
Contributor Author

commented Jan 12, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Jan 12, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Jan 13, 2017

@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

This comment has been minimized.

Copy link
Contributor

commented Jan 13, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Jan 13, 2017

@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

This comment has been minimized.

Copy link
Contributor

commented Jan 13, 2017

@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

This comment has been minimized.

Copy link
Contributor Author

commented Jan 17, 2017

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

@scottmcm

This comment has been minimized.

Copy link
Member

commented Feb 11, 2017

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

@aturon

This comment has been minimized.

Copy link
Member

commented Feb 12, 2017

@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

This comment has been minimized.

Copy link
Member

commented Mar 15, 2017

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

@nikomatsakis

This comment has been minimized.

Copy link
Contributor Author

commented Mar 16, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Mar 16, 2017

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

@steveklabnik

This comment has been minimized.

Copy link
Member

commented Mar 16, 2017

I do not believe so.

bors added a commit that referenced this issue May 25, 2017

Auto merge of #41145 - matthewjasper:stabilize-relaxed-adts, r=petroc…
…henkov

Stabilize rfc 1506 - Clarified ADT Kinds

Closes #35626

Documentation:

- [ ] Reference rust-lang-nursery/reference#37
- [ ] Book?
- [ ] Rust by example?

@bors bors closed this in #41145 May 25, 2017

@nikomatsakis nikomatsakis reopened this May 25, 2017

@est31

This comment has been minimized.

Copy link
Contributor

commented Jun 28, 2017

cc #42945

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.