I am learning swift through Apple's documentation and I am on the Collection Types chapter and in the Sets section.
One of the examples is this
var letters = Set<Character>()
but when I go to enter that I get this following error.
error: use of unresolved identifier 'Set'
var letters = Set<Character>()
there was a revision on sets according to their documentation, but nothing is helping me there.
Native Set is available since Swift 1.2. Everthing points that you're using a lower version.
Swift 1.2 and Xcode 6.3 beta
New native Set data structure — An unordered collection of unique elements that bridges with NSSet and provides value semantics like Array and Dictionary.
Related
I've added Lucene.Net to a .Net 6 Core project and indexing docs with TextField, StringFiled, and Int32Field all work fine but FloatField doesn't seem to be supported. I'm using LuceneVersion.LUCENE_48. According to https://lucene.apache.org/core/4_1_0/core/org/apache/lucene/document/FloatField.html, FloatField has been available since version 4.1 of Java Lucene. What am I missing? Thanks
See the Lucene.NET 4.8.0 migration guide. Numeric types and method names including numeric types have been changed to use .NET conventions.
Instead of Float use Single. Note that Lucene.Net.Queries.Function.ValueSources.SingleFunction was renamed Lucene.Net.Queries.Function.ValueSources.SingularFunction to distinguish it from the System.Single data type.
So, FloatField has been renamed to SingleField.
I'm currently starting up work on a project, and my first task is decomposing a God Object that someone else created out of the AppDelegate. I've started by copying code related around managing location out, in the intention of delegating calls to that code into the new object.
I have two statements that are driving me nuts however.
New file:
if locationManager?.location?.horizontalAccuracy > horizontalAccuracyCheck{...}
Old file:
if locationManager?.location?.horizontalAccuracy > horizontalAccuracyCheck{...}
You'll notice the code is identical. In both cases self.locationManager? is defined as:
var locationManager: CLLocationManager?
But in the new file, I'm getting a warning about 'value of optional type no unwrapped' -- why? Exact duplicate code, copied & pasted, what would make this different?
Changing the code to unwrap it fixes things:
if (locationManager?.location?.horizontalAccuracy)! > horizontalAccuracyCheck{...}
I can wrap my head around why I need to explicitly unwrap a potentially optional return. But... why only in one place?
The reason is that we're talking here about two quite different languages. One file is Swift 2, the other file is Swift 3.
In Swift 2, you can compare an Optional representing a number with another number using the greater-than or less-than operator. In Swift 3, you can't do that.
Here's a simpler example of the same thing:
let optint : Int? = 7
let ok = optint < 42
That code is legal in Swift 2 but illegal in Swift 3.
As discussed in this Q&A – the Swift migrator will insert a custom fileprivate operator overload in order to allow for optional comparisons to work in Swift 3 the same way they did in Swift 2. Because this overload is fileprivate, you won't be able to use it from any other source files in your project that don't also define it, thus why your comparison fails to compile in the new source file.
Therefore one solution is just to copy it over to your new file. Another is to remove the fileprivate access modifer. The overload will default to internal, and therefore be accessible to other Swift files in your module.
Although really I would just recommend removing the overload entirely and instead write your own explicit logic for optional comparison when it arises – the overload can be too easily misused (as demonstrated by the Swift evolution proposal to remove it).
I've learned that swift actually creates a naming method called "mangling" used internally for all objects.
All threads talk about demangling, but how to actually get the mangled name?
i've tried
1- object_getClass(self)
2- NSStringFromClass(MyClass.self)
but they return the normal class name.
I've found this demangle project..
https://github.com/mattgallagher/CwlDemangle/blob/master/CwlDemangle/CwlDemangle.swift
is there a mangling project maybe?
Note: Im using swift 3.0.1
xcode ships with a command line tool to de-mangle names.
Type in:
swift demangle
Then find your mangled class name..
__TMaC17find_the_treasure15YD_Secret_Class
Then watch it spit out the name..
find_the_treasure.YD_Secret_Class
If you want to observe the mangled names, as you asked, you can put the produced Swift iOS or macOS binary into a dissassembler like Hopper, iDAPro or radare2.
The tools to automatically de-mangle names are already here (refer to Hopper v4.0 Dissassembler).
I'm using Appcode-EAP 3.2, but I've also tried this with Appcode 3.1.7.
When stopped in the debugger, I can see the local variables,
e.g.
fromJSON = []
self = []
However, if I move one of these to the Watches window to examine its contents, I get this:
self = Cannot evaluate expression for language Swift
I can't believe it isn't possible to see the values of a variable or property. Can anyone guide me as to what I'm failing to do?
Current AppCode versions (stable 3.1 and 3.2 EAP) don't support Swift debugging. It should be included into the final 3.2 release however: https://youtrack.jetbrains.com/issue/OC-11626
I'am testing the new Core Sportlight API feature in iOS 9. The indexing process works well but is there a way to define that the indexed Item should only get searched by the "title" Attribute instead of "title" and "description"?
Maybe you already have some more informations than me.
I have tried doing this using Objective C, and it works perfectly.
It depends on what implementation of "CSSearchableAttributeSet" is used.
In obj C, there are many implementations of CSSearchableAttributeSet like
CSSearchableItemAttributeSet_General
CSSearchableItemAttributeSet_Document
CSSearchableItemAttributeSet_Image
and others.
I have used CSSearchableItemAttributeSet_General in my code and I'm able to search by the title attribute only. In fact, that particular implementation of CSSearchableItemAttributeSet doesn't even have a "description" attribute.
So depending on what type of object you want to search for, you can use the particular implementation.
I believe it would be the same equivalent class in swift as well.
-Tejas