well, JSONSerialization uses NSNull() as the null value currently. I think this
is right, because a JSON null is conceptually a different thing than `nil as
Any?` - Representing null as "not any value" a.k.a. `nil as Any?` would be a
pun in my opinion.
-Michael
> Am 27.06.2016 um 08:32 schrieb Jean-Daniel Dupas via swift-evolution
> <swift-evolution@swift.org>:
>
>
>> Le 27 juin 2016 à 00:00, Michael Peternell via swift-evolution
>> <swift-evolution@swift.org> a écrit :
>>
>>>
>>> Am 26.06.2016 um 23:03 schrieb Jean-Daniel Dupas via swift-evolution
>>> <swift-evolution@swift.org>:
>>>
>>> Optional are definitely the best way to represent null when parsing JSON.
>>>
>>>> Le 26 juin 2016 à 22:35, Michael Peternell via swift-evolution
>>>> <swift-evolution@swift.org> 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.
>>
>> again, `.none()` is not fully specified. So your answer isn't really an
>> answer to my question. There is
>
> Optional<Any> (aka Any?) is a fully defined type.
>
>> let null1: String? = nil
>> let null2: Int? = nil
>> let null3: Any? = nil
>>
>> and null1, null2 and null3 are three different concrete values. You are
>> making it too easy for yourself when you just say `.none()`, without
>> specifying the type you are referring to.
>>
>> Also, `let x = nil` does not even compile, for exactly this reason. So
>> again, how do you want to represent a JSON null in Swift?
>>
>> let json_null: ... = ... // ???
>> let myJSONdict = ["a":2, "b":json_null]
>
> As I said, myJSONdict can perfectly be represented as a [String:Any?]
> dictionary.
>
>> -Michael
>>
>>>
>>>> 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
>>>>> <swift-evolution@swift.org>:
>>>>>
>>>>> 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
>>>>> <swift-evolution@swift.org> 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
>>>>>> swift-evolution@swift.org
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution@swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
