[swift-evolution] renaming CustomStringConvertible

David Sweeris davesweeris at mac.com
Fri Jul 1 15:10:53 CDT 2016


As I understand things, the point of the whole “Syntax.Literal.ICan’tRememberWhatIt’sCalledToday” discussion was that syntactically speaking, literals kinda work the opposite as how everyone thinks they do. That’s not the case here; CustomStringConvertible clearly only requires `var description: String {get}`. But the String interpolation “operator", “\()” might be a good candidate for moving into “Syntax”, if we ever decide it should be able to interact with types other than `T` and `T: CustomStringConvertible`. Well, IMHO, it probably should get moved there regardless, but “my humble opinion" does not make for a convincing proposal on its own (which is unfortunate, IMHO :-D ).

- Dave Sweeris

> On Jul 1, 2016, at 2:47 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
> How do you mean?
> On Fri, Jul 1, 2016 at 14:44 David Sweeris <davesweeris at mac.com <mailto:davesweeris at mac.com>> wrote:
> Maybe... It's just a property, though. I think if something's moving into the Syntax thing, I'd rather look for a way to move string interpolation there. Maybe.
> 
> - Dave Sweeris
> 
> On Jul 1, 2016, at 14:24, Xiaodi Wu via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> Perhaps another candidate for sinking into `Syntax`?
>> On Fri, Jul 1, 2016 at 14:23 Dmitri Gribenko via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> On Fri, Jul 1, 2016 at 12:16 PM, Eric Habberstad via swift-evolution
>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> >
>> > To the Swift community,
>> >
>> > May I put forth a couple of new names for the following protocol:
>> >
>> >
>> > - CustomStringConvertible  —   rename as ‘Descriptive’ or as ‘Revealable’
>> >
>> >
>> > Two goals for Swift is clarity and joy in use of the language, so I strongly
>> > feel that ‘Custom-‘ not be part of any new name here since it contributes
>> > little except verbosity
>> 
>> Hi Eric,
>> 
>> This protocol was called Printable before, but it caused a lot of
>> confusion for developers, and was guiding the developers toward
>> writing incorrect APIs.  We have seen a lot of developers writing code
>> like this:
>> 
>> func printAll(_ values: [Printable]) {
>>   for v in values { print(v) }
>> }
>> 
>> This code is unnecessarily restrictive since in Swift everything can
>> be converted into a String.
>> 
>> func printAll(_ values: [Any]) {
>>   for v in values { print(v) }
>> }
>> 
>> The same goes for retrieving debug descriptions and mirrors.  Any
>> value can do that.  It is just that some values can opt into
>> customizing this behavior.
>> 
>> Thus, we renamed the protocols, adding the Custom~ prefix.  Our
>> intention was to encourage only conformances to these protocols, and
>> discourage writing APIs against them.
>> 
>> Dmitri
>> 
>> --
>> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
>> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com <mailto:gribozavr at gmail.com>>*/
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160701/173fe569/attachment.html>


More information about the swift-evolution mailing list