I created a tableview and there is a toggle in a cell, I click the toggle there will be a function in the cell's protocol, and in the implement of the function I have a logic like this:
The print function after the return is executed! can't believe this anybody know why? Or this is a bug of apple?
The warning in your screenshot tells you exactly what's happening:
Expression following ‘return’ is treated as an argument of a ‘return’.
When return is being called it sometimes takes an expression, which in this case is a function.
If you don't want the print statement to be part of the return, you could add a ; to the end of return
Related
This may be a little too general for this forum, but hoping someone can explain this in a way that makes sense to my brain. I've tried reading and researching and have found lots of examples - but I still don't understand the "why" which means that I am not understanding exactly how a program comes back from a function return.
Here is a very simple function I wrote that solves a puzzle using backwards recursion. It works well.
func solver(grid: [[Int]])->[[Int]] {
var returnGrid = constraintPropogation(grid: grid)
if contradictionCheck(grid: returnGrid) == false {
return returnGrid
} else {
if returnGrid.flatMap({$0}).filter({$0 == 3}).count == 0 {
print("SOLVED**********")
gridPrint(grid: returnGrid)
print()
stopFlag = true
stopAnswer = returnGrid
return returnGrid
} else {
let randStart = getRandomStart(grid: returnGrid)
returnGrid[randStart.x][randStart.y] = 0
solver(grid: returnGrid)
returnGrid[randStart.x][randStart.y] = 1
solver(grid: returnGrid)
}
}
if stopFlag == true {return stopAnswer}
return solver(grid: returnGrid)
}
My issue is understanding the returns. In the third line of the function if a contradiction check fails this means that we've gone down a path that would not be possible. Therefore we return. That makes sense. The second return in the middle of the function occurs when the puzzle is solved, so it makes sense to return there. But the last one at the end "return solver(grid: returnGrid)" is challenging to my understanding. Here we are returning but also calling this same function again. This is not going deeper into the potential solution path (that happens in the "else" section where the function is called). Why do we need to call the function again rather than just returning? What is happening under the hood? Does the return happen first where we "pop back up a level" and then we are calling the function again effectively one rung higher on the stack? When I write these words I realize that I have a vague understanding - but somehow it is not all clicking together for me.
Am at the point now that when I'm writing functions that involve recursion I just try both returning on own or returning and calling function again to see which one achieves what I want. But I'd really like to understand it rather than just guessing. If anyone had a simple explanation I would appreciate it.
Your function solver takes an array of arrays, and returns an array of arrays. Any call to return(something) returns that something to the caller.
Saying return(someArrayOfArrays) means you are done, and have a result.
Saying return(solver(someArrayOfArrays)) says "call this function again, passing in a new value. Return whatever the result is as the function result." The current call to solver() is done doing work, and passes its intermediate results to another call to the function. That's the recursion. You can think of this as nesting a function call inside a function call inside a function call, or stacking function calls on top of each other.
The call to solver(grid: returnGrid) does not make any sense. That is a recursive call, but you ignore the result. Thus, that call does nothing useful. If your remove that line, it won't make any difference to the outcome. That line is saying "Go do a bunch of work and find an answer for me, but I will throw away your answer". The compiler should give you a "function result ignored" warning at that line.
Beyond that, I can't tell what your code is doing. It appears to be modifying at least one global variable, "stopAnswer". That suggests it's not a pure recursive function.
Is there ever a case where "return n" will cause a problem due to something within ". . ." ?
func foo() -> Int
{
. . .
return n
}
Or, should I always use return( n ) ?
func foo() -> Int
{
. . .
return( n)
}
UPDATE...
The main reason for this question is trouble I once had in viewDidLoad() where the final instruction line was simply "return" because I didn't believe () were needed. However, I had several lines below, which got executed.
(I had temporarily inserted the line with just "return" while debugging.)
This caused confusion and took a while to debug.
From then on, my policy was to always use return( . . . ) and never saw the problem again.
Someone on StackO explained this Swift behavior, but I don't remember the explanation.
I don't think the parentheses are needed unless you declare your function to return a tuple.
As gnasher says in their answer, the parens in the return are weird.
I seem to remember that a function result in Swift is always considered to be a tuple, where Void is a special case empty tuple. If my (vague) memory is correct that might explain why the parens are valid. I need to see if I can dig that up.
The parentheses are absolutely weird. They are weird in C, in Swift they are bizarre.
And since space is relevant in Swift, your weird spacing makes it even weirder.
As a rule, you don’t write anything unnecessary in Swift.
Here is answer to my question:
Parens are only needed if line with "return" is between lines of code
in same func. Other than that case, as far as I know, parens after
return are superfluous.
Here is my test for proving this............
With this code (no parens after return)...
print("viewDidLoad Abort.")
return
print("viewDidLoad WTF!")
...I get:
viewDidLoad Abort.
viewDidLoad WTF!
But, with this code (parens after return)...
print("viewDidLoad Abort.")
return()
print("viewDidLoad WTF!")
...I only get:
viewDidLoad Abort.
Thus, in response to all the esteemed advice above, I shall not use parens after return, unless temporarily aborting a func by using "return()" unless there is a better way to temporarily abort func.
I got to know recently that Anonymous function
is given in the form of: function body that follows argument Lambda
(=>)
and it has no name
is used once in the code
So, you don't have to add a complete function to do this but rather, you can put the function body in use directly in your code (main function).
I read that in spark, "println" statement is always considered anonymous method for the following reasons:
println statement is considered a function body
Moreover, it wasn't added to a method with a name but was rather
used directly in the main class.
Also, it was used once in the code.
Ex:
Before converting to anonymous
click to view pic1
After converting to anonymous
click to view pic2
However, my question is what if the Lambda function wasn't used.. will println be considered as anonymous function still as shown in the ex below?
main question Ex:
click to view pic3
println is a function, but it is not an anonymous function since it has a name.
I am trying to create an automatic 'debugger' for tracing function flow. Because I'm not a god, I do make mistakes, and when I do, I normally end up throwing a bunch of "show" in my functions. What I'm looking to do is create a function that will insert shows prior to each line for each variable used in an expression on that line and any variable assigned to in the previous.
Imagine I have a function f that is throwing an unhelpful error. I would insert
f: debugwrap[f];
after the function definition to insert the appropriate debugging within the lines of function string, parse, and return the augmented function.
I have had success handling the params and simple functions, but where I have trouble is where semicolons do not indicate eol, such as in function calls. Using parse on the function body, I can easily break out all the lines and find the required variables, but once I do that, I need to 'unparse' each line in the function. That unparsing is giving me trouble, especially where functions are translated to what I believe is k - such as "*:".
Simple example with only initial logging:
q)f: {[a;b] a: a xexp b; c: a-first `int$-1#string first table[`symbols]; :c }
q)df: dp[f;";"]
q)df
"{[a;b] show "a is ",string[a]; show "b is ",string[b]; a : a xexp b;c : a - *:`int$-1#$:*:table`symbols;: c;}"
q)parse df
ERROR: *:
What I'm doing now is recursively walking through the parse tree and reconstructing the call. That is painful and not yet yielding results. What I think is the best way is to get the information I need out of each parse subtree, then unparse that subtree and append it to my function string.
Appreciate any help you all can offer.
The best place to see how debugging might be done, is with this code: http://code.kx.com/q/ref/debug/
I'm working on an expression evaluator. There is an evaluate() function which is called many times depending on the complexity of the expression processed.
I need to break and investigate when this method returns null. There are many paths and return statements.
It is possible to break on exit method event but I can't find how to put a condition about the value returned.
I got stuck in that frustration too. One can inspect (and write conditions) on named variables, but not on something unnamed like a return value. Here are some ideas (for whoever might be interested):
One could include something like evaluate() == null in the breakpoint's condition. Tests performed (Eclipse 4.4) show that in such a case, the function will be performed again for the breakpoint purposes, but this time with the breakpoint disabled. So you will avoid a stack overflow situation, at least. Whether this would be useful, depends on the nature of the function under consideration - will it return the same value at breakpoint time as at run time? (Some s[a|i]mple code to test:)
class TestBreakpoint {
int counter = 0;
boolean eval() { /* <== breakpoint here, [x]on exit, [x]condition: eval()==false */
System.out.println("Iteration " + ++counter);
return true;
}
public static void main(String[] args) {
TestBreakpoint app = new TestBreakpoint();
System.out.println("STARTED");
app.eval();
System.out.println("STOPPED");
}
}
// RESULTS:
// Normal run: shows 1 iteration of eval()
// Debug run: shows 2 iterations of eval(), no stack overflow, no stop on breakpoint
Another way to make it easier (to potentially do debugging in future) would be to have coding conventions (or personal coding style) that require one to declare a local variable that is set inside the function, and returned only once at the end. E.g.:
public MyType evaluate() {
MyType result = null;
if (conditionA) result = new MyType('A');
else if (conditionB) result = new MyType ('B');
return result;
}
Then you can at least do an exit breakpoint with a condition like result == null. However, I agree that this is unnecessarily verbose for simple functions, is a bit contrary to flow that the language allows, and can only be enforced manually. (Personally, I do use this convention sometimes for more complex functions (the name result 'reserved' just for this use), where it may make things clearer, but not for simple functions. But it's difficult to draw the line; just this morning had to step through a simple function to see which of 3 possible cases was the one fired. For today's complex systems, one wants to avoid stepping.)
Barring the above, you would need to modify your code on a case by case basis as in the previous point for the single function to assign your return value to some variable, which you can test. If some work policy disallows you to make such non-functional changes, one is quite stuck... It is of course also possible that such a rewrite could result in a bug inadvertently being resolved, if the original code was a bit convoluted, so beware of reverting to the original after debugging, only to find that the bug is now back.
You didn't say what language you were working in. If it's Java or C++ you can set a condition on a Method (or Function) breakpoint using the breakpoint properties. Here are images showing both cases.
In the Java example you would unclik Entry and put a check in Exit.
Java Method Breakpoint Properties Dialog
!
C++ Function Breakpoint Properties Dialog
This is not yet supported by the Eclipse debugger and added as an enhancement request. I'd appreciate if you vote for it.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=425744