Optional are definitely the best way to represent null when parsing JSON.
> Le 26 juin 2016 à 22:35, Michael Peternell via swift-evolution
> <[email protected]> a écrit :
>
> Just one question: If I have functions
>
> json_encode(j: JSON) -> String
> and
> json_decode(j: String) -> JSON throws
If the string is valid JSON, it return .some() optional, if ti is empty, it
returns .none() optional, and if it is invalid, it throws.
> what should be the type of JSON? What should '{"a":2,"b":null}' decode to?
Dictionary<String, Any?>
> What should the type of the JSON null value be in Swift?
Optional<Any>.none()
> I think String and String? and String??? are wrong in this case.
>
> I'm not saying that I'm convinced that NSNull() is the best way to represent
> null in this case. I just want to explain the use case that I was thinking of.
I hardly can think of a better use case than parsing JSON to demonstrate than
Optional are a far better solution to represent a null value than NSNull.
> -Michael
>
>> Am 26.06.2016 um 19:53 schrieb David Rönnqvist via swift-evolution
>> <[email protected]>:
>>
>> I'm not convinced that Swift needs more than on way of representing the lack
>> of a value. As far as I've understood (and remember), NSNull main reason to
>> exist is that it's an actual object and won't for example terminate array
>> literals. From what I've observed of people who are new to Objective-C,
>> NSNull is a big surprise, both its general existence but also when to expect
>> it (read check for NSNull to make sure one doesn't crash) and when not to.
>>
>> The way I've imagined that the same problem would be solved in Swift is with
>> an optional, optional value. That is: if a field in a response can either be
>> set or not, that's an optional. If that field can either contain a value or
>> the explicit lack of a value that's another optional:
>>
>> let nickname: String?? = "Little Bobby Tables"
>>
>> As I see it, this is both safer (requiring that the inner nil value is dealt
>> with), serves as a documentation of when an explicit missing value is
>> expected and when it's not, and is more consistent.
>>
>> I would still expect a newcomer to wonder why there is two question marks in
>> some places, but I'd imagine that that explanation would feel more logical.
>>
>> And it's (still) possible (at least in the latest Swift Playground) to
>> safely unwrap both levels:
>>
>> if case let name?? = nickname { }
>>
>> - David
>>
>> Sent from my iPad
>>
>> On 24 Jun 2016, at 11:32, Brent Royal-Gordon via swift-evolution
>> <[email protected]> wrote:
>>
>>>> Not really. What is the type of Optional.none? `let empty = Optional.none`
>>>> does not compile, it says "Generic parameter 'Wrapped' could not be
>>>> inferred". NSNull() is a unique concrete value, and it's compatible with
>>>> Objective C, NSObject and AnyObject. We could of course use
>>>> `Optional<Int16>.none`, but someone else may use
>>>> `Optional<AnyObject>.none` instead. The extra type information is just
>>>> misleading in this case.
>>>
>>> If you want a single, unique value, use `()`.
>>>
>>> But I'm not sure why you wouldn't just make this member an Optional<Any> in
>>> the first place. Is there some reason that wouldn't be suitable?
>>>
>>> --
>>> Brent Royal-Gordon
>>> Architechies
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected]
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
