Retroactive protocol inheritance

Nevin · 2017-09-22T20:53:32.000Z

With Swift 4 out, I’ve started using the numeric protocols quite a bit, and
they are great!

One thing I find myself wishing for is a protocol that extends Numeric
while also allowing division—a Field protocol, if you will. I have
implemented several algorithms generically over FloatingPoint because they
need division, which means they aren’t available for, eg., a Rational type.

Absent a Field protocol in the standard library, I can create one of my own:

protocol Field: Numeric {
static func / (lhs: Self, rhs: Self) -> Self
}

And I can extend Float and Double and Float80 to conform easily enough.
However, I’d really like to write,

extension FloatingPoint: Field {}

and make every type which conforms to FloatingPoint (such as a third-party
Complex type), also conform to Field.

Is this potentially feasible? Would other people find it useful?

Nevin

allevato · 2017-09-22T21:06:43.000Z

This is mentioned in the Generics Manifesto as "Conditional Conformances
via Protocol Extensions": <

github.com

apple/swift/blob/main/docs/GenericsManifesto.md#conditional-conformances-via-protocol-extensions

(Source: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011666.html, authored by Douglas Gregor)

## Introduction

The "Complete Generics" goal for Swift 3 has been fairly ill-defined thus far, with just this short blurb in the list of goals:

> *Complete generics*: Generics are used pervasively in a number of Swift libraries, especially the standard library. However, there are a number of generics features the standard library requires to fully realize its vision, including recursive protocol constraints, the ability to make a constrained extension conform to a new protocol (i.e., an array of Equatable elements is Equatable), and so on. Swift 3.0 should provide those generics features needed by the standard library, because they affect the standard library's ABI.

This message expands upon the notion of "completing generics". It is not a plan for Swift 3, nor an official core team communication, but it collects the results of numerous discussions among the core team and Swift developers, both of the compiler and the standard library. I hope to achieve several things:

* **Communicate a vision for Swift generics**, building on the [original generics design document](https://github.com/apple/swift/blob/main/docs/archive/Generics.rst), so we have something concrete and comprehensive to discuss.

* **Establish some terminology** that the Swift developers have been using for these features, so our discussions can be more productive ("oh, you're proposing what we refer to as 'conditional conformances'; go look over at this thread").

* **Engage more of the community in discussions** of specific generics features, so we can coalesce around designs for public review. And maybe even get some of them implemented.

A message like this can easily turn into a [centithread](http://www.urbandictionary.com/define.php?term=centithread). To separate concerns in our discussion, I ask that replies to this specific thread be limited to discussions of the vision as a whole: how the pieces fit together, what pieces are missing, whether this is the right long-term vision for Swift, and so on. For discussions of specific language features, e.g., to work out the syntax and semantics of conditional conformances or discuss the implementation in compiler or use in the standard library, please start a new thread based on the feature names I'm using.

This message covers a lot of ground; I've attempted a rough categorization of the various features, and kept the descriptions brief to limit the overall length. Most of these aren't my ideas, and any syntax I'm providing is simply a way to express these ideas in code and is subject to change. Not all of these features will happen, either soon or ever, but they are intended to be a fairly complete whole that should mesh together. I've put a * next to features that I think are important in the nearer term vs. being interesting "some day". Mostly, the *'s reflect features that will have a significant impact on the Swift standard library's design and implementation.

This file has been truncated. show original

While it would be a very powerful and useful feature, it's apparently also
very difficult unfortunately :( One of the biggest issues with
implementing it would be the effects that is has on dynamic type checking
for protocols, and there's a good discussion about it on the list that's
better than anything I could write: <
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160905/027032.html

···

On Fri, Sep 22, 2017 at 1:53 PM Nevin Brackett-Rozinsky via swift-evolution <swift-evolution@swift.org> wrote:

With Swift 4 out, I’ve started using the numeric protocols quite a bit,
and they are great!

One thing I find myself wishing for is a protocol that extends Numeric
while also allowing division—a Field protocol, if you will. I have
implemented several algorithms generically over FloatingPoint because they
need division, which means they aren’t available for, eg., a Rational type.

Absent a Field protocol in the standard library, I can create one of my
own:

protocol Field: Numeric {
static func / (lhs: Self, rhs: Self) -> Self
}

And I can extend Float and Double and Float80 to conform easily enough.
However, I’d really like to write,

extension FloatingPoint: Field {}

and make every type which conforms to FloatingPoint (such as a third-party
Complex type), also conform to Field.

Is this potentially feasible? Would other people find it useful?

Nevin
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution