> On May 18, 2016, at 3:01 PM, Erica Sadun <er...@ericasadun.com> wrote: > > >> On May 18, 2016, at 1:58 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >>> On May 18, 2016, at 1:52 PM, Brent Royal-Gordon <br...@architechies.com> >>> wrote: >>> >>>>> If we're doing this, I wonder if category 1 shouldn't just be >>>>> `Convertible`. This would preserve our `LiteralConvertible` protocols >>>>> with the same names (which, consistency issues aside, seem perfectly >>>>> cromulent), while shifting the `StringConvertible` protocols over to the >>>>> `Representable` category. >>>> >>>> Do you really think 'Convertible' is more clear than 'Initializable'? >>> >>> I don't think `Convertible` is clearer than `Initializable`, but I think it >>> rolls off the tongue better, is easier to spell, is more compatible with >>> non-initializer implementations, and in general wins on a lot of squishy, >>> subjective, hard-to-define axes. >>> >>> Subjectively, I've noticed that a lot of people *don't* think of things >>> like `Double(myFloat)` as being initializers; they think of them as >>> conversions. To those people, `Convertible` is probably the right name. >> >> Thanks for elaborating. I can see that perspective. It does also have the >> advantage of being the smallest change from current state. >> >> I certainly wouldn’t oppose this. The most important thing IMO is that we >> agree on *something*. > > > The whole discussion started because ArrayLiteralConvertible meant "can be > initialized from Array literal", and not "can be converted to array literal", > which is what nearly everyone this was presented to in an informal study > thought it meant. >
That was not the genesis of this proposal in my mind. I was frustrated with the different semantics for Convertible between CustomStringConvertible and *LiteralConvertible. However, I do agree that there is some potential for ambiguity inherent in the term Convertible which is probably how the current conflicting uses arose in the first place. Whatever we decide to do, I hope we can at least remove the current conflict and have consistent meanings in the standard library! > -- E > _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
