My Swift 3.0 Wish List

As some of them may know, Apple is moving toward Swift 3.0 already. Here are some of the voices from developers.

A Wishlist for Swift 3.0

https://realm.io/news/swift-3-wishlist/

I am wondering what would be the wish list for me for the future version of Swift programming language. I start taking a note from a couple of weeks ago while I am coding Swift. Then here is the list so far.

• [Failable initializer for classes](# Failable initializer for classes)
• [Declaring variable of a class and/or struct that conforms to given protocol](## Declaring variable of a class and/or struct that conforms to given protocol
  )
• [Swift native archiving method](# Swift native archiving method)
• [String](# String)
• [Function and Parameter naming](# Function and Parameter naming)
• [@synchronized equivalent support](# @synchronized equivalent support)
• [NSDecimal, NSData equivalent Swift native type](# NSDecimal, NSData equivalent Swift native type)
• [Fixed size array](# Fixed size array)
• [Keep ++, -- operator](# Keep ++, -- operator)
• [unused keyword](# unused keyword)
• [Do not change syntax too much](# Do not change syntax too much)

Failable initializer for classes

I wrote about this at here already. Swift allows to return nil with remaining uninitialized member items for structs, on the other hand, Swift does not allow classes to return nil unless all members are initialized properly.

.swift

struct Animal {
    let species: String
    init?(species: String) {
        if species.isEmpty { return nil } // OK
        self.species = species
    }
}

.swift

class Animal {
    let species: String
    init?(species: String) {
        if species.isEmpty { return nil } // error: oh, please!?
        self.species = species
    }
}

I wish Swift should be a bit more flexible on this issue. Also throwable initializer also can be a bit more flexible as well. There may be an idea that caller should take care of parameters, but I believe classes also have some rights to refuse bad parameters for initialization.

enum AnimalError: ErrorType {
	case SomeError
}

class Animal {
	let species: String
	init(species: String) throws {
		if species.isEmpty { throw AnimalError.SomeError } // error: hey! come on!?
		self.species = species
	}
}

Declaring variable of a class and/or struct that conforms to given protocol

For example, if you like to have an object in your view controller that conforms to a given protocol of a given type.

@protocol MyProtocl <NSObject>
- (void)doSomething;
@end

@interface ViewController : UIViewController {
	UIViewController<MyProtocl> *myProtocolAwareViewController;
}
@end

If you try coding something similar, you will figured out that you can't do that. Then you declared either protocol or class to declare a variable and cast them when you needed.

protocol MyProtocol {
	func doSomething()
}

class MyViewController: UIViewController {
	var myProtocolAwareViewController: UIViewController<MyProtocol>! // error
}

I am not sure that what would be my preferred syntax, but I wish future version of Swift support variables or parameter declaration of a type that conforms to specified protocols.

Swift native archiving method

Native Swift data types such as classes, structs and enums are not really get along with NSCoding. Only NSObject descendant are qualified to be archived by NSCoding mechanism, and other classes and structs need to find some other ways.

I wish future version of Swift to have nice mechanism to serialize or deserialize Swift class objects, structs and enums.

String

There are some methods available on NSString but not on String, such as stringByDeletingLastPathComponent and other path related methods. It is such trivial thing but a bit pain once little while. I wrote some String extension for myself to reuse it for every project. I wish future version of Swift supports file path related methods as a part of String type.

extension String {

	func stringByAppendingPathExtension(str: String) -> String? {
		return (self as NSString).stringByAppendingPathExtension(str)
	}
	
	func stringByAppendingPathComponent(str: String) -> String {
		return (self as NSString).stringByAppendingPathComponent(str)
	}
	
	var stringByDeletingPathExtension: String {
		return (self as NSString).stringByDeletingPathExtension
	}

	var stringByDeletingLastPathComponent: String {
		return (self as NSString).stringByDeletingLastPathComponent
	}

	var lastPathComponent: String {
		return (self as NSString).lastPathComponent
	}

	var pathExtension: String {
		return (self as NSString).pathExtension
	}

	var pathComponents: [String] {
		return (self as NSString).pathComponents
	}
}

Function and Parameter naming

One of the disappointing function naming in Swift is writing a code like this. X become part of method name and y is part of parameter name.

func moveToX(x: Float, y: Float) { }
moveToX(10.0, y: 20.0)

You may write a code this way. But I am still not happy with x x part.

func moveTo(x x: Float, y: Float) { }
moveTo(x: 10.0, y: 20.0)

I prefer this way.

func moveTo(x: Float, y: Float) { }  // I wish
moveTo(x: 10.0, y: 20.0)

@synchronized equivalent support

Functional programming is great. But we still cannot abandon Object Oriented Programming model. Also caching and other down to earth technique is needed for real life. I believe @synchronized in Objective-C is one of them. We still have some cases where some properties should be protected from multiple threads, and NSLock is okay, but I prefer @synchronized. I wish future version of Swift support @synchronized equivalent feature.

NSDecimal, NSData equivalent Swift native type

I wish future version of Swift supports NSDecimal and NSData equivalent native type. BTW, I do not take following code, thanks. ;-)

typealias Data = [UInt8]

Fixed size array

Programming language "C" provides fixed size array. Swift provides Array but it's not a fixed size. Tuple can be equivalent to fixed size array, but if its number of elements gets longer and longer, it is harder and harder to read code and maintain.

typealias Bytes8 = (UInt8, UInt8, UInt8, UInt8,  UInt8, UInt8, UInt8, UInt8)
typealias Bytes16 = (
		UInt8, UInt8, UInt8, UInt8,  UInt8, UInt8, UInt8, UInt8,
		UInt8, UInt8, UInt8, UInt8,  UInt8, UInt8, UInt8, UInt8)
typealias Bytes32 = (
		UInt8, UInt8, UInt8, UInt8,  UInt8, UInt8, UInt8, UInt8,
		UInt8, UInt8, UInt8, UInt8,  UInt8, UInt8, UInt8, UInt8,
		UInt8, UInt8, UInt8, UInt8,  UInt8, UInt8, UInt8, UInt8,
		UInt8, UInt8, UInt8, UInt8,  UInt8, UInt8, UInt8, UInt8)

struct MyFileHeader {
	var signature: Bytes8
	var reserved: Bytes8
	var info: Bytes16 // uuid
	var hash: Bytes32 // sha-256
}

Keep ++, -- operator

I personally don't like ++, -- so much, because it could be tricky time to time. Following code is so confusing and difficult to predict its result in a second. But majority of cases are not so bad, I guess. I wish future version of Swift not to change increment and decrement operators and stay on backward compatibility table.

func printX(a a: Int, b: Int, c: Int, d: Int, e: Int) {
		print("a=\(a), b=\(b), c=\(c), d=\(d), e=\(e)")
}

var x = 5
printX(a: x, b: --x, c: x++, d: x--, e: x)

See Result

unused keyword

Xcode suggest renaming unused variable to _. That's okay, if compiler like to use this for some optimization. But there are some cases, where I like to use those variables to remember what was the value is about. The variable name can be a comment. Or, if you decided to use that variable later on, you may have to search once again to find out what could be the appropriate variable name represented by _.

Do not change syntax too much

If there are significant syntax changes, many of your swift base source code also get pretty large impact. However, some Swift features like defer sentence may not require many changes in Swift. Unless it very important feature enhancement or productivity, I wish future Swift to be stay on right track not requires engineers to make many changes for just for fixing syntax error. Oh, by the way, I don't trust such Auto Fix kind of tricks.

Conclusions

Those list may give you an impression that I am complaining to Swift language. No at all period. I enjoy coding Swift very much day to day, and still finding new code styles, tricks and idioms, and it's fun to do.

Result

a=5, b=4, c=4, d=5, e=4