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)" }
?
···
on Fri May 20 2016, Kevin Ballard <swift-evolution@swift.org> wrote:
On Tue, May 17, 2016, at 08:32 PM, Chris Lattner via swift-evolution wrote:
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.
On Thu, May 19, 2016 at 4:02 PM, Austin Zheng via swift-evolution < swift-evolution@swift.org> wrote:
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`.
We will add a special case in the optimizer to fold these empty
segments when interpolation is invoked on String. It won't affect
other types.
Dmitri
···
On Thu, May 19, 2016 at 6:00 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
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:
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.)
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
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.
It's mostly aesthetics and minimizing redundant API surface area. We
don't love any of the proposed labels for this usage and feel this API
should be substantially lighter-weight than the `reflecting:` one. We
could always go back to providing the global toString() function we once
had, but we don't feel that's a great answer either. Since there's
already another way to do this, we think it's better to remove the API
than reshape it in an unsatisfying way.
···
on Fri May 20 2016, plx <swift-evolution@swift.org> wrote:
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:
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).
>> * 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.
-Kevin Ballard
···
On Fri, May 20, 2016, at 05:14 PM, Dave Abrahams via swift-evolution wrote:
on Fri May 20 2016, Kevin Ballard <swift-evolution@swift.org> wrote:
> On Tue, May 17, 2016, at 08:32 PM, Chris Lattner via swift-evolution wrote:
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)" }
?
Yeah... Perl is back..
Mr Swift o' please, can we have some syntax sugering for this? Please, o' please :)
···
On May 21, 2016, at 2:14 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Fri May 20 2016, Kevin Ballard <swift-evolution@swift.org> wrote:
On Tue, May 17, 2016, at 08:32 PM, Chris Lattner via swift-evolution wrote:
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.
on Thu May 19 2016, Jacob Bandes-Storch <swift-evolution@swift.org> wrote:
On Thu, May 19, 2016 at 4:02 PM, Austin Zheng via swift-evolution < > swift-evolution@swift.org> wrote:
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`.
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
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`.
Considering this idea that swift is concerned with speed, and efficiency, and symetry... this is the LAST thing I would ever expect to happen... you're going to tell us that is does't matter because the compiler is going to parse the string and then realise that this is not a real printf type of interpolation, but is simple convertion?!
Well then lets do it, but in the name of that symetry and economy and efficiency that justifies this one, lets make sure that Int and Float and Double convertions go the same route, right?
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.
It's mostly aesthetics and minimizing redundant API surface area. We
don't love any of the proposed labels for this usage and feel this API
should be substantially lighter-weight than the `reflecting:` one. We
could always go back to providing the global toString() function we once
had, but we don't feel that's a great answer either. Since there's
already another way to do this, we think it's better to remove the API
than reshape it in an unsatisfying way.
I am quite shocked that forcing people to rhink about interpolation can be seen as a more intuitive, more 'swift' soluttion than even a plain-obvious toString()...
···
On May 20, 2016, at 7:44 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Fri May 20 2016, plx <swift-evolution@swift.org> wrote:
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:
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 Fri May 20 2016, Kevin Ballard <swift-evolution@swift.org> 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@swift.org> 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.
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@swift.org> wrote:
on Fri May 20 2016, Kevin Ballard <swift-evolution@swift.org> 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@swift.org> 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.
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().
The function under debate doesn't use the reflection API unless the type doesn't implement any of the related protocols, so calling it reflect(_:) would be very misleading. That name would be much more appropriate as a replacement for String(reflecting:).
-Kevin
···
On Wed, May 25, 2016, at 02:56 PM, Karl Wagner via swift-evolution wrote:
Karl
> On 22 May 2016, at 20:19, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
>
>
> on Fri May 20 2016, Kevin Ballard <swift-evolution@swift.org> 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@swift.org> 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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
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@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@swift.org <javascript:;>> wrote:
>
>
> on Fri May 20 2016, Kevin Ballard <swift-evolution@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@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@swift.org <javascript:;>
> https://lists.swift.org/mailman/listinfo/swift-evolution
