jdfergason/swift-toml

Swift package for parsing TOML documents

swift-toml's Issues

Warning: Hashable.hashValue is deprecated as a protocol requirement

I'm getting this warning when checking this out via SwiftPM:

.build/checkouts/swift-toml/Sources/Toml/Path.swift:41:16: warning: 'Hashable.hashValue' is deprecated as a protocol requirement; conform type 'Path' to 'Hashable' by implementing 'hash(into:)' instead
    public var hashValue: Int {
               ^
.build/checkouts/swift-toml/Sources/Toml/Tokens.swift:37:9: warning: 'Hashable.hashValue' is deprecated as a protocol requirement; conform type 'Token' to 'Hashable' by implementing 'hash(into:)' instead
    var hashValue: Int {

[Swift 3.0.1 Preview 3] warning: expression implicitly coerced from 'Any?' to Any

Running swift build with Swift 3.0.1 Preview 3 emits the following warning:

/Users/emlai/Documents/Code/swift-toml/Sources/Parser.swift:133:25: warning: expression implicitly coerced from 'Any?' to Any
        toml.set(value: currToken.value, for: key)
                        ^~~~~~~~~~~~~~~
/Users/emlai/Documents/Code/swift-toml/Sources/Parser.swift:133:35: note: provide a default value to avoid this warning
        toml.set(value: currToken.value, for: key)
                        ~~~~~~~~~~^~~~~
                                        ?? <#default value#>
/Users/emlai/Documents/Code/swift-toml/Sources/Parser.swift:133:35: note: force-unwrap the value to avoid this warning
        toml.set(value: currToken.value, for: key)
                        ~~~~~~~~~~^~~~~
                                       !
/Users/emlai/Documents/Code/swift-toml/Sources/Parser.swift:133:35: note: explicitly cast to Any with 'as Any' to silence this warning
        toml.set(value: currToken.value, for: key)
                        ~~~~~~~~~~^~~~~
                                        as Any

hasTable() and hasKey() return false for inline tables

This seems to be a bug (tested in v0.3.0). I think both of them should return true.

Here's a commit that adds a test case which catches these: 7cfa946. Feel free to merge.

I'm not sure how to fix this though.

Add this project to cocoapods

It would be good to add this project to https://cocoapods.org

Empty array makes swift-toml trip up

example toml

foo = []
bar = true

full example

let toml = try! Toml(withString: """
foo = []
bar = true
""")
let array: [String]? = toml.array("foo")
print(array!)

Fatal error: 'try!' expression unexpectedly raised an error: Toml.TomlError.SyntaxError("bar = true") 

How to iterate through all tables?

I have a use case where I would need to loop over all root-level tables to check whether each table contains a certain key. Currently this doesn't seem to be possible.

I was previously using YamlSwift, where this was possible using the dictionary getter:

for (key, value) in yaml.dictionary! {
    if let property = value["property"] {
        // use `key` and `property`
    }
}

It would be nice to have something similar in swift-toml, for example:

for (tableName, table) in toml.tables {
    if let property = try? table.double("property") {
        // use `tableName` and `property`
    }
}

Change api to return optional values if keys do not exist

Currently Toml.value and variants throw an exception if a key does not exist. In practice this has created code that feels rather messy because simply grabbing a value requires a do { ... } catch { ... } block, a try! which is frowned upon, or propogating the error up with try and throws.

It would be more swifty to simply return an optional. If the key path requested does not exist then nil would be returned. Ie, Toml.value would become

 public func value<T>(_ path: String...) -> T?

And using the API would change from:

do {
    print(try toml.string("key", "path", "to", "value"))
} catch {
    // do something to handle the missing key
}

to:

if let val = toml.string("key", "path", "to", "value") {
   print(val)
}

Support TOML 0.5.0

@jdfergason Do you have any plans supporting TOML 0.5.0? According to the docs, it's considered very stable and should be mostly compatible with 1.0 – so it definitely is worth implementing.