-
-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Default values with UnsafeRawPointers do not compile #55
Comments
Hi @kkiermasz 馃憢 Good catch, thanks for raising this! I haven't actually used I have however been looking into some improvements around this part of how we generate the (I should mention that I only added parsing support for The With that in mind, I think that we can work out the exact behaviour that we want by testing the let arg: UnsafeRawPointer = ...
let value: String.LocalizationValue = "Test \(arg)"
dump(value) I think that this is because the https://developer.apple.com/documentation/swift/string/localizationvalue/stringinterpolation From what I can see, there are three overloads of interest to us that accept different values:
It seems that Note A note about the private /Applications/Xcode-15.2.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS17.2.sdk/System/Library/Frameworks/Foundation.framework/Modules/Foundation.swiftmodule/arm64-apple-ios.swiftinterface Here is the important stuff
So, with this in mind, I am not sure how to proceed 馃槃 I have a few ideas though:
I hope that this brain-dump helps 馃槃 As I don't really use this feature myself, I am not sure what the best option is so it would be great to hear your thoughts! Thanks 馃檹 |
Hey @liamnichols 馃憢馃徎 , wow, thanks for the response 馃槃 I'm not using them either. I was checking the library condition before adding it to the project 馃槢 The screenshot is from the test snapshot. Thanks for the reference, now I see it's not support out-of-the-box :) Since I'm not a String expert (which is a complex topic), I'm not voting for any of the 4 solutions you mentioned 馃珷 I just thought it might be worth mentioning this in the documentation in some "limitations" section, since someone will probably encounter this problem later. Btw it's a pity that there's no way (or I'm the reason in this case :D) to use one shared catalog across multiple feature modules, as Apple invented (View -> Catalog -> .strings), I'd give it a try. |
Btw did you notice any performance issues? One SwiftUI view (re)render causes ~2.4k LocalizedStringResource resolve attempts, each taking ~0.00016s. I wonder if that's because the tool (catalogs itself) was not designed to expose resources publicly :/ When using the old .strings in the same shared module with It's unusable (LocalizedStringResource) with this performance tbh I know it's not on your side, as I would assume SwiftUI is caching resources data or smth similar, but passing resources to the views was triggering the above issue. As I have some complex views it impacts performance too much. I made a fork and changed the file generation to something similar to SwiftGen. https://github.com/kkiermasz/xcstrings-tool/blob/main/Tests/XCStringsToolTests/__Snapshots__/GenerateTests/testGenerateWithPackageAccessLevel.Localizable.swift Who's brain-dumping now? Haha |
Ahh right I see, that's a good strategy 馃檪
Ooooh, good spot. I opened #56 to keep on top of that in the future.
Well now that I've had a think about it, I think that I am going to peruse option 3 and remove direct support for I believe that option 4 would then be the viable workaround for anybody that did need to use this kind of formatting... I'll keep this issue open to track that 馃憤
I'm not quite sure if I understood what you are trying to achieve here, but does using the
As for this - not yet. I haven't personally used XCStrings Tool in any complex SwiftUI projects where it has become a concern. I'm not quite sure of the solution to this though because my understanding is that the purpose of Maybe it isn't common usage though, and in that case, caching the resolved strings might be a better option, but I don't think it's a good default. I think that it probably needs some more investigation though, so thanks for flagging it.. Perhaps you can open a separate issue to track this? There might be some ways that we can optimise the generated code more, or maybe at least add some best practice documentation 馃檹 |
Hi there,
First of all, I'm really glad you've created this, even though I'm scared to add any new dependencies to the project because Swift 6 is close, I'll give it a try 馃槄
I found an issue with
%s
and%p
parameters.I wanted to fix it by myself and open a PR, but it's the first time I've seen
###
formatting, so I guess you know what to do better and faster :)Btw you might want to create 0.1.3 anyway, as some handy fixes to the documentation were added since 0.1.2 馃枛馃徎
The text was updated successfully, but these errors were encountered: