[swift-evolution] [Manifesto] Completing Generics

[Jonathan Tang]

Going through my code comments & notes now to see where the ideas here
could've helped avoid some nasty hacks.  I'll try to keep this mostly to
(missing) features I've found problematic but haven't seen mentioned here
and quick votes with comments that I think won't be responded to, and then
fork off deeper discussions into their own threads as suggested.

*Missing feature: How do protocols interact with the package system?*

Javascript had an unfortunate situation a couple years ago where there were
about a dozen competing Promise implementations.  The leading libraries all
got together and came up with the Promises/A+ spec.  Because Javascript is
dynamically typed, the spec mandates that anything with a then() method is
"Promise-like", and can be chained into existing promises.  As a result,
you can take a library that uses Bluebird promises, pass them to a library
that uses the es6-promise Polyfill, and then use the native implementation
of Promise.all and everything will just work.

Swift is not dynamically typed - to indicate a common set of functionality,
you need to define a protocol.  What happens when multiple frameworks
define a protocol that other frameworks wish to use?  I know of at least 3
different mutually-incompatible Promise implementations for Swift, but
assuming they managed to reconcile their differences and come up with a
common API - how would a library wanting to use this spec ensure that it's
compatible with other libraries using the spec?  If I include
promises.swift in my project which defines "public protocol Promise { ...
}", will the compiler know that it's the same protocol as the identical
promises.swift in AlamoFire or RethinkDB?  If not - how could it be
packaged up on its own so that everyone can be good citizens and
interoperate with each other?  Will app developers using these libraries
need to install a long chain of dependencies, or can they just get their
leaf dependencies and trust that everything will work together?  What
happens if there are versioning inconsistencies behind the protocols that
library dependencies use?

*Missing feature: "protocol can only be used as a generic constraint"*

This error message pops up whenever you try to use a protocol that has
associated types or Self (in a non-return position) as a type.  Instead of
being able to write "func doSomething(obj: MyProtocol)", you now have to
write "func doSomething<T: MyProtocol>(obj: T)", and you can forget about
being able to store objects of these protocols in data structures.  As I
understand it, this is because of conceptional confusion on the part of the
dev: when a protocol has associated types, it's no longer a *type*, but a *type
family*, and so it doesn't make sense to use it as you would a type.  The
compiler would have to enforce invariants that it doesn't have the
information to enforce.

That said, is there anyway to reduce the impact of this error message
(which, based on several Google searches and a bunch of encounters with it
myself, seems to happen quite frequently)?

In my experience, this error seems to pop up most often in two common
circumstances:

- Adopting Equatable or Hashable in a protocol

Solved by existentials - the usage of the protocol becomes an existential.
In particular, "opening existentials" is usually what you'd want to do for
==; I'm not really sure I like the syntax proposed here but this thread
isn't for bikeshedding. :-)

- Making a protocol inherit from a collection

Examples of this might include having a Message object behave like
[String:AnyObject], having an Amazon S3 interface behave like
[String:NSData], or having a File behave like [String] (like in Python).
Assume that concrete adopting classes cannot change the associated types.

The interesting thing about this case is that all of the associated types
are nailed down, and their usage can be limited to default method
implementations that don't vary between the concrete types adopting the
protocol.  So in such a File, the Generator implementation would always
delegate to self.readLine(), the SubSequence type is always [String], and
the only time these types are referenced is on default methods on File
which themselves delegate to the protocol methods witnessed by adopting
types.

IIUC, the compiler should have enough information available to generate all
code required by a File parameter, right?  It knows the associated types of
the collection, and it knows the methods that generate them.

Could this special case be fixed?

*Missing feature: How does toll-free bridging with Foundation interact with
protocol extensions?*

Last time I checked, an Array is-a NSArray and vice versa; they satisfy
is/as checks, they can be used interchangeably, and methods on one are
available on the other.  Except for with protocol extensions.  When you
extend Array to conform to a protocol, you don't automatically get NSArray
as well.  You have to explicitly define a conformance for NSArray as well,
which often has exactly the same code.

This is more a source of head-scratching & annoyance than a fundamental
limitation, since you can always duplicate the code and factor the logic
out to a common helper.  But it's one that's likely to be propagated
through the library ecosystem, as library authors who grow up on Swift
forget about NSArray/NSDictionary/etc. and then their code just doesn't
work for people switching over an Objective-C app.

On Wed, Mar 2, 2016 at 5:22 PM, Douglas Gregor via swift-evolution <
swift-evolution at swift.org> wrote:


> **Conditional conformances*
>
>
Big +1.  This is necessary for any sort of extensible tree structure.
Think about JSON serialization, for example: an array or dictionary is JSON
serializable only if all of its elements are JSON serializable, and the
algorithm used to serialize it depends on a call to serialize its members.
It comes up in many UI areas as well: a UI component might be Persistable
iff all of its subviews are Persistable.

The lack of this prevents app code from being able to easily extend
functionality provided in a library, eg. I may be able to easily come up
with a JSON serialization of a CLLocation or CNContact, but SwiftyJSON will
be unable to serialize an array of these objects using my mechanism.

*Concrete same-type requirements*
>
>
Big +1 on this as well.  It seems like it's pretty uncontroversial, but
this is widely applicable across a number of domains.  Basically any time
you need to operate on a generic collection with operations that only make
sense on a particular element type.

This would also increase the usefulness of "Generic typealiases" - the two
proposals together let you define new generic types just by adding
extensions to existing generic types.  Good way to prototype, and then if
the extension gets too complicated, you can always take what you've learned
and make a real type.



>
> *Parameterized extensions*
>
>
> **Arbitrary requirements in protocols*
>

These two both seem nifty, but I'm having trouble thinking of a concrete
use-case where they'd be critical.  The "arbitrary requirements in
protocols" in particular seems to be going down the path of "let's embed a
constraint solver in the Swift compiler", which seems like it'd lead to
some fun webpages a la type arithmetics
<http://okmij.org/ftp/Computation/type-arithmetics.html>, but not something
you'd want to see in your coworker's code.



> *Default generic arguments *
>
>
 Is it within Swift's scope to support compile-time polymorphism for high
performance computing?  This is a common technique in C++: you want a
generic algorithm that must be specialized in one or two places, but can't
afford the run-time overhead of dynamic dispatch.  So you create a template
parameter with a functor type.  STL allocators are a good example.

I don't personally do much HPC and dunno if it fits within Apple's vision
for Swift, but there are few other options if you do, and default generic
args make this tactic much more convenient.  Also fits well with "Named
generic parameters" and "Generic value parameters".  Might combine
awkwardly with "Variadic generics" and "Moving the where clause out of the
angle brackets" (would the default be specified inside the angle brackets
or outside?).


> **Allowing subclasses to override requirements satisfied by defaults*
>
>
>
Necessary for "Dynamic dispatch of protocol extensions" and "default
implementations in protocols" to make sense, right?  +1 to all three, it
seems like this is a cluster of related improvements that would make things
more uniform & understandable.


>
> *Variadic generics*
>
>
>
I'll fork off a thread on this...I've got some thoughts specifically
related to use with function types.


>
> **Default implementations in protocols*
>
>
>
+1.  It's cosmetic only, but the "use an extension to provide default
members of a protocol" idiom can be very confusing to newcomers.


> **Renaming “protocol<…>” to “Any<…>”.*
>
>
+1.  protocol<> always struck me as weird.  Any<...> is pretty similar to
equivalent concepts in other languages, like union types in Dylan.


> **Moving the where clause outside of the angle brackets*
>

-1.  Haskell does it this way (and pretty much has to because of MPTCs with
fundeps).  I found it was one of the hard parts of learning Haskell - I'm
used to thinking of a type as a unit.  Adding generics to that unit isn't
too hard to wrap my head around.  Adding constraints to those generics
isn't that hard, although at that point the type signatures are getting
really long.  (The proposals for "Generic typealiases" and "Typealiases in
protocols and protocol extensions" could help ameliorate this.  Is it
possible to typealias constraints as well?)  Wondering what the hell this
"where" clause is and how it relates to these generic things and why it's
at the end of the function signature can get pretty confusing.

Also, how does this interact with generic constraints on class/structs?
Would it go after the full struct definition, or just after the class name?



>
> *Dynamic dispatch for members of protocol extensions*
>
>
>
Static dispatch is very confusing here.  The whole point of protocols is to
get ad-hoc polymorphism, so when a protocol default message is called
instead of the overridden version just because of the static type signature
of the variable, it's likely to result in much head-scratching.



>
>
> *Potential removals*
>
> The generics system doesn’t seem like a good candidate for a reduction in
> scope; most of its features do get used fairly pervasively in the standard
> library, and few feel overly anachronistic. However...
>
> *Associated type inference*
>
>
The consequence of its removal is just that classes/structs that conform to
IteratorProtocol will now have to say "associatedtype Element = Int"?  I
don't view that as a major hurdle.  It's a bit of an annoyance, but if it
makes the typechecker significantly simpler and allows implementation of
some of the other ideas here, I think it's worth it.  It would be more
problematic if it required extra declarations at the call site; functions
are called orders of magnitude more times than classes & structs are
declared.


>
> *Existentials*
>
> Existentials aren’t really generics per se, but the two systems are
> closely intertwined due to their mutable dependence on protocols.
>
> **Generalized existentials*
>
> *Opening existentials*
>
>
>
+1 on both of these.  I remember writing a Haskell tutorial
<https://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_Hours> several
years ago, and it was amazing how quickly you needed existentials.  It's
not uncommon to want a heterogenous collection of objects that all
implement a single protocol; generics don't give you this.

There's an existing thread on this, so I'll send comments on the syntax &
usage of this over that way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160310/2ba81102/attachment.html>