On Saturday, 21 October 2023 at 06:44:22 UTC, Walter Bright wrote:
> On 10/20/2023 9:42 PM, Steven Schveighoffer wrote:
> Yes and no. It's very clearly geared towards writef (or else we would have some other default other than %s), even though it doesn't require hooking with writef. But in effect, writef and format (and other functions like it, such as loggers) are the only functions it works with "out of the box".
That's no surprise, since Phobos has adopted that style for more than just writef, such as std.format.format(). There's no reason to invent a different one for loggers.
https://dlang.org/phobos/std_format.html#format
Besides, I had modified DIP1027 to enable any format string between { } specifically to accommodate your database use case.
This is woefully inadequate. It requires users to participate in the details of the SQL format that are irrelevant to the function call, and it also allows people to do the wrong thing quite easily, with no compiler help. Statically typed languages are better than this, and especially D is. We don't want to make users have to know how the "sausage is made".
This is why I consider it a failure.
consider the even worse case of postgres -- all parameters require a positional index, so:
INSERT INTO tbl (name, age) VALUES ($1, $2)
Now, the user not only has to change the %s to $N, but they have to maintain the ordering of the indexes manually. These are the kinds of things that people "get used to" because they have no other options. Much better to let the function itself handle the proper placeholders that correspond to the implementation details of the usage.
You might say, "hey, that's just the way it is, you are using postgres". But what about a DB abstraction library? It might want to change the placeholders based on the underlying backend.
> > There are many other functions that use the same style of "blueprint + data" calls which will utterly fail, and can't be made to work with DIP1027.
Example, please. I already showed how to do Adam's example of things that wouldn't work with DIP1027.
The point I was making was that there are no other functions except writef and format that work, or can be made to work, directly with this mechanism (of course, without sausage-making by the user). Even printf requires the user to become involved.
Of course, it is possible to write a completely new function with a new name that will handle (poorly) the puzzle that the compiler constructed in its quirky writef-like way (oh, and make sure you don't change those placeholders, because we can't detect that!)
> > BTW, I count a failure as having to specify the correct substitution as the user. That is the domain of the function or the type system.
I don't know what that means.
The {} thing you mentioned above. It does not suffice as discussed above. The user shouldn't have to be involved with figuring out placeholders when we have a perfectly capable compiler to do it for us.
> > Nobody, and I really truly mean, NOBODY, is clamoring for
better ways to call printf (specifically printf).
Which is too bad. printf has many advantages:
I was saying printf is fine the way it is, nobody needs new ways to call printf.
> > NOBODY
Nobody wanted ImportC, either. However, several people have told me that they have been seduced into using it and found it delightful and very productive. Heck, in another posting I discovered it could be used to translate C code to D!
- Everybody wanted a way to import C directly. It's been probably the most requested language change for D ever. ImportC is turning out to be a great success, and I think it will change D's future for the better.
- People can and do successfully and joyfully use printf. Nobody is asking for more printf capabilities.
- YAIDIP and DIP1036 cover this mechanism way way better than DIP1027 or some special case compiler workaround would.
-Steve
Permalink
Reply
