Live data from Hacker News

Swift UTF-8 String

swift.org

41–50 of 97 posts

Re: Swift UTF-8 String

#41
post #26

Earlier quoted context omitted.

It doesn't matter what people think, rather CS definition. Software Engineering is not about what people think, rather what is technically correct.

Well.. what is technically correct depends on a definition. And there are customary/practical definitions too. And sometimes definitions are tainted by context, like in "is this gc or ref counting language".

Which should be "is this tracing GC or ref counting language".

Naturally when in some juriditions one is allowed to call themselves engineers after a 6 months bootcamp we land in such customary/practical definitions.

Re: Swift UTF-8 String

#44
I have never written a single line of iOS/macos code, but I'm interested in Swift because it's a cool language.

Can anyone explain why this is done now and not when Swift was first released? I mean, UTF-8 was already the clear winner when Swift started. Is it some obj-c compat story?

Re: Swift UTF-8 String

#45
post #42

Earlier quoted context omitted.

This one https://www.swiftcommunitypodcast.org/

As far as I can tell, that podcast was started earlier this year, and is still active?

Right, I was wrong about the start date, on my mind it was started in December.

As for being active, no signs of life since 08th February, more than one month without updates.

Re: Swift UTF-8 String

#46

Great work by the Swift team on stabilizing this (especially around UTF-8) for Swift 5. One question: how do Objective-C's tagged NSString pointers fit into this? Are these imported as "opaque" strings? I see that _SmallString seems to store its characters inline; are there any plans to do tagged pointers in Swift as well?

”An opaque string is capable of handling all string operations through resilient function calls. […] Currently, these are used for lazily-bridged NSStrings that do not provide access to contiguous UTF-8 (i.e. ASCII) bytes in memory.”

⇒ it seems tagged NSString pointers indeed map to opaque strings.

Because strings are structs in Swift, I don’t expect them to implement tagged pointers in Swift. Alternatively, you can see the SmallString struct as a tagged pointer that’s twice as large as a regular pointer.

Re: Swift UTF-8 String

#47
post #34

Wise move, in my opinion. I hope Python will do that too, eventually.

Python implemented multi-representation strings in 3.3. It picks the best encoding from ASCII, UTF8, UCS2, or UCS4. UTF8 is the preferred encoding for strings exposed to the C API.

https://www.python.org/dev/peps/pep-0393/

Re: Swift UTF-8 String

#48
post #45

Earlier quoted context omitted.

As far as I can tell, that podcast was started earlier this year, and is still active?

Right, I was wrong about the start date, on my mind it was started in December. As for being active, no signs of life since 08th February, more than one month without updates.

There's still stuff going on on the GitHub repository: https://github.com/SwiftCommunityPodcast/podcast

Re: Swift UTF-8 String

#50

Earlier quoted context omitted.

It really depends on what you're doing. A lot of the time, neither garbage collection pauses nor reference cycles are an issue; and when they are it's typical that one or the other will solve the issue.

If GC pauses aren't an issue for your app then you're better off with a full-blown GC because it's a lot easier to code for. Reference counting, as used in Swift, forces you to think a lot about cases where you might be creating reference cycles and memory leaks. GCs can figure this out for you and take that burden off the programmer.

One of the major advantages of reference counting is that it's easier to integrate with other languages. For example you can manipulate Swift objects from C via CoreFoundation, which then allows them to be used from C++, Rust, whatever.

GC'd languages have some support (JNI, etc) but they require handles, pinning, write barriers, etc. which ends up being more complicated and less flexible.

Post reply on HN