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](http://qiita.com/codelynx/items/c56f06a4ff097dfca5de) 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.

```swift
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.

```objc
@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.

```swift
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.

```swift
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.

```swift
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.

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

I prefer this way.

```swift
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. ;-)

```swift
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.

```swift
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.

```swift
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](#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
```