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-6000] Let protocols inherit from class types #48557

Closed
swift-ci opened this issue Sep 26, 2017 · 3 comments
Closed

[SR-6000] Let protocols inherit from class types #48557

swift-ci opened this issue Sep 26, 2017 · 3 comments
Assignees
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-6000
Radar rdar://problem/34812895
Original Reporter mdmorris (JIRA User)
Type Bug
Status Resolved
Resolution Done
Environment

Swift 4.

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug
Assignee @slavapestov
Priority Medium

md5: b4794a58f4d0c7b151aaad9efd595e7a

is duplicated by:

  • SR-6001 Protocols inheriting from classes
  • SR-6006 Compiler abort trap
  • SR-6521 Compiler fails to see a custom initializer in a protocol
  • SR-7214 TYPE MISMATCH IN ARGUMENT 0 OF APPLY AT expression
  • SR-7452 Swift compiler segmentation fault
  • SR-7839 Protocol Restricting Class Inheritance Cannot Consistently Access Valid Instance Properties
  • SR-8031 Compiler crash in swift::irgen::emitImpliedWitnessTableRef
  • SR-8909 Crash accessing self from a extension
  • SR-6390 Let protocols inherit from class types
  • SR-7634 EXC_BAD_ACCESS when using a Protocol which has a Constraint on it's definition

Issue Description:

Swift can't decide whether a variable belonging to a class constrained protocol counts as a subtype of the constrained class and therefore has access to the members of that class. I would expect it to always have such access, but it's possible that it's not supposed to. Either way the compiler is being nutty here.

class Strawman {
    let name: String
    public func bar(_ x: Strawman) {
        print("\(name) bars \(x.name) from entering.")
    }
    public init(name: String) {
        self.name = name
    }
}

// A type must inherit from Strawman in order to implement
// Fooable, therefore all Fooable are a kind of Strawman.
// Q.E.D.
protocol Fooable where Self: Strawman {
    func foo()
}

class StrawFooable: Strawman, Fooable {
    public func foo() { print("Also Foo!") }
}

let sm1 = StrawFooable(name: "Strawman1")
let sm2 = StrawFooable(name: "Strawman2")

// This will not compile if you define doStuff as
// func doStuff(with x: Fooable, and y: Fooable) {
func doStuff<T: Fooable>(with x: T, and y: T) {
    x.bar(y)
    x.foo()
    y.bar(x)
    y.foo()
}

// This will not compile if you annotate sm1 and sm2 as Fooable.
doStuff(with: sm1, and: sm2)
@belkadan
Copy link
Contributor

The last part, "This will not compile if you annotate sm1 and sm2 as Fooable", is a well-known corner of the language: a protocol value doesn't necessarily provide a type for a generic parameter constrained by that protocol. (Note that sm1 and sm2 could have different dynamic types.)

However, actually using protocol-typed arguments probably ought to work. @slavapestov, @huonw?

@slavapestov
Copy link
Member

I think the problem here is the same as SR-6001, the declaration "protocol Fooable where Self: Strawman" is not fully supported.

@slavapestov
Copy link
Member

Done: #17851

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself
Projects
None yet
Development

No branches or pull requests

3 participants