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-12296] Return protocols / opaque types as return / computed variables #54726

Open
swift-ci opened this issue Feb 28, 2020 · 3 comments
Open
Labels
compiler The Swift compiler in itself improvement opaque types Feature → types: opaque types type checker Area → compiler: Semantic analysis

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-12296
Radar rdar://problem/59976663
Original Reporter eebean2 (JIRA User)
Type Improvement

Attachment: Download

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Improvement, OpaqueResultTypes, TypeChecker
Assignee None
Priority Medium

md5: 4a2b82dc25f04c24f0e53bd7aa7ea45a

Issue Description:

Currently we can create protocols and opaque types and return objects using those types from computed variables and functions without a problem. Returning these types individually will provide API's and SDK's, as well as the default library new ways to expand.

Example:

public protocol A {}
public protocol B: A {}
public func returnA() -> some A {
    return B
}

Currently this errors with "Return type of global function 'returnA()' requires that 'B.Protocol' conform to 'A'". Allowing this would allow new advancements in generic programming, progression in rewriting the Swift language, and advances in the creation of new technology outside the Apple platform. An example would be Layout Constraints.

NSLayoutAnchor<AnchorType> : NSObject where AnchorType : AnyObject

The line of code above is a good example of where this change can be applied. Layout Constraints are fragmented at best. Rewriting them using this change would give a unified change and allow less strict "do not use" code for developers and more continuity.

See attached playground for the example above.

@CodaFi
Copy link
Member

CodaFi commented Feb 29, 2020

This doesn't typecheck as written - even barring language constraints. Are you asking for metatypes to be allowed in some-position?

@swift-ci
Copy link
Collaborator Author

Comment by Erik (JIRA)

@CodaFi Sorry for my bad explanation, but partially yes. Allowing the capability to return metatypes, and in addition, those that extend metatypes where applicable (such as the example I've included).

@hborla
Copy link
Member

hborla commented Mar 3, 2020

@swift-ci create

@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 improvement opaque types Feature → types: opaque types type checker Area → compiler: Semantic analysis
Projects
None yet
Development

No branches or pull requests

3 participants