[CodeCompletion] Don't provide 'init(nilLiteral:)' et al in optional context #23502
Conversation
rintaro
force-pushed
the
ide-completion-unresolvedoptional-rdar47806831
branch
from
9c1a986 to
10c83de
Compare
lib/IDE/CodeCompletion.cpp
Outdated
There was a problem hiding this comment.
Ah, you probably don't want to ignore all constructors. Someone could have added their own.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
force-pushed
the
ide-completion-unresolvedoptional-rdar47806831
branch
from
10c83de to
7e3a5dc
Compare
Okay
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. |
|
Hm, I was thinking mostly about expression context. But yes, |
with "TODO: ignore them in expression context". They are useful in pattern context, so we should provide them in completion.
|
Restored |
|
@swift-ci Please smoke test |
|
@swift-ci Please smoke test |
3 participants
For unresolved member completion, member decls in
Optionalreferenceable with implicit member expression are useless in most cases.init(_: <#Wrapped#>)init(nilLiteral: ())Instead, provide
nilkeyword 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