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 <[email protected]> wrote:
>
> How do you mean?
> On Fri, Jul 1, 2016 at 14:44 David Sweeris <[email protected]
> <mailto:[email protected]>> 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
> <[email protected] <mailto:[email protected]>> wrote:
>
>> Perhaps another candidate for sinking into `Syntax`?
>> On Fri, Jul 1, 2016 at 14:23 Dmitri Gribenko via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>> On Fri, Jul 1, 2016 at 12:16 PM, Eric Habberstad via swift-evolution
>> <[email protected] <mailto:[email protected]>> 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 <[email protected]
>> <mailto:[email protected]>>*/
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
