SE-0287: Extend implicit member syntax to cover chains of member references

[Jumhyn (Frederick Kellison-Linn)]

Yes, the toolchain on the PR should be fully-functional aside from an issue with code completion that still needs to be ironed out.

ETA: link (macOS)

[rumnat (Muratov Anton)]

Feels naturally and as an extension that was supposed to be from the very beginning.
+1

[filip-sakel]

I don’t have anything to comment on.

Great work! +1

[blangmuir (Ben Langmuir)]

@Jumhyn

By "base type of the implicit member expression" I was referring to the implicit base of the expression, i.e., the type that would have been written before the leading dot if we weren't allowed to omit it. In your example, Foo is the "base type of the implicit member expression". Do you have a suggestion for wording that would make this clearer?

Got it. I'm not sure if it's worth changing, but the first bit of the detailed design seems like a much clearer explanation of this.

@Jumhyn

There's no proposed changes to code completion here, so code completion for the implicit member expression should continue to offer only the options which match the contextual type with later members in the chain offering the full list of matches.

The general rule for code-completion is that we offer anything that is legal in the language, so I would expect code-completion to offer the members with other types that are now legal (but with lower priority compared to the ones matching the type). If we continued to constrain completion to only members matching the context type, it makes it hard for developers to use this new feature for heterogenously typed chains. E.g. if each of these has a different type, there would be no way to complete anything except the very last member

let _: D = .a.b.c.d

If we could restrict code-completion to only members for which there is a path to get to the context type (e.g. only show members of type T if T itself has members that can transitively reach the context type C), that would be better, but the extra cost of the analysis may be too high for code-completion.

[Jumhyn (Frederick Kellison-Linn)]

@blangmuir

The general rule for code-completion is that we offer anything that is legal in the language, so I would expect code-completion to offer the members with other types that are now legal (but with lower priority compared to the ones matching the type).

That makes sense—I'll look into updating the code completion according to this behavior.

@blangmuir

E.g. if each of these has a different type, there would be no way to complete anything except the very last member

The behavior of the current implementation is marginally better than this—we don't offer the completion a, but b, c, and d all get offered and the respectively appropriate spots. It's just implicit member expressions that are artificially restricted to offer only options matching the contextual type. But after playing around with the completion I agree it's annoying to not get the completions for non-matching members offered when you're trying to start a heterogeneously-type chain.

[Nathan_Gray]

@Douglas_Gregor

• What is your evaluation of the proposal?

Strongly in favor of the proposal as written.

• Is the problem being addressed significant enough to warrant a change to Swift?

Yes

• Does this proposal fit well with the feel and direction of Swift?

Yes, I’m surprised it doesn’t already work that way.

• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A quick read. It’s not complicated.

[cprovatas (Charlton Provatas)]

+1 Would love to see this!

[Zollerboy1 (Josef Zoller)]

+1 for this feature. Fits the feeling of Swift very well and is a no-brainer in my opinion.

[James_Dempsey]

• What is your evaluation of the proposal?
  Strong +1. I've encountered the limitation the proposal addresses in the past and this will improve the ergonomics of using implicit members in a very natural way.

• Is the problem being addressed significant enough to warrant a change to Swift?
  Yes, although I see this less as fixing a problem and more as improving the expressiveness of the language.

• Does this proposal fit well with the feel and direction of Swift?
  Yes. It works as I would expect in Swift, it feels like a natural extension.

• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  n/a

• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
  I read the proposal twice, and read through the existing comments.

[Douglas_Gregor]

This proposal has been accepted, thank you everyone!

Doug