Why are to-many Core Data relationships represented as optionals?

As of Xcode 7b6, generating NSManagedObject subclasses for Swift in Xcode for an entity with a to-many relationship will generate a property of the optional type "NSSet?". From what I can tell the underlying NSManagedObject data will always contain an empty (or not empty) set for that key. Is there a good reason to keep relationships optional and having to deal with unwrapping the values every time?

This is why I still despise Swift. Nil values used to have a perfectly predictable behavior, but now you have to waste hours and hours satisfying the compiler. In one medium-sized Core Data project, I count over 4,100 ? and ! characters littering my code—most of which were painstakingly added by that drunken toddler known as Fix-It, which crashes if you even think about using Fix All in Scope. And what problem did they solve for me? Absolutely nothing! They cause more problems than they solve in lost productivity, considering how long it takes to migrate to the current version of the language and APIs every summer. You ultimately still have to handle the nil case, which is a perfectly legit value in most cases. Swift started with a noble goal, but it went off the rails when we were force-fed optionals, IMO. Would love to see optionals become an "optional" aspect of Swift, and I'd also love to see a modern replacement for Core Data that is more Swift-friendly.

Why are to-many Core Data relationships represented as optionals?
 
 
Q