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

Saagar Jha saagarjha28 at gmail.com
Sun Jun 26 22:48:06 CDT 2016


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 at swift.org> wrote:

>
> > Am 26.06.2016 um 23:03 schrieb Jean-Daniel Dupas via swift-evolution <
> swift-evolution at 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 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.
>
> 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 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
> >
> > _______________________________________________
> > 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
>
-- 
-Saagar Jha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160627/ed162bf1/attachment.html>


More information about the swift-evolution mailing list