In response to some recommendations from the Swift 3 plans, the proposed API has been made more comprehensive, and the proposal updated to fit.
The proposal is now PR'ed:
The code is still where it was before:
https://github.com/apple/swift/compare/master...zwaldowski:string-from-code-units
Sent from my iPhone
Zach, Max:
Just a comment on the function and parameter names: decodeCString() doesn’t seem right for the factory function that takes a CollectionType since we aren’t passing in a null-terminated string there. Likewise, the first argument to the corresponding initializer that takes a CollectionType is currently called cString. Should the factory method just be called decode() perhaps, and the argument to the initializer be codeUnits rather than cString?
-CK
On Jan 14, 2016, at 6:02 PM, Zachary Waldowski via swift-evolution <swift-evolution@swift.org> wrote:
In response to some recommendations from the Swift 3 plans, the proposed API has been made more comprehensive, and the proposal updated to fit.
The proposal is now PR'ed:
The code is still where it was before:
https://github.com/apple/swift/compare/master...zwaldowski:string-from-code-units
Sent from my iPhone
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I mostly like the proposal.
However, it seems to me that a single constructor could do the job of both:
init?(cString: UnsafePointer<CChar>, repairingUTF8: Bool = false)
(and similarly for the generic constructor.)
I agree that the static function could be called `decode(_:as:)`.
As for the implementation, I don’t like that the `UnsafePointer<CChar>` constructors choose to crash on a null pointer, when String.fromCString politely returned nil in that situation.
Cheers,
Guillaume Lessard
Zach,
A quick note on usage of @available attribute in your code.
@available(*, deprecated, renamed="init(validatingCString:)”)
`renamed` provides a hint to XCode on how to actually rewrite the code in order for it to compile. It is quite unfortunate really that `renamed` accepts the syntax in a snippet above.
Please change `renamed` to `message`. Message will simply be displayed and expect some action from the developer.
thanks,
max
On Jan 14, 2016, at 6:02 PM, Zachary Waldowski via swift-evolution <swift-evolution@swift.org> wrote:
In response to some recommendations from the Swift 3 plans, the proposed API has been made more comprehensive, and the proposal updated to fit.
The proposal is now PR'ed:
The code is still where it was before:
https://github.com/apple/swift/compare/master...zwaldowski:string-from-code-units
Sent from my iPhone
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Charles -
I shared the same concern, and mention them in the proposal. I thought
`decode(_:as:)` to be too simple to the point of being non-descriptive,
so punted on the issue for now. I was going to circle back today and
revisit it.
Cheers!
Zachary Waldowski
zach@waldowski.me
On Fri, Jan 15, 2016, at 02:09 AM, Charles Kissinger wrote:
Zach, Max:
Just a comment on the function and parameter names: decodeCString()
doesn’t seem right for the factory function that takes a CollectionType
since we aren’t passing in a null-terminated string there. Likewise, the
first argument to the corresponding initializer that takes a
CollectionType is currently called cString. Should the factory method
just be called decode() perhaps, and the argument to the initializer be
codeUnits rather than cString?-CK
> On Jan 14, 2016, at 6:02 PM, Zachary Waldowski via swift-evolution <swift-evolution@swift.org> wrote:
>
> In response to some recommendations from the Swift 3 plans, the proposed API has been made more comprehensive, and the proposal updated to fit.
>
> The proposal is now PR'ed:
>
> Proposal: String from code units API by zwaldowski · Pull Request #101 · apple/swift-evolution · GitHub
>
> The code is still where it was before:
>
> https://github.com/apple/swift/compare/master...zwaldowski:string-from-code-units
>
> Sent from my iPhone
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
Hi Guillaume,
If we squash initializer with a default Bool = false, it will mean that the most common use case (i.e. repairing a cstring) will result in String? and will have to be (most of the time blindly) unwrapped.
As for passing nil, there are plans to make UnsafePointer non nil (and represent a nil case by Optional<UnsafePointer>.None), so an explicit nullness check is preferred before the call.
max
On Jan 15, 2016, at 12:03 PM, Guillaume Lessard via swift-evolution <swift-evolution@swift.org> wrote:
I mostly like the proposal.
However, it seems to me that a single constructor could do the job of both:init?(cString: UnsafePointer<CChar>, repairingUTF8: Bool = false)
(and similarly for the generic constructor.)
I agree that the static function could be called `decode(_:as:)`.
As for the implementation, I don’t like that the `UnsafePointer<CChar>` constructors choose to crash on a null pointer, when String.fromCString politely returned nil in that situation.
Cheers,
Guillaume Lessard_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I've made that change and the `codeUnits` split, but am waiting on
the tests before I update the branch. The proposal has been updated
and pushed.
Happy Friday! Zach Waldowski zach@waldowski.me
On Fri, Jan 15, 2016, at 06:15 PM, Max Moiseev wrote:
Zach,
A quick note on usage of @available attribute in your code.
@available(*, deprecated, renamed="init(validatingCString:)”)
`renamed` provides a hint to XCode on how to actually rewrite the code
in order for it to compile. It is quite unfortunate really that
`renamed` accepts the syntax in a snippet above. Please change
`renamed` to `message`. Message will simply be displayed and expect
some action from the developer.thanks, max
On Jan 14, 2016, at 6:02 PM, Zachary Waldowski via swift-evolution >> <swift-evolution@swift.org> wrote:
In response to some recommendations from the Swift 3 plans, the
proposed API has been made more comprehensive, and the proposal
updated to fit.The proposal is now PR'ed:
The code is still where it was before:
https://github.com/apple/swift/compare/master...zwaldowski:string-from-code-units
Sent from my iPhone
_______________________________________________
swift-evolution mailing list swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Good catch!
I would not be too worried about `decode`, as it will be called qualified as `String.decode(_:as:)`.
After a quick discussion with @gribozavr, I think we’re ok with having String.decode(_:as:) accepting a CollectionType (with a name recommended by Charles, i.e. codeUnits) and String.decodeCString(_:as:) accepting an UnsafePointer. The difference between the two functions is significant enough to warrant different names even though, for now, one can be implemented using the other.
max
On Jan 15, 2016, at 9:09 AM, Zach Waldowski <zach@waldowski.me> wrote:
Charles -
I shared the same concern, and mention them in the proposal. I thought
`decode(_:as:)` to be too simple to the point of being non-descriptive,
so punted on the issue for now. I was going to circle back today and
revisit it.Cheers!
Zachary Waldowski
zach@waldowski.meOn Fri, Jan 15, 2016, at 02:09 AM, Charles Kissinger wrote:
Zach, Max:
Just a comment on the function and parameter names: decodeCString()
doesn’t seem right for the factory function that takes a CollectionType
since we aren’t passing in a null-terminated string there. Likewise, the
first argument to the corresponding initializer that takes a
CollectionType is currently called cString. Should the factory method
just be called decode() perhaps, and the argument to the initializer be
codeUnits rather than cString?-CK
On Jan 14, 2016, at 6:02 PM, Zachary Waldowski via swift-evolution <swift-evolution@swift.org> wrote:
In response to some recommendations from the Swift 3 plans, the proposed API has been made more comprehensive, and the proposal updated to fit.
The proposal is now PR'ed:
The code is still where it was before:
https://github.com/apple/swift/compare/master...zwaldowski:string-from-code-units
Sent from my iPhone
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Charles -
I shared the same concern, and mention them in the proposal. I thought
`decode(_:as:)` to be too simple to the point of being non-descriptive,
so punted on the issue for now. I was going to circle back today and
revisit it.
The only other decent alternative I’ve been able to come up with is decodeUTF().
-CK
On Jan 15, 2016, at 9:09 AM, Zach Waldowski <zach@waldowski.me> wrote:
Cheers!
Zachary Waldowski
zach@waldowski.meOn Fri, Jan 15, 2016, at 02:09 AM, Charles Kissinger wrote:
Zach, Max:
Just a comment on the function and parameter names: decodeCString()
doesn’t seem right for the factory function that takes a CollectionType
since we aren’t passing in a null-terminated string there. Likewise, the
first argument to the corresponding initializer that takes a
CollectionType is currently called cString. Should the factory method
just be called decode() perhaps, and the argument to the initializer be
codeUnits rather than cString?-CK
On Jan 14, 2016, at 6:02 PM, Zachary Waldowski via swift-evolution <swift-evolution@swift.org> wrote:
In response to some recommendations from the Swift 3 plans, the proposed API has been made more comprehensive, and the proposal updated to fit.
The proposal is now PR'ed:
The code is still where it was before:
https://github.com/apple/swift/compare/master...zwaldowski:string-from-code-units
Sent from my iPhone
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
For that there is a counter-example, consider an invocation: String.decodeUTF(whatever, as: UTF8.self). There is clear duplication of ‘UTF’ here.
On Jan 15, 2016, at 10:41 AM, Charles Kissinger <crk@akkyra.com> wrote:
On Jan 15, 2016, at 9:09 AM, Zach Waldowski <zach@waldowski.me> wrote:
Charles -
I shared the same concern, and mention them in the proposal. I thought
`decode(_:as:)` to be too simple to the point of being non-descriptive,
so punted on the issue for now. I was going to circle back today and
revisit it.The only other decent alternative I’ve been able to come up with is decodeUTF().
-CKCheers!
Zachary Waldowski
zach@waldowski.meOn Fri, Jan 15, 2016, at 02:09 AM, Charles Kissinger wrote:
Zach, Max:
Just a comment on the function and parameter names: decodeCString()
doesn’t seem right for the factory function that takes a CollectionType
since we aren’t passing in a null-terminated string there. Likewise, the
first argument to the corresponding initializer that takes a
CollectionType is currently called cString. Should the factory method
just be called decode() perhaps, and the argument to the initializer be
codeUnits rather than cString?-CK
On Jan 14, 2016, at 6:02 PM, Zachary Waldowski via swift-evolution <swift-evolution@swift.org> wrote:
In response to some recommendations from the Swift 3 plans, the proposed API has been made more comprehensive, and the proposal updated to fit.
The proposal is now PR'ed:
The code is still where it was before:
https://github.com/apple/swift/compare/master...zwaldowski:string-from-code-units
Sent from my iPhone
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
With pointers, there some kind of nullness check either way; I would personally prefer to do it on an optional String than a probable Pointer. I guess it’s just a matter of picking a poison.
As an aside, is the planned non-nilness also to become a rule for UnsafeMutablePointer?
Guillaume Lessard
On 15 janv. 2016, at 15:56, Max Moiseev <moiseev@apple.com> wrote:
Hi Guillaume,
If we squash initializer with a default Bool = false, it will mean that the most common use case (i.e. repairing a cstring) will result in String? and will have to be (most of the time blindly) unwrapped.
As for passing nil, there are plans to make UnsafePointer non nil (and represent a nil case by Optional<UnsafePointer>.None), so an explicit nullness check is preferred before the call.
The names of methods don't need to be descriptive. It's the use-sites
(and secondarily, declarations) that need to be clear. Trying to make
the names of methods descriptive by themselves just hurts readability at
the use-site.
-Dave
on Fri Jan 15 2016, Zach Waldowski via swift-evolution <swift-evolution-m3FHrko0VLzYtjvyW6yDsg-AT-public.gmane.org> wrote:
Charles -
I shared the same concern, and mention them in the proposal. I thought
`decode(_:as:)` to be too simple to the point of being
non-descriptive,
Hi Guillaume,
If we squash initializer with a default Bool = false, it will mean that the most common use case (i.e. repairing a cstring) will result in String? and will have to be (most of the time blindly) unwrapped.
As for passing nil, there are plans to make UnsafePointer non nil (and represent a nil case by Optional<UnsafePointer>.None), so an explicit nullness check is preferred before the call.
With pointers, there some kind of nullness check either way; I would personally prefer to do it on an optional String than a probable Pointer. I guess it’s just a matter of picking a poison.
Another point is, you will have 2 checks then: one inside the function and one outside of it. Versus a single check upfront.
As an aside, is the planned non-nilness also to become a rule for UnsafeMutablePointer?
Right now UnsafePointer and UnsafeMutablePointer are the same thing essentially. So I would expect...
On Jan 15, 2016, at 3:06 PM, Guillaume Lessard <glessard@tffenterprises.com> wrote:
On 15 janv. 2016, at 15:56, Max Moiseev <moiseev@apple.com> wrote:
Guillaume Lessard
The precondition involves a check, so there’s 2 checks either way. Either a) you check for a null pointer before, then the function does it again before deciding whether to crash, or b) the function checks it before deciding whether to return Optional.None, and then you have to unwrap the optional...
Cheers,
Guillaume Lessard
On 15 janv. 2016, at 16:15, Max Moiseev <moiseev@apple.com> wrote:
On Jan 15, 2016, at 3:06 PM, Guillaume Lessard <glessard@tffenterprises.com> wrote:
With pointers, there some kind of nullness check either way; I would personally prefer to do it on an optional String than a probable Pointer. I guess it’s just a matter of picking a poison.
Another point is, you will have 2 checks then: one inside the function and one outside of it. Versus a single check upfront.
Thanks, Dave.
I definitely wasn't hard to convince on this. The change has already
been made to the proposal, its PR, and the pending PR to the stdlib.
Cheers!
Zach Waldowski
zach@waldowski.me
On Wed, Jan 20, 2016, at 01:23 PM, Dave Abrahams via swift-evolution wrote:
on Fri Jan 15 2016, Zach Waldowski via swift-evolution > <swift-evolution-m3FHrko0VLzYtjvyW6yDsg-AT-public.gmane.org> wrote:
> Charles -
>
> I shared the same concern, and mention them in the proposal. I thought
> `decode(_:as:)` to be too simple to the point of being
> non-descriptive,The names of methods don't need to be descriptive. It's the use-sites
(and secondarily, declarations) that need to be clear. Trying to make
the names of methods descriptive by themselves just hurts readability at
the use-site.-Dave
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Since this seems to have gone quiet, and the code was already done, I've
posted the PR to Swift itself:
https://github.com/apple/swift/pull/1109
The existing proposal PR:
--
Sincerely,
Zachary Waldowski
zach@waldowski.me
On Wed, Jan 20, 2016, at 06:08 PM, Zach Waldowski via swift-evolution wrote:
Thanks, Dave.
I definitely wasn't hard to convince on this. The change has already
been made to the proposal, its PR, and the pending PR to the stdlib.Cheers!
Zach Waldowski
zach@waldowski.meOn Wed, Jan 20, 2016, at 01:23 PM, Dave Abrahams via swift-evolution > wrote:
>
> on Fri Jan 15 2016, Zach Waldowski via swift-evolution > > <swift-evolution-m3FHrko0VLzYtjvyW6yDsg-AT-public.gmane.org> wrote:
>
> > Charles -
> >
> > I shared the same concern, and mention them in the proposal. I thought
> > `decode(_:as:)` to be too simple to the point of being
> > non-descriptive,
>
> The names of methods don't need to be descriptive. It's the use-sites
> (and secondarily, declarations) that need to be clear. Trying to make
> the names of methods descriptive by themselves just hurts readability at
> the use-site.
>
> -Dave
>
> _______________________________________________
> 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
It occurred to me that this proposal provides a way to efficiently initialize Strings from UTF code unit sequences, but it doesn’t provide a way to *append* code unit sequences to existing strings. String has an existing method to append Character sequences:
String.appendContentsOf<S : SequenceType where S.Generator.Element == Character>(_: S)
The equivalent for code units would presumably be:
String.appendContentsOf<S : SequenceType, Encoding: UnicodeCodecType where Encoding.CodeUnit == Input.Generator.Element>(_: S, encoding: Encoding.Type)
Is there any interest in adding that to the proposal? It would only have a lot of value if it could be implemented in a more efficient way than just calling String.Append() for each decoded Character. From looking at the code, that might not be straightforward.
—CK
On Jan 26, 2016, at 3:14 PM, Zach Waldowski via swift-evolution <swift-evolution@swift.org> wrote:
Since this seems to have gone quiet, and the code was already done, I've
posted the PR to Swift itself:https://github.com/apple/swift/pull/1109
The existing proposal PR:
--
Sincerely,
Zachary Waldowski
zach@waldowski.meOn Wed, Jan 20, 2016, at 06:08 PM, Zach Waldowski via swift-evolution > wrote:
Thanks, Dave.
I definitely wasn't hard to convince on this. The change has already
been made to the proposal, its PR, and the pending PR to the stdlib.Cheers!
Zach Waldowski
zach@waldowski.meOn Wed, Jan 20, 2016, at 01:23 PM, Dave Abrahams via swift-evolution >> wrote:
on Fri Jan 15 2016, Zach Waldowski via swift-evolution >>> <swift-evolution-m3FHrko0VLzYtjvyW6yDsg-AT-public.gmane.org> wrote:
Charles -
I shared the same concern, and mention them in the proposal. I thought
`decode(_:as:)` to be too simple to the point of being
non-descriptive,The names of methods don't need to be descriptive. It's the use-sites
(and secondarily, declarations) that need to be clear. Trying to make
the names of methods descriptive by themselves just hurts readability at
the use-site.-Dave
_______________________________________________
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
Due to the semantics of _StringCore and _StringBuffer (as far as I
understand them), such a method would not be more efficient than
creating another String with the new initializer and concatenating the
two, and would require more significant plumbing changes to
_StringBuffer.
It would be good to shop around for this proposal, though; maybe if
someone on the core team wants to chime in.
Cheers,
Zachary Waldowski
zach@waldowski.me
On Mon, Feb 1, 2016, at 03:07 AM, Charles Kissinger wrote:
It occurred to me that this proposal provides a way to efficiently
initialize Strings from UTF code unit sequences, but it doesn’t provide a
way to *append* code unit sequences to existing strings. String has an
existing method to append Character sequences:String.appendContentsOf<S : SequenceType where S.Generator.Element ==
>(_: S)The equivalent for code units would presumably be:
String.appendContentsOf<S : SequenceType, Encoding: UnicodeCodecType
where Encoding.CodeUnit == Input.Generator.Element>(_: S, encoding:
Encoding.Type)Is there any interest in adding that to the proposal? It would only have
a lot of value if it could be implemented in a more efficient way than
just calling String.Append() for each decoded Character. From looking at
the code, that might not be straightforward.—CK
> On Jan 26, 2016, at 3:14 PM, Zach Waldowski via swift-evolution <swift-evolution@swift.org> wrote:
>
> Since this seems to have gone quiet, and the code was already done, I've
> posted the PR to Swift itself:
>
> [stdlib] String from code units API by zwaldowski · Pull Request #1109 · apple/swift · GitHub
>
> The existing proposal PR:
>
> Proposal: String from code units API by zwaldowski · Pull Request #101 · apple/swift-evolution · GitHub
>
> --
> Sincerely,
> Zachary Waldowski
> zach@waldowski.me
>
> On Wed, Jan 20, 2016, at 06:08 PM, Zach Waldowski via swift-evolution > > wrote:
>> Thanks, Dave.
>>
>> I definitely wasn't hard to convince on this. The change has already
>> been made to the proposal, its PR, and the pending PR to the stdlib.
>>
>> Cheers!
>> Zach Waldowski
>> zach@waldowski.me
>>
>> On Wed, Jan 20, 2016, at 01:23 PM, Dave Abrahams via swift-evolution > >> wrote:
>>>
>>> on Fri Jan 15 2016, Zach Waldowski via swift-evolution > >>> <swift-evolution-m3FHrko0VLzYtjvyW6yDsg-AT-public.gmane.org> wrote:
>>>
>>>> Charles -
>>>>
>>>> I shared the same concern, and mention them in the proposal. I thought
>>>> `decode(_:as:)` to be too simple to the point of being
>>>> non-descriptive,
>>>
>>> The names of methods don't need to be descriptive. It's the use-sites
>>> (and secondarily, declarations) that need to be clear. Trying to make
>>> the names of methods descriptive by themselves just hurts readability at
>>> the use-site.
>>>
>>> -Dave
>>>
>>> _______________________________________________
>>> 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
Due to the semantics of _StringCore and _StringBuffer (as far as I
understand them), such a method would not be more efficient than
creating another String with the new initializer and concatenating the
two, and would require more significant plumbing changes to
_StringBuffer.
We are very interested in making significant plumbing changes to String, FWIW.
on Mon Feb 01 2016, Zach Waldowski <swift-evolution@swift.org> wrote:
It would be good to shop around for this proposal, though; maybe if
someone on the core team wants to chime in.Cheers,
Zachary Waldowski
zach@waldowski.meOn Mon, Feb 1, 2016, at 03:07 AM, Charles Kissinger wrote:
It occurred to me that this proposal provides a way to efficiently
initialize Strings from UTF code unit sequences, but it doesn’t provide a
way to *append* code unit sequences to existing strings. String has an
existing method to append Character sequences:String.appendContentsOf<S : SequenceType where S.Generator.Element ==
>(_: S)The equivalent for code units would presumably be:
String.appendContentsOf<S : SequenceType, Encoding: UnicodeCodecType
where Encoding.CodeUnit == Input.Generator.Element>(_: S, encoding:
Encoding.Type)Is there any interest in adding that to the proposal? It would only have
a lot of value if it could be implemented in a more efficient way than
just calling String.Append() for each decoded Character. From looking at
the code, that might not be straightforward.—CK
> On Jan 26, 2016, at 3:14 PM, Zach Waldowski via swift-evolution <swift-evolution@swift.org> wrote:
>
> Since this seems to have gone quiet, and the code was already done, I've
> posted the PR to Swift itself:
>
> [stdlib] String from code units API by zwaldowski · Pull Request #1109 · apple/swift · GitHub
>
> The existing proposal PR:
>
> Proposal: String from code units API by zwaldowski · Pull Request #101 · apple/swift-evolution · GitHub
>
> --
> Sincerely,
> Zachary Waldowski
> zach@waldowski.me
>
> On Wed, Jan 20, 2016, at 06:08 PM, Zach Waldowski via swift-evolution >> > wrote:
>> Thanks, Dave.
>>
>> I definitely wasn't hard to convince on this. The change has already
>> been made to the proposal, its PR, and the pending PR to the stdlib.
>>
>> Cheers!
>> Zach Waldowski
>> zach@waldowski.me
>>
>> On Wed, Jan 20, 2016, at 01:23 PM, Dave Abrahams via swift-evolution >> >> wrote:
>>>
>>> on Fri Jan 15 2016, Zach Waldowski via swift-evolution >> >>> <swift-evolution-m3FHrko0VLzYtjvyW6yDsg-AT-public.gmane.org> wrote:
>>>
>>>> Charles -
>>>>
>>>> I shared the same concern, and mention them in the proposal. I thought
>>>> `decode(_:as:)` to be too simple to the point of being
>>>> non-descriptive,
>>>
>>> The names of methods don't need to be descriptive. It's the use-sites
>>> (and secondarily, declarations) that need to be clear. Trying to make
>>> the names of methods descriptive by themselves just hurts readability at
>>> the use-site.
>>>
>>> -Dave
>>>
>>> _______________________________________________
>>> 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_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
--
-Dave
Due to the semantics of _StringCore and _StringBuffer (as far as I
understand them), such a method would not be more efficient than
creating another String with the new initializer and concatenating the
two, and would require more significant plumbing changes to
_StringBuffer.We are very interested in making significant plumbing changes to String, FWIW.
In that case, perhaps it would make sense to add String.append() for code unit sequences over the exiting plumbing just for completeness of the API, on the assumption that efficiency would come later when String gets its makeover.
—CK
On Feb 1, 2016, at 2:07 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Mon Feb 01 2016, Zach Waldowski <swift-evolution@swift.org> wrote:
It would be good to shop around for this proposal, though; maybe if
someone on the core team wants to chime in.Cheers,
Zachary Waldowski
zach@waldowski.meOn Mon, Feb 1, 2016, at 03:07 AM, Charles Kissinger wrote:
It occurred to me that this proposal provides a way to efficiently
initialize Strings from UTF code unit sequences, but it doesn’t provide a
way to *append* code unit sequences to existing strings. String has an
existing method to append Character sequences:String.appendContentsOf<S : SequenceType where S.Generator.Element ==
>(_: S)The equivalent for code units would presumably be:
String.appendContentsOf<S : SequenceType, Encoding: UnicodeCodecType
where Encoding.CodeUnit == Input.Generator.Element>(_: S, encoding:
Encoding.Type)Is there any interest in adding that to the proposal? It would only have
a lot of value if it could be implemented in a more efficient way than
just calling String.Append() for each decoded Character. From looking at
the code, that might not be straightforward.—CK
On Jan 26, 2016, at 3:14 PM, Zach Waldowski via swift-evolution <swift-evolution@swift.org> wrote:
Since this seems to have gone quiet, and the code was already done, I've
posted the PR to Swift itself:[stdlib] String from code units API by zwaldowski · Pull Request #1109 · apple/swift · GitHub
The existing proposal PR:
--
Sincerely,
Zachary Waldowski
zach@waldowski.meOn Wed, Jan 20, 2016, at 06:08 PM, Zach Waldowski via swift-evolution >>>> wrote:
Thanks, Dave.
I definitely wasn't hard to convince on this. The change has already
been made to the proposal, its PR, and the pending PR to the stdlib.Cheers!
Zach Waldowski
zach@waldowski.meOn Wed, Jan 20, 2016, at 01:23 PM, Dave Abrahams via swift-evolution >>>>> wrote:
on Fri Jan 15 2016, Zach Waldowski via swift-evolution >>>>>> <swift-evolution-m3FHrko0VLzYtjvyW6yDsg-AT-public.gmane.org> wrote:
Charles -
I shared the same concern, and mention them in the proposal. I thought
`decode(_:as:)` to be too simple to the point of being
non-descriptive,The names of methods don't need to be descriptive. It's the use-sites
(and secondarily, declarations) that need to be clear. Trying to make
the names of methods descriptive by themselves just hurts readability at
the use-site.-Dave
_______________________________________________
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_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution--
-Dave_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution