Should we add more mutating methods to `StaticString`?

(Adrian Zubarev) #1

I'm currently playing around with a custom Swift wrapper around the logging API from os.activity module and I'm hitting two issues related to StaticString. For security reasons the os.activity API can only accept static strings which limits its functionality. Now I would like to create an activity that print's the owning type and some methods that are called on the instance to create a deep nested structure.

The following image is just an example what I want to achieve at some point:

Two things that are missing:

  • #Self to extract Observable<Int> from the generic type where the activity would be instantiated.
  • Ability to concatenate multiple static strings to do the following #Self + "." + #function:
extension StaticString {
  static func + (lhs: StaticString, rhs: StaticString) -> StaticString {

I think it's reasonable to extend the API of StaticString to allow mutation with other static strings. Furthermore I think string interpolation should also work iff all interpolated values are also static strings.


Edit - Related topics:

Add #self, #Self to #function, #file, #line, #column
(Jordan Rose) #2

StaticString doesn't just mean "not from user input"; it means "actual compile-time literal". That's fundamentally incompatible with +-like operations until we get support for constant expressions.

(Adrian Zubarev) #3

That makes total sense, but you agree that we could and maybe should allow mutation of static strings with other static strings?

(Jordan Rose) #4

Tentatively yes. In C you use the preprocessor to build up strings that are nonetheless static; this would be a nicer answer. I'm not sure at all how you'd implement it, though—it might have to be some kind of builtin anyway.

(Adrian Zubarev) #5

Other than that, how would #Self work actually? Can we extract the concrete generic type from within a type? If so can we do the same for generic type parameters in general?

func work<T>(_ type: #type(T)) { ... }

(Jordan Rose) #6

That part you're stuck on. You can't get the name of a concrete generic type at compile time within a generic function in today's Swift, because it could always be called with some new type at run time. It's possible that that restriction could be lifted if work were only allowed to be called at compile-time, but otherwise this isn't something you can use with os.activity directly, which is a correct restriction.

(Adrian Zubarev) #7

Okay so it‘s just an API limitation then. os_log on the other hand allows more infos through args and static strings with formats like “%{private}s“. I need to file a rdar for that one.