> On Jun 22, 2016, at 10:09 AM, Matthew Johnson <[email protected]> wrote:
>
>>
>> On Jun 22, 2016, at 10:59 AM, John McCall <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>
>>> On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>>> Rationalizing base conversion protocol names. I personally don't have the
>>>> heart to try to re-address the "LiteralConvertible" protocol naming thing
>>>> again but this would be the last chance to do anything about getting this
>>>> issue addressed.
>>> Given the vast amount of bike shedding that has already happened around
>>> this topic, I don’t think there is a solution that everyone will be happy
>>> with. It is also unclear (to me at least) what solution might be
>>> acceptable to the core team.
>>
>> To be clear, I don't care about the name. If you want to rename
>> IntegerLiteralConvertible to IntegerLiteral or whatever, I won't drag the
>> conversation into the muck again. :) It's the design of the requirements
>> that I'm pretty opposed to revisiting.
>
> This is orthogonal to the discussion that happened in your thread, definitely
> no discussion of any changes to the requirements. :)
>
> We are discussing this proposal:
> https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md
>
> <https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md>
> and specifically the use of the `Convertible` suffix for both the
> `*LiteralConvertible` protocols and the `Custom(Debug)StringConvertible`
> protocols where the conversion runs in opposite directions.
>
> The core team decision was:
>
> "The feedback on the proposal was generally positive about the idea of
> renaming these protocols, but the specific names in the proposal are not well
> received, and there is no apparent confluence in the community on better
> names. The core team prefers discussion to continue -- if/when there is a
> strong proposal for a better naming approach, we can reconsider renaming
> these."
We identified three categories:
* A protocol for types that can be initialized from specific types or
protocols, e.g. created/initialized with strings (a specific type) or
created/initialized with floating point numbers (conforming to a protocol).
Current examples include "IntegerLiteralConvertible".
* A protocol for types that can form a representation which may or may not
provide a complete projection (the original may not be recoverable from that
representation), e.g. "CustomStringConvertible" and
"CustomPlaygroundQuickLookable" both fall into this.
* A protocol for isomorphism: can be converted to and from a type, e.g.
"RawRepresentable"
This is really the last chance to rationalize this across the language and to
evaluate whether other protocol groups should have a core scheme for naming.
-- E
p.s. AbsoluteValuable, AnyCollectionProtocol, AnyObject,
ArrayLiteralConvertible, BidirectionalCollection, Collection,
BidirectionalIndexable, BinaryFloatingPoint, FloatLiteralConvertible,
BitwiseOperations, Boolean, BooleanLiteralConvertible, CVarArg, Collection,
Sequence, Comparable, CustomDebugStringConvertible, CustomLeafReflectable,
CustomPlaygroundQuickLookable, CustomReflectable, CustomStringConvertible,
DictionaryLiteralConvertible, Equatable, ErrorProtocol,
ExtendedGraphemeClusterLiteralConvertible, FloatLiteralConvertible,
FloatingPoint, IntegerLiteralConvertible, SignedNumber, AbsoluteValuable,
Strideable, Hashable, Indexable, IndexableBase, Integer : _Integer, Strideable,
IntegerArithmetic : _IntegerArithmetic, Comparable, IntegerLiteralConvertible,
IteratorProtocol, LazyCollectionProtocol, LazySequenceProtocol,
LazySequenceProtocol, MirrorPath, MutableCollection, Collection,
MutableIndexable, NilLiteralConvertible, OptionSet, RawRepresentable,
OutputStream, RandomAccessCollection, BidirectionalCollection,
RandomAccessIndexable, RangeReplaceableCollection, Collection,
RangeReplaceableIndexable, RawRepresentable, Sequence, SetAlgebra,
ArrayLiteralConvertible, SignedInteger : _SignedInteger, Integer, SignedNumber,
IntegerLiteralConvertible, Streamable, Strideable,
StringInterpolationConvertible, StringLiteralConvertible, UnicodeCodec,
UnicodeScalarLiteralConvertible, UnsignedInteger :
_DisallowMixedSignArithmetic, Integer, _DisallowMixedSignArithmetic : _Integer,
_Incrementable, _Integer, CustomStringConvertible, Hashable, IntegerArithmetic,
BitwiseOperations, _Incrementable, _IntegerArithmetic, _SequenceWrapper,
_SignedInteger : _Integer, SignedNumber
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
