Bug 5142 – writefln should allow no arguments (no formating string)

In D1 it is allowed to write writefln(); In D2 it is no more. This problem exists for more than year now, after writefln is actually template. Disallowing writefln without parameters (as above) makes porting D1 software really a pain (one need to change writefln(); to writeln()), and is inconsistant (propgramer always need to remember which function to use, and makes edditing annoying). Thanks.

This was a deliberate change. The benefit of writeln is that you can put formatting characters in strings without having them interpreted as formatting sequences. I don't think it's that big of a pain -- the compiler should tell you all the places where you have messed up.

> This was a deliberate change. > > The benefit of writeln is that you can put formatting characters in strings > without having them interpreted as formatting sequences. And how this resolves my problem? I was talking about writefln behaviour, not writeln! > I don't think it's that big of a pain -- the compiler should tell you all the > places where you have messed up. Yes, it is. Much simpler is just to add empty template writefln() specizliation which will just call writeln();, for the sake of consistency, and compatibility with old code.

(In reply to comment #2) > > This was a deliberate change. > > > > The benefit of writeln is that you can put formatting characters in strings > > without having them interpreted as formatting sequences. > > And how this resolves my problem? I was talking about writefln behaviour, not > writeln! writeln is for without formatting, writefln is for with formatting. writefln expects its first argument to be a string, if it's not a string, then you aren't calling it properly. > > > I don't think it's that big of a pain -- the compiler should tell you all the > > places where you have messed up. > Yes, it is. Much simpler is just to add empty template writefln() specizliation > which will just call writeln();, for the sake of consistency, and compatibility > with old code. But there is no formatting string. It's like saying pow(2) should be equivalent to pow(2, 1). It makes no sense to call it. The formatting string is an essential parameter. Typing writeln() instead of writefln() is hardly a 'pain', and it's a compile time error. Compile time errors are easy to find because the compiler points them all out for you. No special searching is necessary. in fact, here is a special script I wrote in about 5 seconds which will solve all your problems: find . -name '*.d' -exec sed 's/writefln()/writeln()/g' {} \;

(In reply to comment #3) > writeln is for without formatting, writefln is for with formatting. writefln > expects its first argument to be a string, if it's not a string, then you > aren't calling it properly. I agree.

(In reply to comment #3) > (In reply to comment #2) > > > This was a deliberate change. > > > > > > The benefit of writeln is that you can put formatting characters in strings > > > without having them interpreted as formatting sequences. > > > > And how this resolves my problem? I was talking about writefln behaviour, not > > writeln! > > writeln is for without formatting, writefln is for with formatting. writefln > expects its first argument to be a string, if it's not a string, then you > aren't calling it properly. As I written, in D1 it was correct behavior. Additionally it is unnecessary restriction and inconsistency. Lets see at some common type of code in C: printf("\n"); printf("a=%d b=%f\n", a, b); printf("c=%d d=%f\n", c, d); printf("\n"); printf("\n"); (slightly artificial but I have lots of such or similar printf like statements. I also saw this frequently in others people code). It is much cleaner and visually appealing than: printf("a=%d b=%f\n\n", a, b); printf("c=%d d=%f\n\n\n", c, d); Because you do not see easily where are additional empty lines, and do not immiedietly see structure of output. In D1, one could write: writefln(); writefln("a=%d b=%f", a, b); writefln("c=%d d=%f", c, d); writefln(); writefln(); Whit is even nicer. It also simplifies reaaranging and editing arguments. In D2, one needs to write: writeln(); writefln("a=%d b=%f", a, b); writefln("c=%d d=%f", c, d); writeln(); writeln(); Which introduces unnecessary burded to the code. You also cannot just add parameters, like in D1. Suppose you want to add them to this: writefln("c=%d d=%f", c, d); writeln(); writeln(); Then you add them: writefln("c=%d d=%f", c, d); writeln("f=%f g=%d", f, g); writeln(); But, well, it is incorrect, you need to remember to change writeln to writefln. D1 was simpler and cleaner. One of potentiality possibility is to just write writefln("");. But this isn't so common code. Not to mention, that one can also use other usefull tricks, without formating string: writefln("f=", f, " g=", g); but this is beyond scope of this bug report (and I understand that writefln("s=", s, f), can not work as expected when s="fff%fff", by pure accident). This also makes porting harder, but will just leave it (There is almost good solution for this problem, but I understand that it will need some exception, which isn't good as it can fool beginners). > in fact, here is a special script I wrote in about 5 seconds which will solve > all your problems: > > find . -name '*.d' -exec sed 's/writefln()/writeln()/g' {} \; Not exactly all. What if I have aliases, or imported writefln with other symbolic name? What if I used other style of brackets, like "writefln ( );"? Can be resolved with some additional work, or with good IDE (which D lacks), but why break unnecessarily compatibility (of course there will be other problems with doing D1->D2 port, but just please make it simpler, not harder). I have thousands of occurrences of this problems in one of the projects. And spent about 2 hours fixing it. >>>... >> I agree. I understand, but do not agree with rationale. Thanks for your time. I know that this should be discussed on mailing list, but was hoping it is simpler problem.