Skip to content

[CodeCompletion] Don't provide 'init(nilLiteral:)' et al in optional context #23502

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

Conversation

rintaro
Copy link
Member

@rintaro rintaro commented Mar 22, 2019

For unresolved member completion, member decls in Optional referenceable with implicit member expression are useless in most cases.

  • init(_: <#Wrapped#>)
  • init(nilLiteral: ())
    Instead, provide nil keyword with erasing . instruction.

As for .some(<#Wrapped#>) and .none, although they aren't useful in expression context, it's common to use them in pattern context. So don't hide them until we implement a mechanism to distinguish them.

rdar://problem/47806831

@rintaro rintaro requested a review from benlangmuir March 22, 2019 22:05
@rintaro rintaro force-pushed the ide-completion-unresolvedoptional-rdar47806831 branch from 9c1a986 to 10c83de Compare March 22, 2019 22:11
// '.some(<some>)' and '.none'. They are useless in most cases.
if (T->getOptionalObjectType() &&
VD->getModuleContext()->isStdlibModule() &&
(isa<EnumElementDecl>(VD) || isa<ConstructorDecl>(VD))) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, you probably don't want to ignore all constructors. Someone could have added their own.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think checking VD->getModuleContext()->isStdlibModule() is enough to limit them to init(nilLiteral: ()) and init(<#Wrapped#>). Added test case for that.
Is there any cases which hide user own initializers?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That should be good!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OTOH, maybe we should "just" have a hideFromCodeCompletion attribute…

…context

For unresolved member completion, member decls in `Optional`
referenceable by implicit member expression are useless in most cases.
- `init(_: <#Wrapped#>)`
- `init(nilLiteral: ())`
- `.some(<#Wrapped#>)`
- `.none`

Instead, provide `nil` with erasing `.` instruction.

rdar://problem/47806831
@rintaro rintaro force-pushed the ide-completion-unresolvedoptional-rdar47806831 branch from 10c83de to 7e3a5dc Compare March 22, 2019 22:21
@benlangmuir
Copy link
Contributor

init(_: <#Wrapped#>)
init(nilLiteral: ())

Okay

.some(<#Wrapped#>)
.none

What's the justification for hiding these? I've seen code that uses this style, particularly in switch cases. It's more discoverable than "?" in a pattern binding. Users from other languages with Optional may also be used to writing things this way.

@rintaro
Copy link
Member Author

rintaro commented Mar 22, 2019

Hm, I was thinking mostly about expression context. But yes, .some()/.none is commonly used in matching pattern and I agree we should not hide them in pattern context.
I think, eventually, we should distinguish between pattern and expression context.

with "TODO: ignore them in expression context".
They are useful in pattern context, so we should provide them in
completion.
@rintaro
Copy link
Member Author

rintaro commented Mar 25, 2019

Restored .some and .none for now with TODO note.

@rintaro
Copy link
Member Author

rintaro commented Mar 25, 2019

@swift-ci Please smoke test

@rintaro
Copy link
Member Author

rintaro commented Mar 26, 2019

@swift-ci Please smoke test

@rintaro rintaro merged commit 42d3643 into swiftlang:master Mar 26, 2019
@rintaro rintaro deleted the ide-completion-unresolvedoptional-rdar47806831 branch March 26, 2019 18:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants