This seems like an ideal candidate for a compiler (not JVM) intrinsic. The nice thing about standard libraries is that functions from it can be replaced by intrinsics if so desired. Their API’s are kind of frozen by default anyway.
I completely agree. A lot of time I write SQLs, HTML and other similar things in my code. Would be very nice to have such a functionality. And multiline string keeping extra left spaces is just crazy. This create a very strange code or a very strange string. I don’t know what would be the best rule the follow when removing this extra spaces, but I am sure it is possible to figure out some solution.
The “solution” is in the String.trim... functions that you can use to trim as desired. If these functions could now be defined as constexpr and evaluated at compile time your problem would go away. Alternatively, it may be possible to have a compiler plugin that recognizes these specific function calls and in case of a compile time constant parameter replaces it with the result of calling the function - constexpr is a lot cleaner as it is not limited to “special cases”.
Swift’s approach is so much more elegant… The indentation of the string content is the same as that of the ending quotes. Always and without exception, checked and optimized at compile time. What more could you want?
Compile-time trimming is still useful for dynamic strings in my opinion. If the dynamic parts do not contain line breaks, it will work very well.
I agree that there should be an option to do the trimming at runtime. In many use cases, the developer will know whether to expect line breaks in the dynamic parts, and can choose accordingly.
Correct me if I’m wrong but I don’t think tirmMargin or trimIndent are ever used with dynamic multiline strings. I don’t have real numbers for this but I’d imagine that in most cases a multiline string in a dynamic trimMargin is just a bug and not intended, so maybe changing this is not as bad of a breaking change than it seems.
It may also be possible to translate the dynamic bits of the string into a call that is wrapped in its own trim function that can is given the needed information for correct wrapping by the compiler. It would probably be best implemented in an optimistic fashion (assuming that it doesn’t need to wrap).