In javascriptcore optimization compiler codes, there are some operations which has prefix "phantom".
For example, PhantomNewArrayBuffer, PhantomNewObject, PhantomNewFunction, etc).
I don't know what this prefix means.
Can anybody explain what this prefix stand for?
Related
Just started learning Swift, am really confused about the following behaviour.
This is what I get when I run String.contains without Foundation:
"".contains("") // true
"a".contains("") // true
"a".contains("a") // true
"" == "" // true
And this is what I get with Foundation:
import Foundation
"".contains("") // false
"a".contains("") // false
"a".contains("a") // true
"" == "" // true
Why are the results different depending on whether I import Foundation? Are there other such differences, and is there an exhaustive list somewhere? Didn't find anything in the Foundation documentation, but this seems important to document. I'm only aware of this other example.
Also: How does this happen and is it normal? I understand that Swift has stuff like extensions that change the behaviour of every instance of something once they're included, but surely that should only add behaviour, not change existing behaviour. And if existing behaviour is changed, shouldn't the language indicate this somehow, like make me use a different type if I want the different behaviour?
Basically this is the same as the question I answer here.
Foundation is not part of Swift, it's part of Cocoa, the older Objective-C library that preceded Swift by many, many years. Foundation's version of a string is NSString. But Swift String is "bridged" to NSString, so as soon as you import Foundation, a bunch of NSString methods spring to life as if they were part of Swift String even though they are not. In your case, you actually end up calling a completely different method which, as you've discovered, gives different results.
A good way to see this is to command-click on the term contains in your code (or even better, option-click it and then click Open in Developer Documentation):
If you have not imported Foundation (or UIKit), you jump to Swift String's contains.
If you have imported Foundation, you jump to Foundation's contains.
As for this part:
shouldn't the language indicate this somehow
I'm afraid Stack Overflow is not very good on "should" questions. I would say, yes, this is a little maddening, but it's part of the price we pay for the easy and seamless integration of Swift into the world of Cocoa programming. You could argue that the Swift people should not have named their method contains, but that train has left the station, and besides, it's a name that perfectly indicates what the method does.
Another thing to keep in mind is that you would probably never really use Swift except in the presence of Foundation (perhaps because you're in the presence of UIKit or SwiftUI or AppKit) so in practical terms the issue wouldn't arise. You've hit an unusual edge-case, which is commendable but, ex hypothesi, unusual.
To make things even more complicated, I think the Swift library method you encountered may have been just introduced as part of Xcode 14 and Swift 5.7 etc. See https://developer.apple.com/videos/play/wwdc2022/110354/?time=1415 for the WWDC '22 discussion of new String features. In earlier versions of Xcode, the phrase "a".contains("") would not even have compiled in the absence of Foundation — and so the problem would never have arisen!
While experimenting with Swift I found a lot of useful methods and functions that are prefixed with underscores. For example, strings have a hidden _split() method. For some reason the functions _sin() and _cos() (but not _tan or _sqrt) are also available by default. In fact, the REPL actually suggests me to use these functions when I type sin(2.0). I’m not importing Foundation or anything that imports Foundation.
Why does the Swift offer these “hidden” functions, especially the trig functions which I would have expected to be part of a math module instead of builtins.
Things beginning with underscores are not for public consumption and only exposed publicly for internal reasons (e.g. for testing because the standard library can't use #testable).
By Dave Abrahams
Why in Swift can I type numbers without assigning them to var or let, and the code will compile fine? What is this good for?
import Foundation
55
25
23+8
print("Hello, World!")
4
11
-45
What is this good for?
It isn't good for anything, in the sense that it doesn't cause anything to happen with regard to the flow of the program. It's just something you're doing for fun, if you see what I mean. The numeric value is not being captured, so in effect it is immediately thrown away, like a virtual particle that flashes into existence one moment and back out of existence the next.
The reason it is legal is that a Swift statement is an evaluatable expression. A numeric literal is an evaluatable expression, so it's legal — though useless — as an independent statement.
You can see the same thing in many other ways. This is legal:
let n = 23
n
n is an evaluatable expression, so it's legal as a separate statement. But it is useless.
EDIT In answer to your comment below: I see no reason why a useless statement should prevent a program from compiling. But in a case like this, I would agree that it might be helpful if the compiler would warn that you're doing something useless, and in fact, for at least one case of this sort of thing, I have filed a bug report requesting this.
Swift is a language that has side effects, meaning that some operations can result in a mutation of the global state of the program. This has the implications that the compiler cannot simply eliminate a stand-alone statement without making extra sure that it can do so without affecting the execution of the program. Due to the complexity of state in a program, this is generally not a trivial problem, therefore in order not to penalize users who wish to invoke functions that have side effects, a line must be drawn; Swift has chosen to let users put any kind of stand-alone statement, even ones that are obviously free of side effects (constants or constant expressions), rather than spend a lot of effort trying to differentiate among various possibilities.
There could be a compile-time warning that shows lines of code that have no effect. I don't know much about Swift so I can't tell you, but if there is, you should be able to find it in the documentation.
It has to do with the fact that a number or an expression is a valid statement. So it can exist on its own. Some other languages have the same or similar feature.
Like in any language you can pronounce sentences of no interest... 55 is such a swift sentence. You may think it could be easy to eliminate unuseful sentences, but it is impossible, so why not just eliminate (at compile-time) the obvious ones? Because, in general people don't try to use them or just to exercise, and it will not worth the effort. It would be easy to forbid 55, but what about n=n? Easy? Or n=2*n-n(it is much more tricky because you would need to implement mathematical properties of expressions inside the compiler, and optimisation tricks for them).
I noticed that there are variables and functions used by many libraries that start with CF and ends with Ref, like: CFStringRef , CFURLRef , CFHTTPMessageCreateRequest , etc ...
1) what does CF stand for ? I don't know why apple does not say a word about such abbreviations.
2) what's the benefit(s) of using (for ex.) CFStringRef instead of using NSString ?
3) if it's better to use these CF variables, should I then replace all regular variable like NSString with CFStringRef ?
CF stands for Core Foundation. If you're interested in learning more about that, you can start by reading the Core Foundation Design Concepts Guide. There are also the String Programming Guide for Core Foundation and Collections Programming Topics for Core Foundation, which will tell you more about CFStringRef and the various collection types (arrays, dictionaries, and so forth).
Basically, Core Foundation is a relatively low-level framework that does some of the same things that Foundation does, but is written in C, and not Objective-C. Some Core Foundation "classes" (they're not really classes) are also "toll-free bridged" with their Objective-C counterparts, for example, it is possible to cast a CFStringRef to an NSString * (though it is a little more complicated with ARC).
If you don't need specific APIs that are only available in Core Foundation, there's absolutely no need to use it instead of Foundation. Core Foundation code tends to be less readable than Objective-C and also makes memory management a bit more complicated.
However, it can be quite useful to familiarize oneself with the basic concepts of Core Foundation, because there are still quite a few other frameworks that are built similarly. Core Text and Core Graphics are examples – while they don't formally belong to Core Foundation, they use the same naming and memory management conventions. There are also some APIs that are only available in Core Foundation and don't have Foundation counterparts – CFBagRef or CFBitVector (both collection types) would be examples.
From the Apple documentation:
Core Foundation is a library with a set of programming interfaces conceptually derived from the Objective-C-based Foundation framework but implemented in the C language. To do this, Core Foundation implements a limited object model in C. Core Foundation defines opaque types that encapsulate data and functions, hereafter referred to as “objects.”
This is essentially sums up the difference. Core Foundation (CF) provides pure C implementations of many of the Objective-C implementations that come with the language in the form of the Foundation framework. It is correct that NS stands for 'NeXTSTEP', the name of the operating system that formed the absis for much of Mac OS X, but it also indicates that a type is an Objective C class. CF types are pure C implementations and come with C functions to manipulate them.
There are occasionally times that using the CF structures brings an advantage over the NS equivalent. For example, CFDictionary places fewer restrictions on values and keys than does NSDictionary. But unless any such problem comes up there isn't a reason for you to change your references to their CF equivalents. ARC will also not work as easily with CF types.
It is also possible to map between CF and Foundation using toll-free bridging.
Objective-C is built on the c language, the CF (Core Foundation) types are C structs, and are usually wrapped in an Objective-C object (CFStringRef is wrapped by NSString, CGImageRef is wrapped by UIImage etc)
Unless you have a good reason, use the Objective-C level code. The memory management is much simpler (automatic for ARC), and in general your code will be much cleaner
Edit: as #omz pointed out, wrapped is incorrect for NSString, it is bridged, some of the other answers explain this concept
on iPhone/ARM, which CPU registers are functions supposed to preserve, if any?
Old, but incorrect answer. Wikipedia is often inaccurate (sometimes downright incorrect), and this is an example of the former case. There is a generic calling convention (which is what Wikipedia documents), but OSes can deviate - both Android and iOS do (and likely Win 8 will, but we'll know that when the binaries start surfacing)
http://developer.apple.com/library/ios/#documentation/Xcode/Conceptual/iPhoneOSABIReference/Introduction/Introduction.html
provides the correct spec for iOS, so no sense in repeating here. Most notably, note the use of r7 and r12. Also note that ARMv6 and ARMv7 are different. By now, you want ARMv7 architectures (A4,5,6..)
Wikipedia's article on Calling Convention has a good summary of the conventions for ARM.