[Review] SE-0089: Renaming String.init<T>(_: T)

Hello Swift community,

The review of "SE-0089: Renaming String.init<T>(_: T)" begins now and runs through May 23. The proposal is available here:

  swift-evolution/0089-rename-string-reflection-init.md at master · apple/swift-evolution · GitHub

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  swift-evolution/process.md at master · apple/swift-evolution · GitHub

Thank you,

-Chris Lattner
Review Manager

        * What is your evaluation of the proposal?

+1, because:
  - I believe the default/generic "printing" initializer is not commonly
used (at least, not on purpose).
  - The new argument label clearly indicates what the initializer does.

I would also submit for consideration "*init(describing:)*", to match the
CustomStringConvertible ".description" property which it invokes.

        * Is the problem being addressed significant enough to warrant a
change to Swift?

Yes: accidental use of the initializer can be harmful, and is currently
very easy.

        * Does this proposal fit well with the feel and direction of Swift?

Yes, it fits well with the API guidelines.

        * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?

N/A

        * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

A quick reading.

  * What is your evaluation of the proposal?

I think this is a good and long-needed change.

I also think that the matching protocols should be renamed to correspond to the initializers used to invoke them: CustomStringConvertible should become PrintingStringConvertible, and CustomDebugStringConvertible should become ReflectingStringConvertible. (The suffixes may change depending on SE-0041, of course.)

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes. I've always found it rather disturbing and bizarre that you could make a String out of anything and get a random, possibly unintended result. `String.init(printing:)` makes this more intentional, which is definitely a good thing.

  * Does this proposal fit well with the feel and direction of Swift?

Yes. We're all about being explicit, right?

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I much prefer Swift's solution of using an initializer to other languages' use of `to_s` or `toString()` methods.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick reading.

···

--
Brent Royal-Gordon
Architechies

* What is your evaluation of the proposal?
+1. A very simple API change that fixes a footgun in the standard library.
        * Is the problem being addressed significant enough to warrant a
change to Swift?
Yes.
        * Does this proposal fit well with the feel and direction of Swift?
Yes.
        * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
N/A
        * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
I followed the original thread and read the proposal.

···

On Tue, May 17, 2016 at 11:32 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0089: Renaming String.init<T>(_: T)" begins now and runs
through May 23. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

        https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and contribute to the direction of Swift.
When writing your review, here are some questions you might want to answer
in your review:

        * What is your evaluation of the proposal?
        * Is the problem being addressed significant enough to warrant a
change to Swift?
        * Does this proposal fit well with the feel and direction of Swift?
        * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
        * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

More information about the Swift evolution process is available at

        https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau

I would still prefer a global function; because the output is from reflection, it’s really more for debugging purposes than actually serialising something.

But any change to this gets a +1 from me. It’s too easy to accidentally call this instead of one of the other argument-less initialisers on String.

Karl

···

On 18 May 2016, at 05:32, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0089: Renaming String.init<T>(_: T)" begins now and runs through May 23. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

  * What is your evaluation of the proposal?

+1. Some of the examples of current behavior given in the discussion were disturbing to me. This makes intent explicit.

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes.

  * Does this proposal fit well with the feel and direction of Swift?

Yes.

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick read as well as following the original discussion.

···

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Hello Swift community,

The review of "SE-0089: Renaming String.init<T>(_: T)" begins now and runs
through May 23. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

        https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and contribute to the direction of Swift.
When writing your review, here are some questions you might want to answer
in your review:

        * What is your evaluation of the proposal?

+1. Being able to convert anything to a String using an initializer that
doesn't state its purpose is an easy way for users to get behavior they
don't want or expect. Parameterless initializers should be for "clean" and
simple conversions, which this is not.

        * Is the problem being addressed significant enough to warrant a
change to Swift?

Yes. It's easy for users to mess up using the current syntax, and the
solution is trivial.

        * Does this proposal fit well with the feel and direction of Swift?

Yes.

        * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?

        * How much effort did you put into your review? A glance, a quick

reading, or an in-depth study?

Quick read of the proposal.

···

On Tue, May 17, 2016 at 8:32 PM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

More information about the Swift evolution process is available at

        https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Hello Swift community,

The review of "SE-0089: Renaming String.init<T>(_: T)" begins now and runs through May 23. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?

This method definitely has some strange behavior and I think it most certainly would benefit from a better name. `init<T>(printing value:<T>)` to me sounds like this is somehow printing the string, either to the console or to an arcane device called a “printer”. Personally I think that `init<T>(describing value:<T>)` is more suitable as a name of an initializer.

  * Is the problem being addressed significant enough to warrant a change to Swift?

Absolutely! It improves safety and clarity with little cost to developers

  * Does this proposal fit well with the feel and direction of Swift?

Most definitely

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I have never run across this issue in another language/library. However I have previously attempted to avoid similar problems in C++ so I would definitely consider the standard of having good (and un-ambiguous names a strong benefit when it comes to potentially too generic methods)

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I have personally run across bugs due to this in the wild and it definitely was unexpected and probably took me too long to recognize the reason on why it happened.

···

On May 17, 2016, at 8:32 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Hello Swift community,

The review of "SE-0089: Renaming String.init<T>(_: T)" begins now and runs through May 23. The proposal is available here:

        https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md

        * What is your evaluation of the proposal?

As described in the proposal, it makes sense. I never faced the issue
myself but agree to the change. I'd also go with Jacob's version
'init(describing:)' since there is no guarantee the resulting string
will be printed but will surely describe the object used as argument.

        * Is the problem being addressed significant enough to warrant a change to Swift?

As outlined by the proposal, yes.

        * Does this proposal fit well with the feel and direction of Swift?

Yes.

        * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

None.

        * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A quick reading.

I'm posting this on behalf of Dmitri Gribenko, and Max Moiseev, and
myself.

We would like to accept the proposal with one modification: rather than
add an argument label, we'd like to drop the String initializer
altogether, making `"\(expression)"` the standard way to get a string
representation of `expression`.

Thanks,

···

on Tue May 17 2016, Chris Lattner <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0089: Renaming String.init<T>(_: T)" begins now and
runs through May 23. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md

Reviews are an important part of the Swift evolution process. All
reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and contribute to the direction of
Swift. When writing your review, here are some questions you might
want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

--
-Dave

  * 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.

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. I also think that this approach may encourage people to start using the .description property instead, even though accessing this property is discouraged.

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes.

  * Does this proposal fit well with the feel and direction of Swift?

Yes. Initializers that take one unlabeled argument are typically used for full-width conversions, and I don't think this initializer qualifies as a full-width conversion.

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Some languages have a global function that does this, such as Python's str(foo) or Haskell's `show`. Some languages have a method/property, such as Obj-C (-description) and Ruby (foo.to_s(), though I believe you can also say String(foo)). I'm not aware of any languages that require string interpolation for this functionality. Keeping the initializer and just giving it a label is similar to a global function or to Ruby's String(foo). Removing the initializer in favor of just just string interpolation does not compare to any language I know of.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A quick reading of the proposal, and a reading of the review thread to date.

-Kevin Ballard

···

On Tue, May 17, 2016, at 08:32 PM, Chris Lattner via swift-evolution wrote:

I like Jacob's suggestion of "init(describing:)", and I also think the review team should consider the global function alternative. My main goal is also preventing silently incorrect code.

Austin

···

On May 17, 2016, at 10:14 PM, Karl Wagner via swift-evolution <swift-evolution@swift.org> wrote:

I would still prefer a global function; because the output is from reflection, it’s really more for debugging purposes than actually serialising something.

But any change to this gets a +1 from me. It’s too easy to accidentally call this instead of one of the other argument-less initialisers on String.

Karl

On 18 May 2016, at 05:32, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0089: Renaming String.init<T>(_: T)" begins now and runs through May 23. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

+1 (replying here because I can't find the root and I agree with this evaluation).

~Robert Widmann

2016/05/17 22:07、Trent Nadeau via swift-evolution <swift-evolution@swift.org> のメッセージ:

···

        * What is your evaluation of the proposal?
+1. A very simple API change that fixes a footgun in the standard library.
        * Is the problem being addressed significant enough to warrant a change to Swift?
Yes.
        * Does this proposal fit well with the feel and direction of Swift?
Yes.
        * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
N/A
        * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I followed the original thread and read the proposal.

On Tue, May 17, 2016 at 11:32 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
Hello Swift community,

The review of "SE-0089: Renaming String.init<T>(_: T)" begins now and runs through May 23. The proposal is available here:

        https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

        https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

        * What is your evaluation of the proposal?
        * Is the problem being addressed significant enough to warrant a change to Swift?
        * Does this proposal fit well with the feel and direction of Swift?
        * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
        * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

        https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Another +1 to Jacob's suggestion, and of course +1 to the intent of the
proposal itself.

···

On Tue, May 17, 2016 at 10:17 PM, Austin Zheng via swift-evolution < swift-evolution@swift.org> wrote:

I like Jacob's suggestion of "init(describing:)", and I also think the
review team should consider the global function alternative. My main goal
is also preventing silently incorrect code.

Austin

> On May 17, 2016, at 10:14 PM, Karl Wagner via swift-evolution < > swift-evolution@swift.org> wrote:
>
> I would still prefer a global function; because the output is from
reflection, it’s really more for debugging purposes than actually
serialising something.
>
> But any change to this gets a +1 from me. It’s too easy to accidentally
call this instead of one of the other argument-less initialisers on String.
>
> Karl
>
>> On 18 May 2016, at 05:32, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:
>>
>> Hello Swift community,
>>
>> The review of "SE-0089: Renaming String.init<T>(_: T)" begins now and
runs through May 23. The proposal is available here:
>>
>>
https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md
>>
>> Reviews are an important part of the Swift evolution process. All
reviews should be sent to the swift-evolution mailing list at
>>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> or, if you would like to keep your feedback private, directly to the
review manager.
>>
>> What goes into a review?
>>
>> The goal of the review process is to improve the proposal under review
through constructive criticism and contribute to the direction of Swift.
When writing your review, here are some questions you might want to answer
in your review:
>>
>> * What is your evaluation of the proposal?
>> * Is the problem being addressed significant enough to warrant a
change to Swift?
>> * Does this proposal fit well with the feel and direction of Swift?
>> * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
>> * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
>>
>> More information about the Swift evolution process is available at
>>
>> https://github.com/apple/swift-evolution/blob/master/process.md
>>
>> Thank you,
>>
>> -Chris Lattner
>> Review Manager
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

+1
converting to a string is definitely lossy for most cases.

···

On Wed, May 18, 2016 at 12:09 AM, Jacob Bandes-Storch via swift-evolution < swift-evolution@swift.org> wrote:

        * What is your evaluation of the proposal?

+1, because:
  - I believe the default/generic "printing" initializer is not commonly
used (at least, not on purpose).
  - The new argument label clearly indicates what the initializer does.

I would also submit for consideration "*init(describing:)*", to match the
CustomStringConvertible ".description" property which it invokes.

        * Is the problem being addressed significant enough to warrant a
change to Swift?

Yes: accidental use of the initializer can be harmful, and is currently
very easy.

        * Does this proposal fit well with the feel and direction of
Swift?

Yes, it fits well with the API guidelines.

        * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?

N/A

        * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

A quick reading.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

`init(describing:)` make sense to me. I can see how it could be argued “well it looks like it calls the ‘description’ method of the argument, when it doesn’t, so this is poor naming”.

However, `init(printing:)` looks like it has something to do with `print()`, when it doesn’t. ‘Print’ is a verb, and means to print to standard output. `init(printing:)` has nothing to do with the standard output.

So, `init(describing:)`, how is it more clear? I think it is more clear as you are always getting a description. If you want a custom description, it’s obvious, you implement CustomStringConvertible’s description method. The word ‘describing’ is just based on its meaning, not on how it is implemented with the use of CustomStringConvertible or not.

Patrick

···

On 19 May 2016, at 6:34 AM, Leonardo Pessoa via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0089: Renaming String.init<T>(_: T)" begins now and runs through May 23. The proposal is available here:

       https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md

       * What is your evaluation of the proposal?

As described in the proposal, it makes sense. I never faced the issue
myself but agree to the change. I'd also go with Jacob's version
'init(describing:)' since there is no guarantee the resulting string
will be printed but will surely describe the object used as argument.

       * Is the problem being addressed significant enough to warrant a change to Swift?

As outlined by the proposal, yes.

       * Does this proposal fit well with the feel and direction of Swift?

Yes.

       * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

None.

       * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A quick reading.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Excellent. Having one canonical, unambiguous way to get the string
representation should make things simpler and easier for developers.

Austin

···

On Thu, May 19, 2016 at 3:57 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote:

on Tue May 17 2016, Chris Lattner <swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of "SE-0089: Renaming String.init<T>(_: T)" begins now and
> runs through May 23. The proposal is available here:
>
>
https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md
>
> Reviews are an important part of the Swift evolution process. All
> reviews should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of
> Swift. When writing your review, here are some questions you might
> want to answer in your review:
>
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a
change to Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md

I'm posting this on behalf of Dmitri Gribenko, and Max Moiseev, and
myself.

We would like to accept the proposal with one modification: rather than
add an argument label, we'd like to drop the String initializer
altogether, making `"\(expression)"` the standard way to get a string
representation of `expression`.

Thanks,

--
-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I'm posting this on behalf of Dmitri Gribenko, and Max Moiseev, and
myself.

We would like to accept the proposal with one modification: rather than
add an argument label, we'd like to drop the String initializer
altogether, making `"\(expression)"` the standard way to get a string
representation of `expression`.

Given how complicated the StringInterpolationConvertible protocol is, I'm not sure it's a good idea to invoke all of that machinery merely to convert an expression to a string. I mean, you end up with code like:

  String(stringInterpolation:
    String(stringInterpolationSegment: ""),
    String(stringInterpolationSegment: expression),
    String(stringInterpolationSegment: "")
  )

That seems like a lot of code to generate for such a simple task.

(And you can have those empty segments over my dead body—they're very important to a lot of interpolation use cases, because they allow you to distinguish between the literal and interpolated segments. If you want to design a different mechanism that's more efficient and equally capable, well, I'm happy to talk about improving StringInterpolationConvertible any time you are, but it'll definitely be opening a can of worms.)

···

--
Brent Royal-Gordon
Architechies

Hello Swift community,

The review of "SE-0089: Renaming String.init<T>(_: T)" begins now and
runs through May 23. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md

Reviews are an important part of the Swift evolution process. All
reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and contribute to the direction of
Swift. When writing your review, here are some questions you might
want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

I'm posting this on behalf of Dmitri Gribenko, and Max Moiseev, and
myself.

We would like to accept the proposal with one modification: rather than
add an argument label, we'd like to drop the String initializer
altogether, making `"\(expression)"` the standard way to get a string
representation of `expression`.

Is there some performance-driven motivation here, or is this just aesthetics?

I ask b/c not having a name for this "initializer" here would seem mildly annoying and asymmetric vis-a-vis `String.init(reflecting:)`; sure, I can always add an equivalent with a name, but I’m curious if there’s an argument-from-functionality for the removal.

Also FWIW I like the idea to use `init(describing:)`, although it’s still a bit quirky when put side-by-side with `init(reflecting:)` (since it doesn’t really capture the heart of the distinction between the two, IMHO).

···

On May 19, 2016, at 5:57 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Tue May 17 2016, Chris Lattner <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Thanks,

--
-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

I was about to suggest this as well. It seems like the natural name given the CustomStringConvertible protocol requires the description property.

···

On May 17, 2016, at 10:17 PM, Austin Zheng via swift-evolution <swift-evolution@swift.org> wrote:

I like Jacob's suggestion of "init(describing:)", and I also think the review team should consider the global function alternative. My main goal is also preventing silently incorrect code.

Austin

On May 17, 2016, at 10:14 PM, Karl Wagner via swift-evolution <swift-evolution@swift.org> wrote:

I would still prefer a global function; because the output is from reflection, it’s really more for debugging purposes than actually serialising something.

But any change to this gets a +1 from me. It’s too easy to accidentally call this instead of one of the other argument-less initialisers on String.

Karl

On 18 May 2016, at 05:32, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0089: Renaming String.init<T>(_: T)" begins now and runs through May 23. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution