[Issue 16771] Depreciation of implicit string concatenation in 2.072

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16771

--- Comment #2 from Joseph M Rice <ricejm01 at gmail.com> ---
(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.

--