digitalmars.D.bugs - [Issue 5142] New: writefln should allow no arguments (no formating string)
- d-bugmail puremagic.com (25/25) Oct 31 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5142
- d-bugmail puremagic.com (16/16) Nov 02 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5142
- d-bugmail puremagic.com (10/16) Nov 02 2010 And how this resolves my problem? I was talking about writefln behaviour...
- d-bugmail puremagic.com (18/31) Nov 02 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5142
- d-bugmail puremagic.com (11/14) Nov 02 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5142
- d-bugmail puremagic.com (64/82) Nov 03 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5142
http://d.puremagic.com/issues/show_bug.cgi?id=5142 Summary: writefln should allow no arguments (no formating string) Product: D Version: D2 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nobody puremagic.com ReportedBy: baryluk smp.if.uj.edu.pl 06:03:52 PDT --- 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 31 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5142 Steven Schveighoffer <schveiguy yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |schveiguy yahoo.com Resolution| |WONTFIX 08:36:41 PDT --- 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 02 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5142 10:33:21 PDT ---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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 02 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5142 11:08:04 PDT ---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.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!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' {} \; -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------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.
Nov 02 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5142 bearophile_hugs eml.cc changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bearophile_hugs eml.ccwriteln 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 02 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5142 04:16:05 PDT ---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).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.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!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 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------...I agree.
Nov 03 2010