I'm strongly in favor if this, I think it's a great addition.

What would you say to removing "required" from the method names? It would fit with the existing SwiftyJSON naming conventions. Also, I think the type signature (func string() throws -> String) implies that the property would be required.

I would love to use this!

@jkubicek I think this is confusing since we already have string property.

I think it's better to use therawString,rawArray series API instead of thestringValue,arrayValue API to implement these methods. And I wishrequiredDictionaryObject which returns[String: AnyObject] andrequiredArrayObject which returns[AnyObject] are added too.

AndrequiredBool is a must, since boolean type is different type from number type.

Looks interesting, can you kindly add a bit of test and update the syntax to swift3.
Would love to ship this.

Also, sorry for not getting to this sooner.

@zhigang1992 Looking at the code, it seems that we're gonna end up with a confusing API. For instance, to unpack a string you have

• json.string -> String?
• json.stringValue -> String with a fallback on"" if not found, potentially error prone
• json.requiredString throws -> String which throws if the value is incorrect.

I would argue that we should be as strict as possible and leave the responsibility on the user to fallback on whatever is best if the value cannot be unpacked. This is why I'm proposing this unique interface:

• json.string() throws -> String

It covers all the cases above:

• try? json.string()
• try? json.string() ?? ""
• try json.string()

It also has the value to provide an explicit error if the unpack fail, as opposed to returningnil or a "fake" value. Imho it'll lead to more robustness in codebases.

However it does introduce a code-breaking change, probably worth a SwiftyJSON v4 or something. What do you think?

@ldiqual This change is huge, but the benefit is not that much. I don't think the try syntax is very beginner friendly or easy to use.

I must admit I all but forgot about this pull request.

Although there could still be uses of this type of functionality in SwiftyJSON, my specific use case was abusing the library. As such, I built a component in myBetterLibrary that is better designed for my purpose. It is available as a Cocoapod or through SPM. It is fairly mature now, but I would love to have more eyes on it.

You should consider add@hollyschilling code or add something liketryString, because good mapping in reactive base project (like RxSwift) practically base ontry!

I don't think the try syntax is very beginner friendly or easy to use

@CosynPa If someone use this pod and new "not beginner friendly" func / var with try in extension is a problem, then this someone will learn how to use try catch 🥇

PS.@hollyschilling BetterLibrary, really good work :)

any news on making SwiftyJSON throwable?

@BabyAzerty
I created new pod JSONModel with throwable extension. I can share it for you, but IMO the best option for throwable mapping is use:
https://hackernoon.com/everything-about-codable-in-swift-4-97d0e18a2999
https://github.com/quicktype/quicktype-xcode?utm_campaign=iOS%2BDev%2BWeekly&utm_medium=email&utm_source=iOS_Dev_Weekly_Issue_333

Read this article and check pod. If you will still need SwiftyJSON with throwable extension then mention me and I will share my version on GitHub