[Discussion] Allowing subclasses to override requirements satisfied by defaults

DevAndArtist · May 20, 2016, 4:47pm

Do we still get this in Swift 3?

apple/swift/blob/main/docs/GenericsManifesto.md#allowing-subclasses-to-override-requirements-satisfied-by-defaults-

(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/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

protocol P {}

extension P {
func foo() { print("P") }
}

class C : P {
// gets the protocol extension's
}

class D : C {
/*override not allowed!*/ func foo() { print("D") }
}

let p: P = D()
p.foo() // gotcha: prints "P" rather than "D"!

What will happen if I declare a final computed property or function inside the default implementation?

protocol P {}

extension P {
final func foo() { print("P") }
}

class C : P {
// gets the protocol extension's
}

class D : C {
/* can not override because of final */ override func foo() { print("D") }
}

let p: P = D()
p.foo() // prints "P"

···

--
Adrian Zubarev
Sent with Airmail