[swift-evolution] Proposal: conversion protocol naming conventions

[ilya]

> p.s. Does anyone ever actually use debugString stuff? I love it in
concept but I find that I use it about 0% of the time
Composite types (array, optional, ...) display debugString output

On Tue, Dec 15, 2015 at 20:59 Erica Sadun via swift-evolution <
swift-evolution at swift.org> wrote:

> The great advantage of basic renaming is that migration is super-simple.
> And now that I think about it, CustomStringRepresentable is probably a
> lot better than CustomStringRepresentationExpressible
>
> It's easy enough to take some time, throw some options out there, and come
> up with names that better represent the concepts in question (the big win
> of your proposal) and then vote for the best.
>
> -- E
> p.s. Does anyone ever actually use debugString stuff? I love it in concept
> but I find that I use it about 0% of the time
>
>
> On Dec 15, 2015, at 10:47 AM, Matthew Johnson <matthew at anandabits.com>
> wrote:
>
> Thanks for your input Erica!  I would be happy with any convention that
> establishes clarity and consistency.
>
> I wrote the proposal the way I did as it is the minimum change from
> current state that would establish clarity and consistency.  My rationale
> was the smaller the change, the greater the chance of acceptance.
>
> It would be great to hear whether the community would prefer minimal
> change or wants to make a larger change if a better end result is possible
> that way.
>
> Matthew
>
> On Dec 15, 2015, at 11:39 AM, Erica Sadun via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> And adding:
>
> I *hate* Convertible in its current form. Per your current write-up, the
> protocols should cover initialized from, converted to, and a mix. Let me
> suggest:
>
> * can be initialized from: Instantiable, Initializable
> * can be converted to: Expressible, Presentable, Projectable
> * can be represented as and instantiated by: Convertible
>
> For example, IntegerLiteralInitializable,
> CustomStringRepresentationExpressible, and DoubleTypeConvertible.
>
> -- Erica
>
>
> On Dec 15, 2015, at 9:28 AM, Matthew Johnson via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Bumping this thread.  There wasn’t much response to the initial post,
> which may have been because Saturday night is probably not the best time to
> post a proposal.  :)
>
> You can find the draft here:
> https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md
>
> The little feedback I did receive was positive.
>
> Matthew
>
> On Dec 12, 2015, at 8:40 PM, Matthew Johnson via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I have drafted a proposal to establish precise conventional meaning for
> the use of `Convertible`, `Representable`, and `Projectable` protocol
> suffixes.  The proposal would require renaming `CustomStringConvertible`
> and `CustomDebugStringConvertible` to `CustomStringProjectable`
> and `CustomDebugStringProjectable` respectively
>
> I am seeking input on the proposal before submitting a PR.  The full draft
> can found at
> https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md
> .
>
> Thanks,
> Matthew
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151215/8d01cd98/attachment.html>