Hi,
Members of NSString, except those defined in Foundation, are available on
values of type String. For example,
extension NSString {
@objc func foo() {}
}
let s: String = “hello”
s.foo()
We don’t do this for any other bridged types, for instance NSArray methods are
not imported as Array
I would feel better about it if String gained a lot of the utility of NSString
(so that we don’t have to go to NSString all the time for methods)
Thanks,
Jon
> On Oct 24, 2017, at 3:00 PM, Slava Pestov via swift-evolution
> wrote:
>
> Hi,
>
> Members of NSString, except those defined in Foun
Perhaps you could write up a proposal to outline the missing functionality :-)
Slava
> On Oct 24, 2017, at 3:09 PM, Jonathan Hull wrote:
>
> I would feel better about it if String gained a lot of the utility of
> NSString (so that we don’t have to go to NSString all the time for methods)
>
>
I think any serious proposal with the removal of APIs would need to consider
source compatibility and to do so you should likely audit the API surface area
that is being offered (and replace it via the NSStringAPI.swift extension)
> On Oct 24, 2017, at 3:12 PM, Slava Pestov via swift-evolution
I think to maintain source compatibility, the old behavior would be preserved
until/if we remove -swift-version 4 mode. By deprecating it though, we won’t
have to devote as much time to maintaining it going forward.
Slava
> On Oct 24, 2017, at 3:54 PM, Philippe Hausler wrote:
>
> I think any
+1, it's currently really non-obvious where these automatic bridges are
happening which keeps costing me time.
> On 24 Oct 2017, at 11:00 pm, Slava Pestov via swift-evolution
> wrote:
>
> Hi,
>
> Members of NSString, except those defined in Foundation, are available on
> values of type Strin
Sent from my iPad
> On Oct 24, 2017, at 5:55 PM, Slava Pestov via swift-evolution
> wrote:
>
> I think to maintain source compatibility, the old behavior would be preserved
> until/if we remove -swift-version 4 mode. By deprecating it though, we won’t
> have to devote as much time to mainta
> On 25 Oct 2017, at 15:29, Matthew Johnson via swift-evolution
> wrote:
>
>
>
> Sent from my iPad
>
>> On Oct 24, 2017, at 5:55 PM, Slava Pestov via swift-evolution
>> wrote:
>>
>> I think to maintain source compatibility, the old behavior would be
>> preserved until/if we remove -swift
I don’t think anyone is really looking at that at the time but +1 to
bringing NSString functionality to String. This is something that gets
talked about a lot but no one has really sat down to outline what such an
API would look like.
On Wed, Oct 25, 2017 at 3:24 PM, David Hart via swift-evolution
We are definitely looking at it, soon. Right now (working on Swift 4.1), most
of the String focus is on ABI-critical concerns, but better String APIs and
programming models is a focus area for Swift 5.
> On Oct 25, 2017, at 3:34 PM, Kelvin Ma via swift-evolution
> wrote:
>
> I don’t think a
is there a roadmap for strings + unicode in swift 5?
will unicode normalization and other functionality be available in the standard
library?
https://docs.oracle.com/javase/8/docs/api/java/text/Normalizer.html
https://www.unicode.org/reports/tr31/
http://www.unicode.org/reports/tr44/
http://w
A complementary tactic would be that migration tool support to Swift 5 would
insert the needed casts to NSString. That way even if the magic lookup is gone
in Swift 5 the code could be automatically migrated and preserve the same
semantics. If this came to a formal proposal I’d really like to
> On 30 Oct 2017, at 6:16 am, Ted Kremenek via swift-evolution
> wrote:
>
> A complementary tactic would be that migration tool support to Swift 5 would
> insert the needed casts to NSString. That way even if the magic lookup is
> gone in Swift 5 the code could be automatically migrated and
13 matches
Mail list logo
