It's not as bad as with Java. For example there are nice structs, which Java doesn't have IIRC. But I don't like the casting required everywhere:
<snip>
So all these good Swift things kinda get in the way and I don't like how the code looks, either.
These are all signs that you are trying to bend the language to a particular way of doing things rather than actually doing things in the language. A couple things to point out in the code you wrote:
- Using C-style enumeration rather than the range enumerator, and not specifying a type for "i", which would help with the casting behavior. Swift defaults to the default int size of the platform if you don't.
- Using a buffer rather than just letting the array size itself appropriately to fit the content (pre-sizing is a minor optimization).
- Should be using Character or UnicodeScalar instead of UInt8. Swift doesn't assume that you are in ASCII-land, which is part of your trouble. Since you are writing code to fill a character buffer, but not actually using characters, but ASCII.
- Instead of enumerating the array, you create an unsafe pointer and do another C-style loop. This is the worst way to iterate through an array you already have.
- Why even use a buffer like this when a String can be sliced up and converted into the UnicodeScalars if you need the underlying value. You can also create slices of arrays if you want to only pass around a piece of an array (circular buffers for example).
- While UnicodeScalar and Character are somewhat incomplete if you need the ability to do math on the underlying value, you can always add them as operators to make the code doing the manipulation cleaner rather than keeping values that don't represent what you are actually working with.
For grins, I wrote up a version of the sample code you wrote using UnicodeScalar. Either way it is a bit contrived as the real solution will depend on how these things interact with the rest of the program. It also avoids extending array (which it should) for printing the hex values, which does require a few steps to get it right.
Code:
func +<T:UnsignedIntegerType>(lhs: UnicodeScalar, rhs: T) -> UnicodeScalar {
return UnicodeScalar(lhs.value + UInt32(rhs.toUIntMax()))
}
func printArrayAsHexValues(buffer: [UnicodeScalar]) {
for element in buffer {
print(String(format: "%@ = 0x%X", String(element), element.value))
}
}
var startChar = UnicodeScalar(65)
var characterBuffer:[UnicodeScalar] = []
for offset : UInt32 in 0...9 { // Range is inclusive
characterBuffer.append(startChar + offset)
}
printArrayAsHexValues(characterBuffer)
This code has the advantage of being easier to read, clearer behavior, and the customizations are actually reusable. Again, this isn't really code I'd actually write in Swift in practice, since I'd either be using an integer buffer for raw data (possibly an NSMutableData if on Apple platforms), and a string for a character buffer.
One of the other issues with Swift is that the standard library is woefully tiny. You basically have to marshal out to a framework, and AppKit/UIKit/GCD are first class citizens, while the POSIX APIs are very much not.
But the code you wrote suggests someone with a strong C background, possibly spending a lot of time in low level code, and not having spent much time with Obj-C, Python, C# or other modern languages used in app and tool development.
Honestly, swift is something you need to dig into, and unfortunately, if you are doing so off an Apple platform, the frameworks just aren't there to support a rich experience. And even if you are on an Apple platform, AppKit and UIKit prevent certain features of Swift from being used to their full potential because you can get more functional programming styles done in Swift, but then things like CoreData rip you back into the world of reference types of multi threading hell that results.
As for the comment of the GP that comments about efficient coding techniques, those are the same techniques that create crashes, security holes and other fun. All for the opportunity to maybe outsmart the compiler, when in many cases, bugs I've run into are because someone tried to outsmart the compiler, and got bit later because it forced the compiler into undefined parts of the C spec, or it actually prevented the optimizer from finding an even faster optimization because mucking with the pointers turned the whole process into something opaque.
