[swift-evolution] Overloading Generic Types

Abe Schneider abe.schneider at gmail.com
Wed Feb 22 20:52:13 CST 2017

>> I'm starting to think my original motivation might’ve had something to do with normally needing storage for both some property and a T, but not needing (local) storage for said property if T conformed to a protocol which itself already required conforming types to have that property? Or maybe as a way to have the “bottom” variable in a hierarchy of wrapper types to break the “reference cycle” for some property? (Come to think of it, those could be the same thing)
>> That was (and is) an odd project... Anyway, it's been a while since I've thought about it. I'll try to find time today to poke through some old code and see if still have a copy of what I’d gotten stuck on.
>> And thanks for those links :-)

It sounds like what you want is similar to C++ template specialization (also something I’ve been asking for). Another slightly different form you can imagine it taking is:

class Array {
	associatedtype StorageType:Storage

	subscript(index:[Int]) -> StorageType.ElementType { /* … */ }

extension Array where StorageType:FloatStorage {
	// define specific variables for this specialization
	// and define behavior for subscript

Another example might be (if ints were allowed as generic parameters):

struct Factorial<N:Int> {
	var value { return N * Factorial <N-1>.value }

struct Factorial<N:Int> where N == 1 {
	var value { return 1 }

let value = Factorial<10>.value

The first example can in theory be done using runtime information (though as stated in my previous posts, I still can’t get it to work correctly in Swift). The second clearly needs to be done at compile time and could potentially benefit from the `constexpr` discussed in the `pure` function thread. A slightly different formulation could be:

constexpr factorial<N:Int>() { return N*factorial<N-1>() }
constexpr factorial<N:Int>() where N == 1 { return 1 }

Right now generics in Swift feel closer to Java’s generics than c++ templates. I think these types of constructs are extremely useful to a language and would disagree with anyone who says they aren’t needed (e.g. look at Boost and Eigen). However, I can also appreciate that adding these features to a language probably should be done with lots of care and thought.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170222/ea8c9316/attachment.html>

More information about the swift-evolution mailing list