[swift-evolution] [Review] SE-0089: Renaming String.init<T>(_: T)
Leonardo Pessoa
me at lmpessoa.com
Wed May 25 17:49:28 CDT 2016
I get it that the point here is about the intention. If you mean to call
that initialiser, using an extra name or none should make no difference. If
there is a chance people are misusing the nameless initialiser, I don't see
a reason why not adding a name here.
On Wednesday, 25 May 2016, Karl Wagner via swift-evolution <
swift-evolution at swift.org> wrote:
> What is so bad about the global function idea?
>
> reflect(_:Any)->String
>
> It’s invoking the reflection APIs, doing a bunch of things you could do
> yourself with Mirror, and returning a String.
>
> I know we don’t have many global functions, but this seems like a
> reasonable place for one.
>
> This isn’t Objective-C; we have namespaces. You can still create another
> function with that same signature, and refer to the global one with
> Swift.reflect().
>
> Karl
>
> > On 22 May 2016, at 20:19, Dave Abrahams via swift-evolution <
> swift-evolution at swift.org <javascript:;>> wrote:
> >
> >
> > on Fri May 20 2016, Kevin Ballard <swift-evolution at swift.org
> <javascript:;>> wrote:
> >
> >> On Fri, May 20, 2016, at 05:14 PM, Dave Abrahams via swift-evolution
> wrote:
> >>>
> >>> on Fri May 20 2016, Kevin Ballard <swift-evolution at swift.org
> <javascript:;>> wrote:
> >>>
> >>>> On Tue, May 17, 2016, at 08:32 PM, Chris Lattner via swift-evolution
> wrote:
> >>>>> * What is your evaluation of the proposal?
> >>
> >>>>
> >>>> I'm a little nervous about this change, because converting things to
> >>>> strings is a fairly basic operation and it should be immediately
> >>>> obvious how to do that. That said, the described issues are pretty
> >>>> bad, and I know I've had to carefully triple-check sometimes to make
> >>>> sure I was calling the right initializer. So I'm +1 on the idea.
> >>>>
> >>>> That said, I don't like the name String(printing:). As others have
> >>>> pointed out, it sounds like this is related to print(), but this
> >>>> initializer does not actually print anything, it just converts any
> >>>> value into a string. I also don't like String(describing:) because
> >>>> it's too long. This initializer should be easier to call than
> >>>> String(reflecting:). Also, in my experience this initializer is
> >>>> particularly useful with code of the form `someOpt.map(String.init)`,
> >>>> and saying `someOpt.map(String.init(describing:))` is annoyingly long.
> >>>>
> >>>> Given this, I'd like to suggest the simpler `String(from:)`. It's
> >>>> short and generic, and it makes sense as it creates a String from any
> >>>> value.
> >>>
> >>> Not too bad. I could live with it.
> >>
> >> 😀
> >>
> >>>> I'm also not a fan of Dave's suggestion of removing this initializer
> >>>> entirely in favor of "\(foo)". This feels weird, and it also can't be
> >>>> turned into a first-class function value.
> >>>
> >>> { "\($0)" }
> >>>
> >>> ?
> >>
> >> Good point. I think what I intended to express was you cannot refer to
> >> this operation by name anymore. Maybe not a big deal, but it feels
> >> weird.
> >
> > Makes sense.
> >
> > --
> > -Dave
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org <javascript:;>
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <javascript:;>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160525/0374d413/attachment.html>
More information about the swift-evolution
mailing list