Closed tyetrask closed 4 months ago
Hi! That's definitely next on the list of things to add, I'm just waiting for the fix for https://github.com/apple/swift/issues/74386 to land in a nightly build as it was causing issues (should be in the next few days)
Ah, wonderful! Thank you so much 🙌 ! I hadn't noticed the crash because in my working fork I had just been replacing StaticString
in the signatures rather than overloading them 😅.
(If it makes sense then to close this issue, please do!)
(Hello and thank you for all of your work on
PlaydateKit
, it's really great!)I wanted to start a discussion around either 1) moving from
StaticString
toString
now that some basic support has landed in Swift Embedded or ifStaticString
is still desirable (for performance/simplicity/memory/? reasons), 2) complementing any initializers/functions that acceptStaticString
with an overload forString
.I've been experimenting with this in my working fork of
PlaydateKit
and so far things seem to be working out pretty well. I'm curious to hear if there's interest in this, and if so, which direction would be preferred. If there's interest and a direction is determined, I would be happy to open pull requests and help move things along! Thanks for reading 🙏!As just one example, for
System.log()
:Current
With
String
instead:Which, of course, allows for potentially useful things like:
(This is a silly example but a more concrete one is e.g. using a dynamically generated
String
as an argument toGraphics.Bitmap(path: ...)
and I'm sure there are potentially many more!)