[Pitch] Add Null struct to Foundation

Evolution Pitches
1

Add a struct Null to the Swift 3.0 Foundation value types. As a struct, Null is more performant (no ARC or memory allocation) than NSNull, and will be needed for Swift JSON decoders and libraries that want to use struct value types, and be free from classes for their model layer.

  Coleman,

2

I assume you are thinking of [String:SomeRootJSONProtocol] as the Object type? However, once you reference the data as a protocol however, it will be promoted and stored as a reference type.

I’ve preferred a similar approach to the following for JSON (although this isn’t my code): JSON.swift · GitHub

-DW

···

On Jun 22, 2016, at 10:14 PM, Alsey Miller via swift-evolution <swift-evolution@swift.org> wrote:

Add a struct Null to the Swift 3.0 Foundation value types. As a struct, Null is more performant (no ARC or memory allocation) than NSNull, and will be needed for Swift JSON decoders and libraries that want to use struct value types, and be free from classes for their model layer.

3

I think NSNull() should be used, not a struct. I don't think that a struct would be more performant. Or maybe the performance doesn't matter at all in any real-world usage scenario. But you may write a benchmark of a realistic (!) use-case (!) if you think otherwise... would be interesting to see the results.

Keeping with NSNull() also simplifies objc-interoperability.

-Michael

···

Am 23.06.2016 um 06:14 schrieb Alsey Miller via swift-evolution <swift-evolution@swift.org>:

Add a struct Null to the Swift 3.0 Foundation value types. As a struct, Null is more performant (no ARC or memory allocation) than NSNull, and will be needed for Swift JSON decoders and libraries that want to use struct value types, and be free from classes for their model layer.

  Coleman,

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

4

Please see

https://github.com/PureSwift/SwiftFoundation/blob/develop/Sources/SwiftFoundation/Null.swift

https://github.com/PureSwift/SwiftFoundation/blob/develop/Sources/SwiftFoundation/JSON.swift

Specifically, line 77 in JSON.swift

  Coleman,

···

On Jun 23, 2016, at 12:54 AM, David Waite <david@alkaline-solutions.com> wrote:

On Jun 22, 2016, at 10:14 PM, Alsey Miller via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Add a struct Null to the Swift 3.0 Foundation value types. As a struct, Null is more performant (no ARC or memory allocation) than NSNull, and will be needed for Swift JSON decoders and libraries that want to use struct value types, and be free from classes for their model layer.

I assume you are thinking of [String:SomeRootJSONProtocol] as the Object type? However, once you reference the data as a protocol however, it will be promoted and stored as a reference type.

I’ve preferred a similar approach to the following for JSON (although this isn’t my code): JSON.swift · GitHub

-DW

5

Doesn't Optional.None allready a placeholder for null values in swift?

I read some where that nil was the new way to represent null pointer in swift.

···

--
J. Charles

Le 24 juin 2016 à 00:59, Michael Peternell via swift-evolution <swift-evolution@swift.org> a écrit :

I think NSNull() should be used, not a struct. I don't think that a struct would be more performant. Or maybe the performance doesn't matter at all in any real-world usage scenario. But you may write a benchmark of a realistic (!) use-case (!) if you think otherwise... would be interesting to see the results.

Keeping with NSNull() also simplifies objc-interoperability.

-Michael

Am 23.06.2016 um 06:14 schrieb Alsey Miller via swift-evolution <swift-evolution@swift.org>:

Add a struct Null to the Swift 3.0 Foundation value types. As a struct, Null is more performant (no ARC or memory allocation) than NSNull, and will be needed for Swift JSON decoders and libraries that want to use struct value types, and be free from classes for their model layer.

   Coleman,

_______________________________________________
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

6

Doesn't Optional.None allready a placeholder for null values in swift?

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.

I read some where that nil was the new way to represent null pointer in swift.

It is, usually. But does it work in this case?

-Michael

···

Am 24.06.2016 um 07:59 schrieb J. Charles M. N. via swift-evolution <swift-evolution@swift.org>:

--
J. Charles

Le 24 juin 2016 à 00:59, Michael Peternell via swift-evolution <swift-evolution@swift.org> a écrit :

I think NSNull() should be used, not a struct. I don't think that a struct would be more performant. Or maybe the performance doesn't matter at all in any real-world usage scenario. But you may write a benchmark of a realistic (!) use-case (!) if you think otherwise... would be interesting to see the results.

Keeping with NSNull() also simplifies objc-interoperability.

-Michael

Am 23.06.2016 um 06:14 schrieb Alsey Miller via swift-evolution <swift-evolution@swift.org>:

Add a struct Null to the Swift 3.0 Foundation value types. As a struct, Null is more performant (no ARC or memory allocation) than NSNull, and will be needed for Swift JSON decoders and libraries that want to use struct value types, and be free from classes for their model layer.

  Coleman,

_______________________________________________
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

7

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

8

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

9

Just one question: If I have functions

json_encode(j: JSON) -> String
and
json_decode(j: String) -> JSON throws

what should be the type of JSON? What should '{"a":2,"b":null}' decode to? What should the type of the JSON null value be in Swift? 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.

-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

10

Optional are definitely the best way to represent null when parsing JSON.

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.

···

Le 26 juin 2016 à 22:35, Michael Peternell via swift-evolution <swift-evolution@swift.org> a écrit :

-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

11

Optional are definitely the best way to represent null when parsing JSON.

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

···

Am 26.06.2016 um 23:03 schrieb Jean-Daniel Dupas via swift-evolution <swift-evolution@swift.org>:

Le 26 juin 2016 à 22:35, Michael Peternell via swift-evolution <swift-evolution@swift.org> a écrit :

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

12

Any? or AnyObject?; have your dictionary be something like [String:
AnyObject?].

···

On Sun, Jun 26, 2016 at 3:00 PM Michael Peternell via swift-evolution < swift-evolution@swift.org> wrote:

> 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

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

--
-Saagar Jha

13

Optional are definitely the best way to represent null when parsing JSON.

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.

···

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>:

Le 26 juin 2016 à 22:35, Michael Peternell via swift-evolution <swift-evolution@swift.org> a écrit :

-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

14

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

15

JSONSerializer uses NSNull to workaround limitation of the Cocoa collections that do not support to insert nil value.

Moreover, without a null token, it would not be possible to know if the value is present but nil or absent when trying to access it without an additional key lookup.

Swift Optional provides a clean and better way to represent nil in a collection, and so don’t need NSNull at all.

To my point of view, considering JSON null as something different than nil is a misconception. They both are the same thing.

···

Le 27 juin 2016 à 18:50, Michael Peternell via swift-evolution <swift-evolution@swift.org> a écrit :

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