[swift-evolution] No disjunctions in type constraints: why?

Saagar Jha saagar at saagarjha.com
Sat Jan 13 14:37:47 CST 2018

The “Swifty” way of doing such a thing is to have the types you care about conform to a protocol that clearly defines the API you’re trying to expose. For example:

protocol Fooable {
	func doFoo()

extension Int: Fooable {
	func doFoo() {
		print("I’m an Int")

extension String: Fooable {
	func doFoo() {
		print("I’m a String")

Now, instead of a disjunctive Int | String union type you can just use Fooable and call doFoo on it when necessary:

func doSomethingWithAFooable(_ foo: Fooable) {

doSomethingWithAFooable(0) // prints: I’m an Int
doSomethingWithAFooable("") // prints: I’m a String

Saagar Jha

> On Jan 13, 2018, at 01:45, Daryle Walker via swift-evolution <swift-evolution at swift.org> wrote:
> From <https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md#miscellaneous <https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md#miscellaneous>>.
> Maybe I’m not up on my Type Theory, but why should type constraint disjunctions be banned?
>> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT com 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

More information about the swift-evolution mailing list