Bug 16771 – Depreciation of implicit string concatenation in 2.072

I actually have to complain about this whole thing. In C/C++, Java, C# and virtually every programming language based on the C syntax allows for implicit string concatenation. Allowing this to be depreciated you are making the D language harder to use. the rationale for the reasoning for why all of sudden we have to start using ~ to break up long strings so that the code is readable is quite frankly Bullshit! Case in point. this: string[] names = [ "Anna", "Michael" "Emma", "David" ]; // The content of arr is [ "Anna", "MichaelEmma", "David" ] Vs. string aReallyLongString = "this is a really long string that will" "not look good on the page if it put on" " a single line"; There is a huge difference between Array assignment and single string assignment. How about you revert the changes in 2.072 and re-implement to fix the actual problem, which is solely with array assignment and look for '[' ']' characters to not allow implicit string concatenation. At this point 2.072 is not usable, and I would appreciate not having to fix ~20,000 lines of code to add '~' everywhere. Not to mention you just broke almost every dub library I use as well.

Adding exceptions to a rule just makes the language even more complicated, with very little benefit. (In reply to Joseph M Rice from comment #0) > I actually have to complain about this whole thing. In C/C++, Java, C# and > virtually every programming language based on the C syntax allows for > implicit string concatenation. > > Allowing this to be depreciated you are making the D language harder to use. > > the rationale for the reasoning for why all of sudden we have to start using > ~ to break up long strings so that the code is readable is quite frankly > Bullshit! > > There is a huge difference between Array assignment and single string > assignment. How about you revert the changes in 2.072 and re-implement to > fix the actual problem, which is solely with array assignment and look for > '[' ']' characters to not allow implicit string concatenation. > > At this point 2.072 is not usable, and I would appreciate not having to fix > ~20,000 lines of code to add '~' everywhere. Not to mention you just broke > almost every dub library I use as well. Adding an exception to the rule will just make it more complicated. With very little benefit. In your example, you can just add "~" to the end of the line to split the long string. string aReallyLongString = "this is a really long string that will" "not look good on the page if it put on" " a single line"; // vs string aReallyLongString = "this is a really long string that will"~ "not look good on the page if it put on"~ " a single line"; I don't think it'll be that difficult to correct. It's only a deprecation right now, that doesn't mean the feature is removed. I doubt there's 20k lines of strings as well. You could probably write a regex to fix most of the occurrences.

(In reply to Sprink from comment #1) > Adding exceptions to a rule just makes the language even more complicated, > with very little benefit. It's not really an exception to the rule. I was pointing out that the rationale is not grounded in reality. If they want to fix the array assignment issue, which their the entire rationale supports. Then fix that problem. "Use a scalpel, don't use a sledge hammer and create other problems." Ideally the correct fix is to revert the commit that adds this depreciation entirely. Every other language based off C syntax allows for strings to carry over into multiple lines. If we as a community want D to get more and more adoption in the marketplace. Then we really can't be moving the cheese on people and making it harder to program than in other languages. > I don't think it'll be that difficult to correct. It's only a deprecation > right now, that doesn't mean the feature is removed. I doubt there's 20k > lines of strings as well. You could probably write a regex to fix most of > the occurrences. My business has been developing in D for over 3 years, we have a large code base written spanning several products. So yes, we have over 20,000 warnings that have popped up after switching to 2.072 yesterday for evaluation, and compiling every project. In our defined Coding Style Guidelines, we basically implement the Linux kernel style guidelines which in a nut shell is: (don't go past 3 levels of indentation, don't go past 80 characters per line). This is to promote readability and make any line of code written by any individual developer indistinguishable from any other. At this point 2.072 is not an option for us, and we will be looking at using the GDC or ldc moving forward. For the time being we are not going to be upgrading our dmd on our development servers. Using Regex is not a substitute for human eyes and I would not trust it. Any developer who instantly thinks using Regex as a solution to a problem, now has suddenly got two problems (1 the original problem, 2 How do i safely write a regex to solve problem 1). In my experience you will spend more time developing a solution to solve problem 2, then you would have just rolled up your sleeves and fixed problem 1.

sed 's/\" *$/\" ~/g' myfile.d > newmyfile.d mv newmyfile.d myfile.d The bugs fixed by this update are well worth the burden to run sed on your files. Sorry.

(In reply to Steven Schveighoffer from comment #3) > sed 's/\" *$/\" ~/g' myfile.d > newmyfile.d > mv newmyfile.d myfile.d > > The bugs fixed by this update are well worth the burden to run sed on your > files. Sorry. I thought that's what dfix is for also? Semantically parsing your sources, finding deprecations, fixing them inplace.

(In reply to Joseph M Rice from comment #0) > In C/C++, Java, C# and > virtually every programming language based on the C syntax allows for > implicit string concatenation. No? http://ideone.com/0KbaFl http://ideone.com/rlUqAb