[swift-evolution] [Review] SE-0027 Expose code unit initializers on String

[Charles Kissinger]

Dave, a few questions below:

> On Feb 15, 2016, at 11:10 AM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:

…

> Heh, well, that's ironic.  Before Swift was released we had all of this
> functionality for unicode transcoding available in the String API, and
> it was decided that to avoid treading into Foundation's territory, any
> functionality already exposed by NSString should not be public API on
> String without Foundation loaded.

Could you explain what went into the decisions about what overlapping functionality was allowed and what was not? There seems to be significant overlapping functionality: fromCString, uppercaseString, and hasPrefix just to name a few redundant methods.

Also, the new functions in the proposal operate on parameters that are Swift types with no equivalent in Obj-C. Is that really treading into Foundation territory?

> I have ambitions that Swift strings will be first-class standalone types
> without the need to rely on Foundation some day soon, but under the
> circumstances we may need a more comprehensive change than merely adding
> fast unicode transcoding to justify treading into this area.

Are all of the Swift stdlib types that bridge to Foundation types (Array, Dictionary, etc.) under similar restrictions about treading on Foundation? I’m surprised by that approach.

> 
>> Is it not a deficiency of the stdlib when code has to resort to
>> non-public methods? 
> 
> Yes.  There are lots of deficiencies in the stdlib.  I'm not saying this
> shouldn't be addressed, but I'm concerned about addressing this in a
> temporary way that we think may be sub-optimal.

Is it the interface or the implementation that you think might be suboptimal? As long as we can settle on a good API, we don’t have to worry about the implementation changing underneath it, do we?

> 
>> The stdlib (i.e., the parts touched by the PR) and corelibs-foundation
>> would have to move in lockstep to adopt a replacement, so the existing
>> underscored versions are as good as public API.
>> 
>> I understand, and 100% encourage, the reticence around new API. However,
>> we've created a worse problem by encouraging slow, buggy, custom
>> versions of behavior that already exists in the stdlib, or implying that
>> the underscored API should be used because we haven't managed something
>> better yet. :/
> 
> I am not reticent to have new API.  I am reticent to accept partial or
> known-suboptimal temporary solutions when we are developing a
> comprehensive plan that ought to address the same problems (among many
> others).

Is the comprehensive String redesign happening in public? I haven’t found anything, but I probably just don’t know where to look.

—CK

> 
> -- 
> -Dave
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution