[swift-evolution] [Pitch] Add Null struct to Foundation

Jean-Daniel Dupas mailing at xenonium.com
Sun Jun 26 16:03:06 CDT 2016


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 at 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.

> 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 at 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 at 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 at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



More information about the swift-evolution mailing list