> Am 26.06.2016 um 23:03 schrieb Jean-Daniel Dupas via swift-evolution
> <[email protected]>:
>
> 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.
again, `.none()` is not fully specified. So your answer isn't really an answer
to my question. There is
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]
-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
>>> <[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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
