Support `Self` in struct expressions and patterns by petrochenkov · Pull Request #37035 · rust-lang/rust

petrochenkov · 2016-10-08T00:32:52Z

Struct expressions and patterns generally support type aliases Alias { field: 10 } i.e. they already have to work with ty::Ty to do their job. Self is a type alias (when it's not a type parameter) => struct expressions and patterns should support Self.

Typical example:

impl MyStruct {
fn new() -> Self {
Self { a: 10, b: "Hello" }
}
}

The first commit does some preparations and cleanups, see the commit message for details.
This also fixes couple of bugs related to aliases in struct paths (fixes#36286).

EDIT:
Since struct expressions and patterns always work with ty::Ty now, associated paths in them are also supported. If associated type A::B successfully resolves to a struct (or union) type, then A::B { /* fields */ } is a valid expression/pattern. This will become more important when enum variants are treated as associated items.

r? @eddyb

eddyb

LGTM, certainly something I'd like to use myself.

cc @rust-lang/lang Any objections?

eddyb · 2016-10-08T00:34:09Z

Don't we have something like this already?

I'm not entirely sure, I've searched a bit, but found only type pretty printing (in the same ppaux.rs), but no short descriptions.

That's because it's hidden away in some error reporting logic.

petrochenkov · 2016-10-08T00:47:21Z

Oops, this is no longer necessary, need to remove.

Due to the "actual variant definition" vs "variant constructor" split?

No, due to tcx.parent_def_id(did) a few lines above.
Only type arguments are taken from the variant (from base_segments.last()), ast_path_to_ty works with the enum after that and returns enum's type, which cannot be a function.

Ericson2314 · 2016-10-08T15:36:38Z

Can we have a test to make sure this fails? I'd write it myself but not sure how.

structFoo<A>{inner:A};traitBar{fnbar();}implBarforFoo<i32>{fnbar(){Self{inner:1.5f32};}}

petrochenkov · 2016-10-08T16:01:34Z

@Ericson2314
Added the test.

Ericson2314 · 2016-10-08T17:07:49Z

Thanks!

nrc · 2016-10-08T20:37:43Z

This feels a little weird to me since Self is a fully instantiated type, but in patterns and struct initialisers, you can usually only supply a type constructor. So the semantics are kind of special when using Self in an impl where parameters are instantiated - I presume you are just using the name from Self, effectively? I guess we have the same problem when type aliases are partial instantiations? This feels worse on a theoretical level because we are admitting a different syntactic kind, but I suspect there may not be a practical difference.

petrochenkov · 2016-10-08T21:04:18Z

@nrc

in patterns and struct initialisers, you can usually only supply a type constructor.

I've heard something about this being true before 1.0, but now paths in struct expressions/patterns are types, possibly with provided type arguments, not just type constructors.

structS<T,U = u16>{a:T,b:U,}typeAlias<T> = S<T>;fnmain(){// Everything below is legallet s = S::<u8,u8>{a:0,b:1};// desugared into S::<u8, u8> { a: 0, b: 1 };let s = S::<u8>{a:0,b:1};// desugared into S::<u8, u16> { a: 0, b: 1 };let s = S{a:0,b:1};// desugared into S::<_, _> { a: 0, b: 1 };let s = Alias::<u16>{a:0,b:1};// desugared into S::<u16, u16> { a: 0, b: 1 };}

So, Self being already instantiated is not an exception.

nrc · 2016-10-09T19:40:25Z

@petrochenkov huh, ok, then I feel much better about this, thanks for the explanation!

Does this mean that if the type params or lifetime params of the values for fields disagree with the params of Self, then there will be an error? Could you add a test for that please?

petrochenkov · 2016-10-09T19:47:26Z

@nrc

Could you add a test for that please?

@Ericson2314 asked for the same test a few messages above and I added compile-fail/struct-path-self-type-mismatch.rs

Ericson2314 · 2016-10-10T00:10:57Z

@nrc not knowing that feature prior to this also led me to think of the test case. :)

nrc · 2016-10-11T00:32:36Z

@petrochenkov sweet, thanks!

aturon · 2016-10-11T16:26:59Z

What about the common case of constructors with generics?

structFoo<T>{ ... }impl<T>Foo<T>{fnnew<U>(u:U) -> Foo<U>{Self{ ...}// is this Foo<T> or Foo<U>?}}

aturon · 2016-10-11T16:27:26Z

I'm going to nominate for merging on @eddyb's behalf:

@rfcbot fcp merge

durka · 2016-10-11T17:37:39Z

@aturon I think you might need a T- label.

About fn new<U> -- how common is it really that Foo<T>::new doesn't return Foo<T>‽ Anyway, I would expect that code to fail with a type mismatch. Indeed it does (twice):

[root@li1424-173 rust]# build/x86_64-unknown-linux-gnu/stage1/bin/rustc - <<<"structFoo<T>{inner:T}impl<T>Foo<T>{fnnew<U>(u:U) -> Foo<U>{Self{inner: u }}}fnmain(){}" │··
error[E0308]: mismatched types │··
--> <anon>:1:87 │··
| │··
1 | struct Foo<T> { inner:T} impl<T> Foo<T> {fnnew<U>(u:U) -> Foo<U>{Self{inner: u }}}fnmain(){} │··
| ^ expected type parameter, found a different type parameter │··
| │··
= note: expected type `T` │··
= note: found type `U` │··
│··
error[E0308]: mismatched types │··
--> <anon>:1:73 │··
| │··
1 | struct Foo<T> { inner:T} impl<T> Foo<T> {fnnew<U>(u:U) -> Foo<U>{Self{inner: u }}}fnmain(){} │··
| ^^^^^^^^^^^^^^^^^ expected type parameter, found a different type parameter │··
| │··
= note: expected type `Foo<U>` │··
= note: found type `Foo<T>` │··
│··
error: aborting due to 2 previous errors

@petrochenkov can we get this to work for tuple structs as well?

[root@li1424-173 rust]# build/x86_64-unknown-linux-gnu/stage1/bin/rustc - <<<"structFoo<T>(T);impl<T>Foo<T>{fnnew<U>(u:U) -> Foo<U>{Self(u)}}fnmain(){}" │··
error[E0425]: unresolved name `Self` │··
--> <anon>:1:64 │··
| │··
1 | struct Foo<T>(T);impl<T>Foo<T>{fnnew<U>(u:U) -> Foo<U>{Self(u)}}fnmain(){} │··
| ^^^^ unresolved name │··
│··
error:aborting due to previous error

Note that Self { 0: u } does work.

aturon · 2016-10-11T17:41:22Z

Let's try that again, with a team:

@rfcbot fcp merge

eddyb · 2016-10-11T17:41:47Z

@durka Type aliases also don't work for tuple structs - but you can have a function with the same name.
Not sure if we should do something specific for Self in the value namespace, but it seems orthogonal.

durka · 2016-10-11T17:45:06Z

Oh, I didn't know that type aliases don't work for tuple structs. And you don't even get a warning, just an error when you try to use the alias. That's super weird, but yeah orthogonal to this PR.

rfcbot · 2016-10-11T18:00:27Z

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.

aturon · 2016-10-11T18:05:27Z

@durka

how common is it really that Foo<T>::new doesn't return Foo<T>

I feel like I've run into cases like this from time to time, though probably in all cases it suffices to make a separate impl block. The example I gave is not a realistic one; I'll try to dig up some real code.

In any case, I think the proposed behavior for this PR is fine there.

nrc · 2016-10-11T20:04:09Z

@aturon

What about the common case of constructors with generics?

AIUI, this is a case of the case I was asking about and your example should give a type error since Self is considered Foo<T>.

petrochenkov · 2016-10-11T20:55:31Z

Added this example #37035 (comment) to the tests.

rfcbot · 2016-10-13T18:59:45Z

All relevant subteam members have reviewed. No concerns remain.

rfcbot · 2016-10-20T18:59:47Z

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

nikomatsakis · 2016-10-21T21:04:23Z

OK, seems like we're all on board with letting this change go forward.

bors · 2016-10-27T04:51:53Z

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

Diagnostics for struct path resolution errors in resolve and typeck are unified. Self type is treated as a type alias in few places (not reachable yet). Unsafe cell is seen in constants even through type aliases. All checks for struct paths in typeck work on type level.

petrochenkov · 2016-10-27T20:17:20Z

@bors r=eddyb

bors · 2016-10-27T20:17:22Z

📌 Commit 8a38928 has been approved by eddyb

bors · 2016-10-28T01:18:57Z

⌛ Testing commit 8a38928 with merge 5530030...

@eddyb

Support `Self` in struct expressions and patterns Struct expressions and patterns generally support type aliases `Alias { field: 10 }` i.e. they already have to work with `ty::Ty` to do their job. `Self` is a type alias (when it's not a type parameter) => struct expressions and patterns should support `Self`. Typical example: ``` impl MyStruct { fn new() -> Self { Self { a: 10, b: "Hello" } } } ``` The first commit does some preparations and cleanups, see the commit message for details. This also fixes couple of bugs related to aliases in struct paths (fixes#36286). EDIT: Since struct expressions and patterns always work with `ty::Ty` now, associated paths in them are also supported. If associated type `A::B` successfully resolves to a struct (or union) type, then `A::B { /* fields */ }` is a valid expression/pattern. This will become more important when enum variants are treated as [associated items](#26264 (comment)). r? @eddyb

bors · 2016-10-28T05:02:29Z

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-cargotest, auto-linux-64-cross-freebsd, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-opt-rustbuild, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-opt, auto-mac-64-opt-rustbuild, auto-mac-cross-ios-opt, auto-win-gnu-32-opt, auto-win-gnu-32-opt-rustbuild, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-cargotest, auto-win-msvc-64-opt, auto-win-msvc-64-opt-rustbuild
Approved by: eddyb
Pushing 5530030 to master...

nikomatsakis · 2016-11-02T21:23:31Z

Discussing in the @rust-lang/core team meeting, we realized that this probably ought to have been feature-gated!

nikomatsakis · 2016-11-02T21:23:49Z

Even though it's small, it seems like feature-gating (and moving to stabilize in next cycle) would be more proper.

aturon · 2016-11-03T21:40:25Z

👍 for feature-gating.

@nikomatsakis

Feature gate Self and associated types in struct expressions and patterns cc rust-lang#37544Fixesrust-lang#37035 (comment) r? @nikomatsakis

rust-highfive assigned eddyb Oct 8, 2016

eddyb approved these changes Oct 8, 2016
View reviewed changes

petrochenkov commented Oct 8, 2016
View reviewed changes

durka mentioned this pull request Oct 8, 2016
Self alias as struct constructor rust-lang/rfcs#1588
Closed

petrochenkov force-pushed the selfstruct branch from b251cbb to 4f96b8aCompare October 8, 2016 12:17

petrochenkov force-pushed the selfstruct branch from 4f96b8a to 9d63af0Compare October 8, 2016 16:00

aturon added the T-lang Relevant to the language team label Oct 11, 2016

petrochenkov force-pushed the selfstruct branch from 9d63af0 to 077eed2Compare October 11, 2016 20:54

petrochenkov added 3 commits October 27, 2016 22:14

Support Self in struct expressions and patterns
eada951

Address comments + Fix rebase
8a38928

petrochenkov force-pushed the selfstruct branch from 077eed2 to 8a38928Compare October 27, 2016 20:16

bors merged commit 8a38928 into rust-lang:masterOct 28, 2016

bluss added the relnotes Marks issues that should be documented in the release notes of the next release. label Oct 28, 2016

nikomatsakis mentioned this pull request Nov 2, 2016
Support use *; and use ::*;. #37367
Merged

This was referenced Nov 3, 2016
Tracking issue for Self and associated types in struct expressions and patterns #37544
Closed
Feature gate Self and associated types in struct expressions and patterns #37547
Merged

petrochenkov mentioned this pull request Nov 12, 2016
Stabilize Self and associated types in struct expressions and patterns #37734
Closed

petrochenkov deleted the selfstruct branch March 16, 2017 19:40

petrochenkov mentioned this pull request Dec 4, 2020
Parsable associated enum constructor #79658
Closed

fmease mentioned this pull request Apr 4, 2026
Braced variant ctor gets rejected if enum has lifetime params & you pass gen args to enum explicitly #108224
Closed

Uh oh!

Uh oh!

Conversation

petrochenkov commented Oct 8, 2016• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

eddyb left a comment

Choose a reason for hiding this comment

Uh oh!

eddybOct 8, 2016

Choose a reason for hiding this comment

Uh oh!

petrochenkovOct 8, 2016

Choose a reason for hiding this comment

Uh oh!

eddybOct 8, 2016

Choose a reason for hiding this comment

Uh oh!

petrochenkovOct 8, 2016• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

eddybOct 8, 2016

Choose a reason for hiding this comment

Uh oh!

petrochenkovOct 8, 2016

Choose a reason for hiding this comment

Uh oh!

Ericson2314 commented Oct 8, 2016• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

petrochenkov commented Oct 8, 2016

Uh oh!

Ericson2314 commented Oct 8, 2016

Uh oh!

nrc commented Oct 8, 2016

Uh oh!

petrochenkov commented Oct 8, 2016• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nrc commented Oct 9, 2016

Uh oh!

petrochenkov commented Oct 9, 2016

Uh oh!

Ericson2314 commented Oct 10, 2016

Uh oh!

nrc commented Oct 11, 2016

Uh oh!

aturon commented Oct 11, 2016

Uh oh!

aturon commented Oct 11, 2016

Uh oh!

durka commented Oct 11, 2016

Uh oh!

aturon commented Oct 11, 2016

Uh oh!

eddyb commented Oct 11, 2016

Uh oh!

durka commented Oct 11, 2016

Uh oh!

rfcbot commented Oct 11, 2016• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

aturon commented Oct 11, 2016

Uh oh!

nrc commented Oct 11, 2016

Uh oh!

petrochenkov commented Oct 11, 2016

Uh oh!

rfcbot commented Oct 13, 2016

Uh oh!

rfcbot commented Oct 20, 2016

Uh oh!

nikomatsakis commented Oct 21, 2016

Uh oh!

bors commented Oct 27, 2016

Uh oh!

petrochenkov commented Oct 27, 2016

Uh oh!

bors commented Oct 27, 2016

petrochenkov commented Oct 8, 2016•
edited
Loading

petrochenkovOct 8, 2016•
edited
Loading

Ericson2314 commented Oct 8, 2016•
edited
Loading

petrochenkov commented Oct 8, 2016•
edited
Loading

rfcbot commented Oct 11, 2016•
edited
Loading