initializeBufferWithTakeOfBuffer value witness.
Attempt to use initializeBufferWithTakeOfBuffer in
some appropriate places.
There are some changes enabled by this which are
coming in a follow-up patch.
Swift SVN r20802
initializeBufferWithTakeOfBuffer value witness.
Attempt to use initializeBufferWithTakeOfBuffer in
some appropriate places.
There are some changes enabled by this which are
coming in a follow-up patch.
Swift SVN r20741
There's no meaningful way in which these methods are public, since they
can't be accessed through any value of the type
<rdar://problem/17647878>
Swift SVN r20224
Mechanically add "Type" to the end of any protocol names that don't end
in "Type," "ible," or "able." Also, drop "Type" from the end of any
associated type names, except for those of the *LiteralConvertible
protocols.
There are obvious improvements to make in some of these names, which can
be handled with separate commits.
Fixes <rdar://problem/17165920> Protocols `Integer` etc should get
uglier names.
Swift SVN r19883
Feedback from Dave and Dmitri - the Mirrors.gyb file is now split in three parts:
- Boilerplate, the value, valueType, objectIdentifier and disposition properties
- Decl, the type declaration proper, with no opening brace
- Conformance, the extension that provides Reflectable conformance on the original type
This is substantially no feature change, but it should make for easier editing, and a generally more readable experience
Swift SVN r19637
This commit removes Mirrors for RangeGenerators, since Dave and I discussed that these won't be necessary in practice
Also, it removes the Mirrors for Range types from Range.swift.gyb, and instead adds a new RangeMirrors.swift.gyb used to generate range types Mirrors
Swift SVN r19543
This is a .gyb file based upon Dave's trick of allowing boilerplate templates (r19490)
As per comments, this will generate all the common cruft of getting a Mirror up and running - yes including the Reflectable conformance on the type!
It could likely be extended to specify a full Mirror, either by defaulting missing parts, or by letting you specify them as arguments to the template
However, since we can have other templates that use this as a foundation, those expansions might be best served being their own templates based upon this
Also, the members this doesn't generate for you are usually the ones you care about when writing a Mirror, so probably passing them as arguments to this template generator would only make things look uglier/less obvious when skimming through the code
Swift SVN r19534
