Here’s an overview of @inline(__always):
- It is an annotation for the performance inliner, which only runs in -O
builds. The performance inliner uses heuristics to figure out what to inline,
so most of the time explicit annotations are not necessary, and sometimes it
won’t inline something
Not at all, thank you for trying it out.
When I run my code on the Mac in Xcode with thread sanitizer on, I don't
get any warnings or problems at all. I only find problems on Linux. I have
noticed that for the same release, the compiler and libraries are not
identical between Mac and Linux. I am
Any best practices for `@inline(__always)`? When it's short? When has very few
call sites? When the abstraction aids reading but hinders computation?
Thanks -- E
___
swift-users mailing list
swift-users@swift.org
I am sorry if this bothers you. I just put the original code in Xcode and
it works. Anyone knows why this works in Xcode or in macOS? I thought it
should show the same warnings as Linux.
Zhaoxin
On Fri, Mar 3, 2017 at 2:51 AM, Edward Connell via swift-users <
swift-users@swift.org> wrote:
> Hi
Yes, the easiest way is to rely on compiler magic for ObjC/C interoperability,
but it is also important to know what is really happening.
My preferred version of the compiler magic is this actually:
func allZerosUUID() -> String {
return NSUUID(uuidBytes: [UInt8](repeating: 0, count:
I agree that the use of `withUnsafeBufferPointer` to get to the contents of
an array makes more sense than `withUnsafePointer`, once you discover the
concept of a "buffer pointer" (which a new Swift programmer may not do at
first).
However, I note that the following code:
func allZerosUUID()
Hi Guillaume,
There is still a race condition report, but I think maybe we are almost
there. I had to modify your example because it didn't quite build, and a
loop to do it twice since it randomly complains if you only do it once.
Btw, this is on Linux.
The warning is triggered when deinitialize
Hi everyone,
It looks like I’m still having issues exposing a CustomNSError to Objective-C.
I am generating errors of this type in Swift and then trying to bridge them in
one direction over to Objective-C.
From Objective-C, this Error type is being exposed as a _SwiftValue.
Do I have to mark
