Sigh... I've hit this issue. Everything looked great on 64-bit targets, but then a quick check of 32-bit targets revealed the flaw.
My first workaround was to go down the conditional compilation path by using the "#if arch([...])" directive and writing specific code for 32-bit/64-bit. Of course, that works, but it just doesn't feel right, so I went with a casting solution instead.
Hopefully this will be ironed out in subsequent beta versions of Xcode, so that we can feel a little more confident about this issue in advance of the final production version of Xcode.
I don't suppose just this once that HotNewLanguage(TM) could come out with HN being flooded with "HotNewLanguage can access web pages! HotNewLanguage can now talk to MySQL! HotNewLanguage has an SQLite binding! HotNewLanguage has an MVC web framework! HotNewLanguage just got a binding to ImageMagick! HotNewLanguage now has a newer, hotter way of accessing web pages! HotNewLanguage has a binding to inotify!" for the next six months? I am willing to stipulate that Swift is a Turing-complete more-or-less general purpose programming language.
This rant would have been so much better if it somehow captured (or at least didn't clash with) the spirit of the link, which is certainly not a celebration (or even a mere observation) of how the language does scalar arithmetic.
Some developer decides to show a utility library they wrote for better interoperability between 32 and 64-bit numerical types to Hacker News and this is the reaction?
Right this very moment there's a REST library for Haskell on the front page, and Javascript libraries for various purposes show up on a semi-regular basis. Libraries, code, and frameworks for frivolous and serious purposes, for old and new languages alike, are constantly being posted to Hacker News. I honestly don't see how this is any different, except for this backlash to phantom hype which I find frankly quite puzzling.
9 comments
[ 1.8 ms ] story [ 31.8 ms ] threadMy first workaround was to go down the conditional compilation path by using the "#if arch([...])" directive and writing specific code for 32-bit/64-bit. Of course, that works, but it just doesn't feel right, so I went with a casting solution instead.
Hopefully this will be ironed out in subsequent beta versions of Xcode, so that we can feel a little more confident about this issue in advance of the final production version of Xcode.
At least the only casting you need to do is when doing
myDouble = myPoint.x // This works on 64 bit out of the box but not 32bit.
For now I try to avoid setting like that.
Everything else including myDouble += myPoint.x should work fine with the library.
Right this very moment there's a REST library for Haskell on the front page, and Javascript libraries for various purposes show up on a semi-regular basis. Libraries, code, and frameworks for frivolous and serious purposes, for old and new languages alike, are constantly being posted to Hacker News. I honestly don't see how this is any different, except for this backlash to phantom hype which I find frankly quite puzzling.
Also, I might have stolen your description as it is far better than mine :)
"better interoperability between 32 and 64-bit numerical types"