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

[SR-13770] Optional "?" sugar for nested types works within functions but not outside #56167

Open
swift-ci opened this issue Oct 23, 2020 · 4 comments
Labels
compiler The Swift compiler in itself parser Area → compiler: The legacy C++ parser

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-13770
Radar rdar://problem/70639080
Original Reporter BenLeggiero (JIRA User)
Type Sub-task
Environment
  • Apple Swift version 5.3 (swiftlang-1200.0.29.2 clang-1200.0.30.1)

  • Target: x86_64-apple-darwin19.6.0

  • macOS Catalina 10.15.7 (19H2)

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Sub-task, Parser
Assignee None
Priority Medium

md5: cf3d19a6bf0d324edf805a84dc3b622c

Parent-Task:

  • SR-14407 ☂️ Inconsistent behavior between sugared types and desugared types

Issue Description:

Within functions, the Optional "?" sugar for nested types (for example, Optional<String>.Publisher is the same as String?.Publisher) compiles and runs as intended within functions, but not outside them:

import Combine

func foo() {
    print(type(of: String?.Publisher.self)) // Compiles, runs, prints `Publisher.Type``
}
foo()

typealias Bar = Optional<String>.Publisher // Compiles

typealias Baz = String?.Publisher // Error: Consecutive statements on a line must be separated by ,

func hoge() -> String?.Publisher { // Error: Consecutive statements on a line must be separated by ,
    String?.none.publisher
}
@typesanitizer
Copy link

Potentially related and reduced:

extension Optional {
    typealias Cake = ()
}
typealias T = Int?.Cake // error: reference to member 'Cake' cannot be resolved without a contextual type
typealias S = Optional<Int>.Cake

@typesanitizer
Copy link

@swift-ci create

@CodaFi
Copy link
Member

CodaFi commented Oct 26, 2020

Seems like a common theme with type resolution and sugar

extension Array {
    typealias Cake = String
}

extension Dictionary {
    typealias Cake = String
}

typealias AT = [Int].Cake // error: reference to member 'Cake' cannot be resolved without a contextual type
typealias AC = Array<Int>.Cake

typealias DT = [Int: Int].Cake // error: reference to member 'Cake' cannot be resolved without a contextual type
typealias DC = Dictionary<Int, Int>.Cake

@rintaro
Copy link
Mannequin

rintaro mannequin commented Oct 27, 2020

According to https://docs.swift.org/swift-book/ReferenceManual/Types.html, this is "as designed" at this point.
Only type identifier can have member type syntax.

But it works in expression position:

extension Array {
  typealias Alias = Int
}
extension Optional {
  typealias Alias = Int
}

_ = [String].Alias()
_ = String?.Alias()

because they are modeled as explicit member expression

I'm not sure that fixing this requires language evolution process, but at least, the document should be updated.
Also, for implementing it we need to introduce something like `MemberTypeRepr` and obsolete `CompoundIdentTypeRepr`

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler The Swift compiler in itself parser Area → compiler: The legacy C++ parser
Projects
None yet
Development

No branches or pull requests

3 participants