[SR-1842] Introduce syntax for explicitly invoking extension methods. #44451

atrick · 2016-06-20T22:55:22Z


Previous ID	SR-1842
Radar	rdar://problem/26901464
Original Reporter	@atrick
Type	Bug

Additional Detail from JIRA


Votes	0
Component/s	Compiler
Labels	Bug
Assignee	None
Priority	Medium

md5: f177e287c5a900503259242832a8c778

relates to:

SR-117 Calling default implementation of protocols
SR-11183 There should be a way to disambiguate methods/properties/nested types with the same name in the same type defined in extensions in different modules

Issue Description:

There are two motivations for this:

1. Avoid future method name conflicts across modules. A helper extension within a user module might morph into a default implementation when the module defining the protocol is modified.

2. Introduce a declaration in the protocol implementation calls down to the original extension.

The first use case was a request from someone migrating to Swift. They were concerned about this case, and I didn't have a great answer:

// 3rd party module
protocol PP {
  func foo() -> Int
}

struct SS : PP {
  func foo() -> Int { return 3 }
}

func getPP() -> PP {
  return SS()
}

// User Module
extension PP {
  func bar() -> Int {
    return foo()
  }
}

print(getPP().bar())

Now, what if the 3rd party later does this:

protocol PP {
  func foo() -> Int
  func bar() -> Int
}

struct SS : PP {
  func foo() -> Int { return 3 }
  func bar() -> Int { return 33 }
}

That changes the behavior of the client code, and there's no way to prevent it.

<rdar://problem/26901464> Introduce syntax for explicitly invoking extension methods.

The second case relates to default protocol methods that we want to explicitly specialize. We need to provide a declaration of the protocol method inside of the concrete implementation. The problem is that there's no way for that implementation to override method and call the original implementation:

<rdar://problem/25495822> @_specialize that dispatches on associated types

The text was updated successfully, but these errors were encountered:

belkadan · 2016-06-21T00:37:09Z

This changes behavior on recompilation, yes.

This is all particularly interesting when library evolution is involved. In that case changes like this only happen with proper availability annotations, but on the flip side the "user code" can't just rename its entry point, because there may be existing clients depending on that.

What do you want to do if there are multiple possible extension methods? It seems like the same problem as picking a specific overload.

I'm not sure this is merely a syntactic problem.

atrick · 2016-06-21T00:56:13Z

As long as library evolution prevents the accidental promotion of a helper method to a default implementation, and fails to compile, that probably takes care of the serious concern. I wouldn't expect this to be a frequent problem.

The developer was looking for a way to namespace the extension by its module: "call extension foo() in module M" as a way to handle name conflicts. I don't know if that's a good idea.

For specialization, I am looking for a way to invoke the default protocol method from within an implementation that overrides the default. I'm not sure how generally useful that is though. It seems like a somewhat different problem.

belkadan · 2016-06-21T00:58:29Z

It doesn't prevent that promotion, and I'm not sure it should.

We need the module-based disambiguation anyway, just when you have two frameworks that extend the same (concrete) type. paulofaria (JIRA User) is working on a proposal for that.

swift-ci transferred this issue from apple/swift-issues Apr 25, 2022

AnthonyLatsis added feature A feature request or implementation swift evolution proposal needed Flag → feature: A feature that warrants a Swift evolution proposal and removed bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. labels Jul 27, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[SR-1842] Introduce syntax for explicitly invoking extension methods. #44451

[SR-1842] Introduce syntax for explicitly invoking extension methods. #44451

atrick commented Jun 20, 2016

belkadan commented Jun 21, 2016

atrick commented Jun 21, 2016

belkadan commented Jun 21, 2016

[SR-1842] Introduce syntax for explicitly invoking extension methods. #44451

[SR-1842] Introduce syntax for explicitly invoking extension methods. #44451

Comments

atrick commented Jun 20, 2016

belkadan commented Jun 21, 2016

atrick commented Jun 21, 2016

belkadan commented Jun 21, 2016