[swift-evolution] [Draft proposal] Faster/lower-level external String initialization

[Max Moiseev]

> I think you should still be able to call an initializer like that with your `swiftApi(String(cString))` example, right? It would just be `swiftApi(String(cString, foo: &otherTupleValue). I thought the proposed alternative would look more like `swiftApi(String.fromCString(cString).0)`

Yes, you can do that, but the variable you pass as inout should be declared somewhere, so you call becomes `var inoutVar: Bool; swiftApi(String(cString, foo: &inoutVar))`. Slightly more complicated, that is.

>  (I’ve lost track at this point about what the exact API proposal is, sorry).
That we are trying to figure out here =)

max

> On Jan 12, 2016, at 5:25 PM, Alex Migicovsky <migi at apple.com> wrote:
> 
> I was trying to say that any tuple returning factory method can be turned into an initializer with an inout param. e.g.
> 
> struct F {
>      func makeF() -> (F?, Int)
> }
> 
> can be made into:
> 
> struct F {
>      init?(inout result: Int) { … }
> }
> 
> I think you should still be able to call an initializer like that with your `swiftApi(String(cString))` example, right? It would just be `swiftApi(String(cString, foo: &otherTupleValue). I thought the proposed alternative would look more like `swiftApi(String.fromCString(cString).0)` (I’ve lost track at this point about what the exact API proposal is, sorry).
> 
> With this approach every time you need to create a String you go through a String initializer—you don’t need to think if it’s a factory method or an initializer. That’s what I was trying to get at about keeping the “initializer story" consistent.
> 
> - Alex
> 
>> On Jan 12, 2016, at 5:01 PM, Max Moiseev <moiseev at apple.com <mailto:moiseev at apple.com>> wrote:
>> 
>> Hi Alex,
>> 
>> If you mean that we still need to have initializers for both cases, we do. It’s just that in one of them (the repairing on) we throw away the information about whether repairs were made, which a) we don’t care in many cases and b) can still have using String.decodeCString.
>> 
>> Having an inout parameter in an initializer will break the (I think) common use case, where you get a CString from some C API, and want to call some Swift API that accepts String. I would do it like `swiftApi(String(cString))`, with inout it gets weird.
>> 
>> What do you think?
>> 
>> max
>> 
>>> On Jan 12, 2016, at 1:00 PM, Alex Migicovsky <migi at apple.com <mailto:migi at apple.com>> wrote:
>>> 
>>> 
>>> On Jan 12, 2016, at 12:08 PM, Max Moiseev via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>>>> It would be nice to get some feedback from someone at Apple as to why fromCString() was implemented as a type method instead of a failable initializer. Presumably it was because there is both a repairing and a failable, non-repairing version. 
>>>> 
>>>> There probably were no failable initializers when it was first implemented. The other thing is `fromCStringRepairingIllFormedUTF8` returns a tuple, so cannot be an initializer.
>>> 
>>> Can the initializer take an inout parameter instead? Seems like it would be better to keep a consistent "initializer story."
>>> 
>>>>> On Jan 12, 2016, at 11:18 AM, Charles Kissinger via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> 
>>>>> It would be nice to get some feedback from someone at Apple as to why fromCString() was implemented as a type method instead of a failable initializer. Presumably it was because there is both a repairing and a failable, non-repairing version. 
>>>>> 
>>>>>> ## Detailed design
>>>>>> 
>>>>>> See [full
>>>>>> implementation](https://github.com/apple/swift/compare/master...zwaldowski:string-from-code-units <https://github.com/apple/swift/compare/master...zwaldowski:string-from-code-units>).
>>>>>> 
>>>>>> This is a fairly straightforward renaming of the internal APIs.
>>>>>> 
>>>>>> The initializer, its labels, and their order were chosen to match other
>>>>>> non-cast
>>>>>> initializers in the stdlib. "Sequence" was removed, as it was a
>>>>>> misnomer.
>>>>>> "input" was kept as a generic name in order to allow for future
>>>>>> refinements.
>>>>>> 
>>>>>> The static initializer made the same changes, but was otherwise kept as
>>>>>> a
>>>>>> factory function due to its multiple return values.
>>>>>> 
>>>>>> `String.Type._fromWellFormedCodeUnitSequence(_:input:)` was kept as-is
>>>>>> for
>>>>>> internal use. I assume it wouldn't be good to expose publicly because,
>>>>>> for
>>>>>> lack of a better phrase, we only "trust" the stdlib to accurately know
>>>>>> the
>>>>>> wellformedness of their code units. Since it is a simple call through,
>>>>>> its
>>>>>> use could be elided throughout the stdlib.
>>>>>> 
>>>>>> ## Impact on existing code
>>>>>> 
>>>>>> This is an additive change to the API.
>>>>>> 
>>>>>> ## Alternatives considered
>>>>>> 
>>>>>> * A protocol-oriented API.
>>>>>> 
>>>>>> Some kind of `func decode<Encoding>(_:)` on `SequenceType`. It's not
>>>>>> really
>>>>>> clear this method would be related to string processing, and would
>>>>>> require
>>>>>> some kind of bounding (like `where Generator.Element:
>>>>>> UnsignedIntegerType`), but
>>>>>> that would be introducing a type bound that doesn't exist on
>>>>>> 
>>>>>> * Do nothing.
>>>>>> 
>>>>>> This seems suboptimal. For many use cases, `String` lacking this
>>>>>> constructor is
>>>>>> a limiting factor on performance for many kinds of pure-Swift
>>>>>> implementations.
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160113/fe557e57/attachment.html>