On Thursday, 27 June 2013 at 13:11:55 UTC, Andrej Mitrovic wrote:
> I mistyped that, I meant:
>
> format("%s", 1, 2);  // no exceptions in future release
> safeFormat("%s", 1, 2);  // exception thrown

I think if there's going to be a new function anyway, it might as well be more like the ctFormat bearophile mentioned, and check it at compile time.

On 6/27/13, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> On 6/27/13, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>> NO! This is exactly the kind of code that is buggy and useless. The right use cases involve more arguments than format specifiers.
>
> I mistyped that, I meant:
>
> format("%s", 1, 2);  // no exceptions in future release
> safeFormat("%s", 1, 2);  // exception thrown

I'll add that the exception throwing was not introduced v2.000 (because my test-case was wrong), but was introduced in 2.062:

std.format.FormatException@C:\dmd-git\dmd2\windows\bin\..\..\src\phobos\std\string.d(2346): Orphan format arguments: args[1..2]

I'd like to keep this behavior in either a new separate format function or as a customization point of format.

On 6/27/13, Adam D. Ruppe <destructionator@gmail.com> wrote:
> I think if there's going to be a new function anyway, it might as well be more like the ctFormat bearophile mentioned, and check it at compile time.

Yeah but it's not always possible to know what the formatting string is. For example, maybe you have an enum array of format strings but a runtime index into this array which you pass to format at runtime. I've ported C samples before that used this style of formatting.

Andrej Mitrovic:

> Yeah but it's not always possible to know what the formatting string
> is. For example, maybe you have an enum array of format strings but a
> runtime index into this array which you pass to format at runtime.
> I've ported C samples before that used this style of formatting.

In some cases the format string is computed at run-time, so it can't be a template argument. A ctWritefln is for the other cases.

Bye,
bearophile

On 06/27/13 13:16, Nicolas Sicard wrote:
> On Wednesday, 26 June 2013 at 20:50:03 UTC, bearophile wrote:
>> If you want a special behavour you should use a special function as partialWritefln that ignores arguments not present in the format string.
> 
> Or maybe just define a new format specifier (%z, for 'zap'?) to ignore one or more arguments?

%.0s

artur

Andrei Alexandrescu:

>> But the bottom line is I don't think we need to force anything on anybody. If anything, we could split up the internal format
>> implementation and provide format and safeFormat functions.
>>
>> format("%s %s", 1);  // no exceptions
>
> NO! This is exactly the kind of code that is buggy and useless. The right use cases involve more arguments than format specifiers.

Currently this code is accepted (and it prints "A B10"), but I think it should be not accepted (also why is it 1-based?):

import std.stdio;
void main() {
    writefln("A%2$s B%1$s", 10);
}


> The only point I'd negotiate would be to not throw with positional
> arguments, and throw with sequential arguments. All code that cares uses
> positional specifiers anyway.

I have opened this ER:
http://d.puremagic.com/issues/show_bug.cgi?id=10489

Bye,
bearophile

On Thursday, 27 June 2013 at 19:22:08 UTC, bearophile wrote:
> (also why is it 1-based?):

It is specified that way in the Single Unix Specification for format strings.

I'm not sure why they did it that way, but if we changed it, that would be surprising since the format string is otherwise similar to printf, but this would be different.

On Thursday, June 27, 2013 13:47:53 Adam D. Ruppe wrote:
> On Thursday, 27 June 2013 at 06:59:49 UTC, Jonathan M Davis wrote:
> > But if we make a design decision that favors 1% of our userbase
> 
> I really think we all need to be more careful about these kinds of statements. I often see posts on the newsgroup where someone says "feature/function X is totally useless".... and it is something I actually use.
> 
> In this thread, there's I think three people who said the extra arguments are a good thing (myself, Andrei, and Peter). And there's what, maybe a dozen participants in the thread (I didn't count, I think it is less though)?
> 
> That's not a big enough sample to be statistically significant, but what are the odds that this thread is so skewed that only 1% of D's userbase feels this way, when 25% of the thread disagrees?

I wasn't arguing that only 1% of the users care about this particular feature. What I was objecting to was that Andrei seemed to think that argumentum ad populum was an invalid argument, and when you're talking about an API and the userbase for that API, I really don't think that argumentum ad populum is invalid. If you make a design decision that causes problems for 99% of your users, then it's a bad design decision, and I think that the fact that the majority of the users would then be against it should hold weight.

For this particular feature, I don't know how many people want format to ignore extra arguments. Certainly, prior to this thread, I'd heard Andrei discuss it once, and I've never heard anyone else even mention it. And initially, everyone else in this thread thought that that it was a bad idea. So, it at least looked like the majority thought that it was a bad idea. And if that held true, then I think that that would at least be an argument for making format require that the number of arguments match the number of format specifiers. It wouldn't necessarily be enough in and of itself (particularly if the use case for allowing more is valid and doesn't really harm the people who don't use it), but I think that it would still be valid argument.

So, I was objecting to Andrei's assertion that what the majority thought was not a valid argument rather than trying to specifically assert that we definitely shouldn't do this because of how many people were against it. What we do ultimately depends on what all of the arguments are and what all of the various pros and cons are.

But your point is well taken about 1% vs 99% and whatnot. We certainly don't want to decide that only 1% of users care about something based on the half-a- dozen or so people who happen to have posted in a discussion on it over the course of a few hours.

- Jonathan M Davis

On 27/06/13 23:33, bearophile wrote:
> Andrej Mitrovic:
>
>> Yeah but it's not always possible to know what the formatting string
>> is. For example, maybe you have an enum array of format strings but a
>> runtime index into this array which you pass to format at runtime.
>> I've ported C samples before that used this style of formatting.
>
> In some cases the format string is computed at run-time, so it can't be
> a template argument. A ctWritefln is for the other cases.

In internationalized/localized code the string is highly likely to be determined at run time.

Peter

On 28/06/13 05:52, Jonathan M Davis wrote:
> On Thursday, June 27, 2013 13:47:53 Adam D. Ruppe wrote:
>> On Thursday, 27 June 2013 at 06:59:49 UTC, Jonathan M Davis wrote:
>>> But if we make a design decision that favors 1% of our userbase
>>
>> I really think we all need to be more careful about these kinds
>> of statements. I often see posts on the newsgroup where someone
>> says "feature/function X is totally useless".... and it is
>> something I actually use.
>>
>> In this thread, there's I think three people who said the extra
>> arguments are a good thing (myself, Andrei, and Peter). And
>> there's what, maybe a dozen participants in the thread (I didn't
>> count, I think it is less though)?
>>
>> That's not a big enough sample to be statistically significant,
>> but what are the odds that this thread is so skewed that only 1%
>> of D's userbase feels this way, when 25% of the thread disagrees?
>
> I wasn't arguing that only 1% of the users care about this particular feature.
> What I was objecting to was that Andrei seemed to think that argumentum ad
> populum was an invalid argument,

Plato would agree with Andrei.

Peter