On Apr 2, 2015, at 19:28 , Charles Jenkins <cejw...@gmail.com> wrote: > > So after doing two anchored searches, one at the beginning and one at the end > of the string, if I get two different ranges, I’m stuck with two values that > aren’t subtractable to determine the length of the NSRange I need in a call > to attributedSubstringFromRange().
Not at all. All of this API is *NSString* API, even if the instance happens to be String instead of NSString, so the ranges are NSString-compatible ranges (i.e. UTF16 code value ranges), so you can just do the subtraction and use the result in attributedSubstringFromRange. > I think the safest thing for me to do for attributed string compatibility is > give up on Swift purity and put my range-trimming function in an Objective-C > file. Again, it’s all NSString API, so the results are what the Obj-C API would return. Otherwise, interoperability wouldn’t work. If, additionally, you cast any String-returning result ‘as’ NSString, then you literally are doing Obj-C, though it happens to be created by the Swift compiler. That is to say, it’s going to make Obj-C-style method calls with an Obj-C-NSString-style object as receiver, so the source language is irrelevant. (!) That, or I’ve run wildly off the rails. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
