Avoid unnecessary template

[ryuukk]

No description provided.

[dlang-bot]

Thanks for your pull request and interest in making D better, @ryuukk! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#16982"

[ryuukk]

@dkorpel

Perhaps the right approach is to update the format function in chkformat.d so it understands D's strings?

edit:

looks like dmd just validates the strings it passes to printf, lol

[RazvanN7]

src/dmd/root/string.d(29): Error: no property `fTuple` for `str` of type `const(char)[]`

[dkorpel]

Perhaps the right approach is to update the format function in chkformat.d so it understands D's strings?

You can't pass D slices to C-style variadic arguments. Even if you change that, the compiler is still being compiled with dmd version 2.079, so dmd's source can't rely on new features.

The motivation for the helper function is:

• Reduce argument list length (notice how this PR bumps lines past 120 columns)
• Extract side effects (toString().length, toString().ptr calls toString twice)
• Ease future refactoring (when e.g. transitioning from C-style to D-style variadics, it becomes easy to adapt arguments)

What's the motivation for removing it in this PR?

[ryuukk]

Reading library.filename.fTuple.expand means nothing, yet hides ton of complexity, argument count will be 2 instead of 1

The code that uses it is not complex, it doesn't justify it, you mention issues that are non existent in your PR

The only way to prevent the future issues you mention is to make the function understand what a D string is, not to tell people to instead rely on this cryptic code

[dkorpel]

Reading library.filename.fTuple.expand means nothing, yet hides ton of complexity, argument count will be 2 instead of 1

I don't think a length, ptr pair is a ton of complexity. Perhaps fTuple is a bit cryptic on first read, but printfStringTuple is a bit long for something that is supposed to make string passing more convenient. I'm open to better names.

you mention issues that are non existent in your PR

There's refactoring PRs converting C strings to D strings all the time. The idea is that it can be used for future PRs as well, not just the one PR that introduced it.

The only way to prevent the future issues you mention is to make the function understand what a D string is, not to tell people to instead rely on this cryptic code

I want to, believe me, but for the time being we're stuck with printf and C variadics.

I don't think this is worth discussing at length, perhaps @RazvanN7 and @thewilsonator can weigh in on whether it is too obfuscating, and if it is, we can merge this and I'll stop refactoring printf calls like this.

[dkorpel]

This entire unittest should be removed, without fTuple it's moot

[thewilsonator]

does alias expand this; work here? if so we should use it and give FTuple a less cryptic name.

[dkorpel]

I tried, but they won't auto expand in C-style variadic argument lists

[dkorpel]

Perhaps str.lengthPtr.expand is clearer?