On 4/28/16 3:21 PM, David Nadlinger wrote:
On Thursday, 28 April 2016 at 18:49:54 UTC, Steven Schveighoffer wrote:
Please, D, don't ever do this kind of stuff! I just gained about 45
warnings in my iOS project.
… and what? This statement alone is hardly an argument. Both those
warnings are trivial to fix in an automated fashion; in fact, you
pointed out the possible rewrites yourself. Fixing the warnings and
verifying the changes takes way less time than tracing down and
addressing even a simple application bug, yet the language is
substantially cleaner as a result. This is exactly the sort of changes D
needs more of.
And both warnings achieved nothing in terms of preventing bad code. Like
absolutely nothing.
A function like this (actual function in my code):
func distRange(var segment0: NRMShapeSegment, var segment1:
NRMShapeSegment, var segment2: NRMShapeSegment, minLength: CGFloat) ->
(CGFloat, CGFloat)
Now must have 3 var statements at the beginning to identify the
parameters as var. What exactly does this achieve? BTW, xcode does not
provide a mechanism to fix this automatically, I'd have to write a
script to do it.
It's like we're back to non-ANSI C style parameters.
And as far as the ++ to += 1, sure, that is an easy fix. But what is the
benefit? If ++ was not there originally, then I wouldn't care, but now I
have to go through and change 15 lines of code for no flipping reason.
At least xcode suggests the fix and will do it for me.
I also have several for loops that I have no idea how to rewrite. Maybe
you can help:
http://stackoverflow.com/questions/36923799/swift-equivalent-for-loop-complex-condition
I hope this doesn't happen to D.
-Steve
