v1.0.0

Changed

• On Apple platforms, PropertyListValue(propertyList:) reads what
  PropertyListSerialization and UserDefaults hand back in under a third
  of the instructions: an object is told apart once by its CoreFoundation
  type ID, a number is read without being bridged first, and a collection
  is walked where it stands rather than cast to a Swift one.
  PropertyListSerialization.propertyListValue(from:) takes about 58% fewer
  instructions for it, and a tree of Swift values built by hand about 6%
  fewer.
• PropertyListValue.init(from:) asks the decoder whether a value is a
  dictionary or an array before reading it as one, where it used to find out
  by reading a collection and failing. Reading a tree through
  PropertyListDecoder takes about 10% fewer instructions for it.
• PropertyListValue.init(from:) throws the error for something nested that
  no case can hold — a CFKeyedArchiverUID, say — as the decoder reported it,
  with the coding path to where it was. It used to be wrapped in a
  dataCorrupted at the collection that held it, with that path only in the
  message.
• PropertyListValueDecoder looks a key up once to read an optional property,
  where the standard library's decodeIfPresent looked it up three times.
  Decoding a structure with one optional property among four takes about 5%
  fewer instructions.
• PropertyListValueEncoder starts a dictionary with room for six keys rather
  than growing it from empty, which takes about 7% off encoding a structure of
  four properties and two allocations with it.
• On Apple platforms, the package now depends on
  swift-core-foundation-kit,
  which is what tells an object apart by its CoreFoundation type ID and
  reads it from there. Other platforms resolve the dependency and build
  none of it. It is asked for from 1.0.0, which walks a dictionary of eight
  pairs or fewer without allocating: reading an object graph takes three
  allocations fewer for it, and about 5% fewer instructions.

Full Changelog: v0.1.0...v1.0.0